Return-Path: Delivered-To: apmail-geronimo-user-archive@www.apache.org Received: (qmail 19570 invoked from network); 31 May 2006 21:54:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 31 May 2006 21:54:19 -0000 Received: (qmail 49578 invoked by uid 500); 31 May 2006 21:54:16 -0000 Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org Received: (qmail 49516 invoked by uid 500); 31 May 2006 21:54:15 -0000 Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: user@geronimo.apache.org List-Id: Delivered-To: mailing list user@geronimo.apache.org Received: (qmail 49504 invoked by uid 99); 31 May 2006 21:54:15 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 May 2006 14:54:15 -0700 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [68.142.206.241] (HELO smtp108.plus.mail.mud.yahoo.com) (68.142.206.241) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 31 May 2006 14:54:14 -0700 Received: (qmail 32071 invoked from network); 31 May 2006 21:53:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=uQEBJR44eDoUgkODu3QS5UdTY/D5n8EG+fdOgGUZd9SRxwd1vFUU+jVCw7mWoL7INNRwSEuxMDW9W/v+alW4hDNE7g4OfrZPKxD/MCYH2uBW6ygh6et1fZl7cGsCepfyp9TbmqR7KspWfqGnwBy+bRe0TMRecXUBLV01INWjc5o= ; Received: from unknown (HELO ?192.168.1.5?) (david?jencks@66.93.38.137 with plain) by smtp108.plus.mail.mud.yahoo.com with SMTP; 31 May 2006 21:53:52 -0000 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <447E0D05.9070208@coderesearch.com> References: <4690875E336998438DF43A78B8E38CF2E4F5DF@BLRKECMSG01.ad.infosys.com> <447DDAF4.902@coderesearch.com> <447E0D05.9070208@coderesearch.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6A41F021-91AB-4A5C-A07E-D14651480A6A@yahoo.com> Content-Transfer-Encoding: quoted-printable From: David Jencks Subject: Re: Problem with Geronimo 1.0, PreparedStatements, pools and MaxDB Date: Wed, 31 May 2006 14:54:09 -0700 To: user@geronimo.apache.org X-Mailer: Apple Mail (2.746.2) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On May 31, 2006, at 2:39 PM, Mario R=FCbsam wrote: > David, > > where can I get the source for Traql 1.2.1? I will try to debug > that commit handling. svn co https://svn.codehaus.org/tranql/trunk/connector will get the current source code: if it's not exactly the same was =20 what has been released it should be pretty close. > > I have AutoCommit always off because I need the transaction > control so CommitBeforeAutocommit=3Dtrue was no help for my problem. I was pretty sure that was the case :-) thanks david jencks > > Thanks, > Mario > > > > David Jencks wrote: >> Mario, >> I don't see an obvious way for this stuff to break, but if you are =20= >> set up for debugging you could get the tranql connector source =20 >> code and trace through starting at =20 >> org.tranql.connector.jdbc.ConnectionHandle.commit(). I don't see =20 >> how the commit call wouldn't get eventually to the db, but knowing =20= >> which path execution takes should make it simpler to figure out =20 >> what is going on. >> BTW someone was mentioning setting CommitBeforeAutocommit to =20 >> true. You should only set this on very buggy jdbc drivers that =20 >> violate the jdbc spec by not committing pending work when you set =20 >> autocommit to true (axion). Any real database should not need =20 >> this set. >> thanks >> david jencks >> On May 31, 2006, at 11:05 AM, Mario R=FCbsam wrote: >>> Santosh, >>> >>> I did the development mostly on PostgreSQL. It's working there =20 >>> but don't know >>> if the commits come through or if the DB handle it in some way. >>> I can't test Derby atm because I have to setup a separate Derby =20 >>> server to import >>> all the data needed. That needs to much time. >>> >>> Thanks, >>> Mario >>> >>> >>> Santosh Koti wrote: >>>> Mario, >>>> Can u try the same thing on the Derby ,if it is not cumbersome :) >>>> I think tranQL has better support for Derby. >>>> PS: Ofcourse it may not solve ur MaxDB problem ,but atleast it =20 >>>> says ur code is safe enough :) >>>> Thanks, >>>> Santosh. >>>> "Don't talk about yourself; it will be done when you leave. " >>>> -----Original Message----- >>>> From: Santosh Koti [mailto:Santosh_Koti@infosys.com] Sent: =20 >>>> Wednesday, May 31, 2006 11:10 PM >>>> To: user@geronimo.apache.org >>>> Subject: RE: Problem with Geronimo 1.0, PreparedStatements, =20 >>>> pools and MaxDB >>>> Mario, >>>> I agree that is not a solution , but atleast it points out that =20 >>>> the problem is cornered around TranQL ?? . (That's what I =20 >>>> suspect !! If so, then look smething on transQL config, or may =20 >>>> need to chk for next release :) Time for the gurus to dive in =20 >>>> here !! :) >>>> Thanks, >>>> Santosh. >>>> "Don't talk about yourself; it will be done when you leave. " >>>> -----Original Message----- >>>> From: Mario R=FCbsam [mailto:mr@coderesearch.com] Sent: Wednesday, =20= >>>> May 31, 2006 10:55 PM >>>> To: user@geronimo.apache.org >>>> Subject: Re: Problem with Geronimo 1.0, PreparedStatements, =20 >>>> pools and MaxDB >>>> Santosh, >>>> Santosh Koti wrote: >>>>> Mario, >>>>> >>>>> Just give another try (of course a wild advise :-)) >>>> I did ;) >>>>> After running the transactions , chk ur DB for any updates, =20 >>>>> then bring the server down -> & then chk ur DB, whether commit =20 >>>>> is happening the moment u trigger the server with a shutdown =20 >>>>> event ?? >>>> data is committed with shutdown, but that is not a solution >>>>> If so , some configuration needs to be looked at ? ! >>>> here is what I did now: >>>> instead of calling: >>>> mConnection.commit() >>>> I did the following: >>>> Statement tStatement =3D mConnection.createStatement(); >>>> tStatement.executeUpdate("COMMIT"); >>>> this is dirty but working, all commits are registered on the =20 >>>> MaxDB server >>>> this is bypassing all the commit stuff in the Tranql Connection =20 >>>> object >>>> and the driver >>>> So I find me now debugging the commit stuff in the Connection =20 >>>> instance. >>>> Thanks, >>>> Mario >>>>> >>>>> >>>>> Thanks, >>>>> Santosh. >>>>> "Don't talk about yourself; it will be done when you leave. " >>>>> >>>>> -----Original Message----- >>>>> From: Mario R=FCbsam [mailto:mr@coderesearch.com] Sent: =20 >>>>> Wednesday, May 31, 2006 9:54 PM >>>>> To: user@geronimo.apache.org >>>>> Subject: Re: Problem with Geronimo 1.0, PreparedStatements, =20 >>>>> pools and MaxDB >>>>> >>>>> Santosh, >>>>> >>>>> it works, but only in the following situation: >>>>> >>>>> open connection --> call update --> commit >>>>> >>>>> >>>>> if you I do a: >>>>> >>>>> open connection --> call query --> call update --> commit >>>>> >>>>> no commit happen on server, like without =20 >>>>> commitbeforeautocommit=3Dtrue >>>>> >>>>> Strange is that CommitBeforeAutocommit is a workaround for =20 >>>>> setAutoCommit(true) >>>>> which I don't use. And "setAutoCommit(true)" also doesn't commit. >>>>> >>>>> Thanks, >>>>> Mario >>>>> >>>>> >>>>> Santosh Koti wrote: >>>>>> Mario, >>>>>> >>>>>> Can u give a try for : >>>>>> commitbeforeautocommit=3D"true" in ur db deployment =20= >>>>>> plan. >>>>>> >>>>>> Not sure, but may work, I had the same problem with delayed =20 >>>>>> EJB's commit. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Santosh. >>>>>> "Don't talk about yourself; it will be done when you leave. " >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Mario R=FCbsam [mailto:mr@coderesearch.com] >>>>>> >>>>>> Sent: Wednesday, May 31, 2006 7:11 PM >>>>>> To: user@geronimo.apache.org >>>>>> Subject: Re: Problem with Geronimo 1.0, PreparedStatements, =20 >>>>>> pools and MaxDB >>>>>> >>>>>> The "setAutoCommit(false)" is required by MaxDB because >>>>>> it's default is "on". >>>>>> >>>>>> I debugged the connections open and close and I can see >>>>>> the connections (db sessions on the MaxDB server) come >>>>>> and go when I do this. The only thing that not happen >>>>>> on the server is the Connection.commit() whe I call it. >>>>>> >>>>>> If I use the direct driver connection I can see the >>>>>> commit in the stats immediately after I call the commit. >>>>>> If I use the connection from the pool no commit happens >>>>>> on the server. >>>>>> >>>>>> Is there any delayed commit mechanism implemented? >>>>>> >>>>>> Thanks, >>>>>> Mario >>>>>> >>>>>> >>>>>> >>>>>> Aaron Mulder wrote: >>>>>>> The one thing that looked suspicious in your code was the >>>>>>> setAutoCommit -- that shouldn't be done in a J2EE =20 >>>>>>> environment. Can >>>>>>> you try commenting out that line and see if it makes a =20 >>>>>>> difference? >>>>>>> >>>>>>> If that doesn't help, can you put printlns near where you =20 >>>>>>> close the >>>>>>> connections and just convince yourself that they're =20 >>>>>>> definitely being >>>>>>> closed? >>>>>>> >>>>>>> Thanks, >>>>>>> Aaron >>>>>>> >>>>>>> On 5/31/06, Mario R=FCbsam wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I testet a bit further and tried the following situations: >>>>>>>> >>>>>>>> I used a direct driver connection without the Geronimo pool =20 >>>>>>>> --> working >>>>>>>> >>>>>>>> I disabled all write access to the tables were the hang occurs, >>>>>>>> only read access enabled --> working >>>>>>>> >>>>>>>> I checked (with the MaxDB Database Manager) the connections/db >>>>>>>> sessions all >>>>>>>> open and close correct so thats not the problem. >>>>>>>> >>>>>>>> So my conclusion is that there is something different with the >>>>>>>> transactions and Tranql. I debugged the commits and if I use =20= >>>>>>>> the >>>>>>>> direct driver connection I can see the commits in the =20 >>>>>>>> Database Manager >>>>>>>> stats. If I commit on the Tranql connection the commit is not >>>>>>>> registered on the MaxDB server. >>>>>>>> >>>>>>>> Is this now a driver or a Tranql issue? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Mario >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Mario R=FCbsam wrote: >>>>>>>>> Aaron, >>>>>>>>> >>>>>>>>> here is a stack trace attached, it hangs sometimes when =20 >>>>>>>>> calling the >>>>>>>>> prepareStatement and sometimes when executing the statement =20= >>>>>>>>> and it's >>>>>>>>> not always the same statement. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Mario >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Mario R=FCbsam wrote: >>>>>>>>>> Aaron, >>>>>>>>>> >>>>>>>>>> connections are correctly closed. If they are returned to =20 >>>>>>>>>> the pool, >>>>>>>>>> don't know? >>>>>>>>>> >>>>>>>>>> The code that opens/closes connections is a bit widespread =20= >>>>>>>>>> and wrapped >>>>>>>>>> into a db abstraction layer. Here are some code fragments =20 >>>>>>>>>> collected >>>>>>>>>> together without the try catches. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> open connection: >>>>>>>>>> >>>>>>>>>> InitialContext tCtx =3D new InitialContext(); >>>>>>>>>> >>>>>>>>>> mJDBCDataSource =3D (DataSource)tCtx.lookup( >>>>>>>>>> pDataSource.getString(PDbDataSource.URL)); >>>>>>>>>> >>>>>>>>>> String tUser =3D pDataSource.getString(PDbDataSource.USER, =20= >>>>>>>>>> null); >>>>>>>>>> String tPass =3D pDataSource.getString(PDbDataSource.PASS, =20= >>>>>>>>>> null); >>>>>>>>>> >>>>>>>>>> if (tUser !=3D null) { >>>>>>>>>> mConnection =3D mJDBCDataSource.getConnection(tUser, =20 >>>>>>>>>> tPass); >>>>>>>>>> } else { >>>>>>>>>> mConnection =3D mJDBCDataSource.getConnection(); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> mConnection.setAutoCommit(false); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> call statements: >>>>>>>>>> >>>>>>>>>> String tStmtSQL =3D "SELECT ...."; >>>>>>>>>> PreparedStatement tStmt =3D mConnection.prepareStatement=20 >>>>>>>>>> (tStmtSQL); >>>>>>>>>> >>>>>>>>>> tStmt.setString(1, tName); >>>>>>>>>> ResultSet tRS =3D tStmt.executeQuery(); >>>>>>>>>> >>>>>>>>>> while (tRS.next()) { >>>>>>>>>> ... >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> tRS.close(); >>>>>>>>>> tStmt.close(); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> close the connection: >>>>>>>>>> >>>>>>>>>> mConnection.close(); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The DataSource lookup happens only once. After that I only >>>>>>>>>> call getConnection() on the DS and close() on the connection. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Mario >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Aaron Mulder wrote: >>>>>>>>>>> It sounds like connections are not being returned to the =20 >>>>>>>>>>> pool, though >>>>>>>>>>> it's hard to know without a stack trace. Also, can you =20 >>>>>>>>>>> post the code >>>>>>>>>>> you're using to access the connection pool, execute the =20 >>>>>>>>>>> prepared >>>>>>>>>>> statements, and close the connection? And what kind of =20 >>>>>>>>>>> component is >>>>>>>>>>> running these prepared statements? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Aaron >>>>>>>>>>> >>>>>>>>>>> On 5/30/06, Mario R=FCbsam wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I have some serious problems when executing prepared =20 >>>>>>>>>>>> statements >>>>>>>>>>>> on MaxDB with pooled connections managed by Tranql in =20 >>>>>>>>>>>> Geronimo 1.0. >>>>>>>>>>>> >>>>>>>>>>>> The problem is, that after calling a lot of these prepared >>>>>>>> statements >>>>>>>>>>>> the connection will hang until I get a timout. It's always >>>>>>>>>>>> a different statement that worked just fine some =20 >>>>>>>>>>>> milliseconds >>>>>>>> before. >>>>>>>>>>>> There is no CPU load on the Geronimo machine and also no =20= >>>>>>>>>>>> load >>>>>>>>>>>> on the DB machine. Just a hang up until timeout. >>>>>>>>>>>> I can run the same app on MySQL 4.x or PostgrSQL 8.x =20 >>>>>>>>>>>> without any >>>>>>>>>>>> Problems. Also no problems with a client app and MaxDB =20 >>>>>>>>>>>> that do >>>>>>>>>>>> a batch import and use exactly the same statements but =20 >>>>>>>>>>>> without db >>>>>>>>>>>> pooling. >>>>>>>>>>>> >>>>>>>>>>>> So I think it must be a db pool problem with the MaxDB or a >>>>>>>>>>>> strange behaviour with that driver and connection pools. >>>>>>>>>>>> >>>>>>>>>>>> Any suggestions where I can start analysing the problem? >>>>>>>>>>>> >>>>>>>>>>>> here my MaxDB plan: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> xmlns=3D"http://geronimo.apache.org/xml/ns/j2ee/=20 >>>>>>>>>>>> connector-1.0"> >>>>>>>>>>>> >>>>>>>>>>> xmlns:dep=3D"http://geronimo.apache.org/xml/ns/=20 >>>>>>>>>>>> deployment-1.0"> >>>>>>>>>>>> mysql/sapdbc/7.6/jar >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> javax.sql.DataSource>>>>>>> connectionfactory-interface> >>>>>>>>>>>> >>>>>>>>>>>> jdbc/default >>>>>>>>>>>> >>>>>>>>>>> name=3D"UserName">sse >>>>>>>>>>>> >>>>>>>>>>> name=3D"Password">sse >>>>>>>>>>>> >>>>>>>>>>> name=3D"CommitBeforeAutocommit">false>>>>>>>>>>> setting> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> name=3D"Driver">com.sap.dbtech.jdbc.DriverSapDB>>>>>>> property-setting> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> name=3D"ExceptionSorterClass">org.tranql.connector.AllExceptionsA= =20 >>>>>>>> reFatalSorter >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> name=3D"ConnectionURL">jdbc:sapdb://192.168.8.3/service>>>>>>> config-property-setting> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 100 >>>>>>>>>>>> 50 >>>>>>>>>>>> >>>>>>>>>>>> 60000>>>>>>>>>>> milliseconds> >>>>>>>>>>>> >>>>>>>>>>>> 60 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Mario >>>>>>>>>>>> >>>>>>>> ---------------------------------------------------------------=20= >>>>>>>> --------- >>>>>>>>> DEBUG DATE=3D2006-05-30 TIME=3D13:42:22:046 CATEGORY=3Dcpa.db >>>>>>>> SOURCE=3Dmr@aeon:CDbContext.getPreparedStatement() SID=3Dcpa.=20= >>>>>>>> 1-1-1.cpa >>>>>>>> MESSAGE=3Dprepare statement "SELECT >>>>>>>> TbRegistryValues.TcValueText,TbRegistryValues.TcValueLineNo =20 >>>>>>>> FROM >>>>>>>> TbRegistry,TbRegistryValues WHERE >>>>>>>> ((TbRegistry.TcEntityId=3DTbRegistryValues.TcEntityId) AND >>>>>>>> (TbRegistry.TcDomain=3D?)) ORDER BY =20 >>>>>>>> TbRegistryValues.TcValueLineNo" >>>>>>>>> DEBUG DATE=3D2006-05-30 TIME=3D17:38:50:421 CATEGORY=3Dcpa.db >>>>>>>> SOURCE=3Dmr@aeon:CDbContext.getPreparedStatement() SID=3Dcpa.=20= >>>>>>>> 1-1-1.cpa >>>>>>>> MESSAGE=3Dprepared statement >>>>>>>> "org.tranql.connector.jdbc.PreparedStatementHandle@1728a26" >>>>>>>>> 13:42:22,046 WARN [GeronimoConnectionEventListener] >>>>>>>> connectionErrorOccurred called with null >>>>>>>>> com.sap.dbtech.jdbc.exceptions.ConnectionException: [-708] =20 >>>>>>>>> Timeout >>>>>>>>> at >>>>>>>> com.sap.dbtech.jdbc.ConnectionSapDB.execute=20 >>>>>>>> (ConnectionSapDB.java:554) >>>>>>>>> at >>>>>>>> com.sap.dbtech.jdbc.CallableStatementSapDB.sendCommand=20 >>>>>>>> (CallableStatementSapDB.java:1764) >>>>>>>>> at >>>>>>>> com.sap.dbtech.jdbc.StatementSapDB.sendSQL=20 >>>>>>>> (StatementSapDB.java:808) >>>>>>>>> at >>>>>>>> com.sap.dbtech.jdbc.CallableStatementSapDB.doParse=20 >>>>>>>> (CallableStatementSapDB.java:233) >>>>>>>>> at >>>>>>>> com.sap.dbtech.jdbc.CallableStatementSapDB.constructor=20 >>>>>>>> (CallableStatementSapDB.java:186) >>>>>>>>> at >>>>>>>> com.sap.dbtech.jdbc.CallableStatementSapDB.=20 >>>>>>>> (CallableStatementSapDB.java:88) >>>>>>>>> at >>>>>>>> com.sap.dbtech.jdbc.ConnectionSapDB.prepareStatement=20 >>>>>>>> (ConnectionSapDB.java:803) >>>>>>>>> at >>>>>>>> org.tranql.connector.jdbc.ConnectionHandle.prepareStatement=20 >>>>>>>> (ConnectionHandle.java:231) >>>>>>>>> at >>>>>>>> com.coderesearch.cpa.db.jdbc.CDbContext.getPreparedStatement=20 >>>>>>>> (CDbContext.java:1131) >>>>>>>>> at >>>>>>>> com.coderesearch.cpa.reg.db.jdbc.CDbBrokerRegistry.lookup=20 >>>>>>>> (CDbBrokerRegistry.java:129) >>>>>>>>> at >>>>>>>> com.coderesearch.cpa.reg.db.jdbc.CDbBrokerRegistry.query=20 >>>>>>>> (CDbBrokerRegistry.java:430) >>>>>>>>> at >>>>>>>> com.coderesearch.cpa.naming.CPANamingContextDb.lookup=20 >>>>>>>> (CPANamingContextDb.java:116) >>>>>>>>> at >>>>>>>> com.coderesearch.cpa.reg.CPARegistryContext.lookup=20 >>>>>>>> (CPARegistryContext.java:256) >>>>>>>>> at com.coderesearch.cpa.reg.Registry.lookupInt=20 >>>>>>>>> (Registry.java:199) >>>>>>>>> at >>>>>>>> com.coderesearch.abp.index.srv.CRPIndex.countLogin=20 >>>>>>>> (CRPIndex.java:140) >>>>>>>>> at >>>>>>>> com.coderesearch.abp.index.srv.CRPIndex.process=20 >>>>>>>> (CRPIndex.java:266) >>>>>>>>> at >>>>>>>> com.coderesearch.abp.found.srv.MainServlet.process=20 >>>>>>>> (MainServlet.java:482) >>>>>>>>> at >>>>>>>> com.coderesearch.abp.found.srv.MainServlet.doPost=20 >>>>>>>> (MainServlet.java:610) >>>>>>>>> at javax.servlet.http.HttpServlet.service=20 >>>>>>>>> (HttpServlet.java:615) >>>>>>>>> at javax.servlet.http.HttpServlet.service=20 >>>>>>>>> (HttpServlet.java:688) >>>>>>>>> at >>>>>>>> org.mortbay.jetty.servlet.ServletHolder.handle=20 >>>>>>>> (ServletHolder.java:428) >>>>>>>>> at >>>>>>>> org.apache.geronimo.jetty.JettyServletHolder.handle=20 >>>>>>>> (JettyServletHolder.java:99) >>>>>>>>> at >>>>>>>> org.mortbay.jetty.servlet.WebApplicationHandler=20 >>>>>>>> $CachedChain.doFilter(WebApplicationHandler.java:830) >>>>>>>>> at >>>>>>>> org.mortbay.jetty.servlet.JSR154Filter.doFilter=20 >>>>>>>> (JSR154Filter.java:170) >>>>>>>>> at >>>>>>>> org.mortbay.jetty.servlet.WebApplicationHandler=20 >>>>>>>> $CachedChain.doFilter(WebApplicationHandler.java:821) >>>>>>>>> at >>>>>>>> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch=20 >>>>>>>> (WebApplicationHandler.java:471) >>>>>>>>> at >>>>>>>> org.mortbay.jetty.servlet.ServletHandler.handle=20 >>>>>>>> (ServletHandler.java:568) >>>>>>>>> at org.mortbay.http.HttpContext.handle=20 >>>>>>>>> (HttpContext.java:1530) >>>>>>>>> at >>>>>>>> org.mortbay.jetty.servlet.WebApplicationContext.handle=20 >>>>>>>> (WebApplicationContext.java:633) >>>>>>>>> at org.mortbay.http.HttpContext.handle=20 >>>>>>>>> (HttpContext.java:1482) >>>>>>>>> at org.mortbay.http.HttpServer.service=20 >>>>>>>>> (HttpServer.java:909) >>>>>>>>> at >>>>>>>> org.mortbay.http.HttpConnection.service(HttpConnection.java:=20 >>>>>>>> 816) >>>>>>>>> at >>>>>>>> org.mortbay.http.HttpConnection.handleNext=20 >>>>>>>> (HttpConnection.java:982) >>>>>>>>> at >>>>>>>> org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) >>>>>>>>> at >>>>>>>> org.mortbay.http.SocketListener.handleConnection=20 >>>>>>>> (SocketListener.java:244) >>>>>>>>> at >>>>>>>> org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) >>>>>>>>> at >>>>>>>> org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) >>>>>>>> --=20 >>>>>> >>>>>> **************** CAUTION - Disclaimer ***************** >>>>>> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION =20 >>>>>> intended solely for the use of the addressee(s). If you are =20 >>>>>> not the intended recipient, please notify the sender by e-mail =20= >>>>>> and delete the original message. Further, you are not to copy, =20= >>>>>> disclose, or distribute this e-mail or its contents to any =20 >>>>>> other person and any such actions are unlawful. This e-mail =20 >>>>>> may contain viruses. Infosys has taken every reasonable =20 >>>>>> precaution to minimize this risk, but is not liable for any =20 >>>>>> damage you may sustain as a result of any virus in this e-=20 >>>>>> mail. You should carry out your own virus checks before =20 >>>>>> opening the e-mail or attachment. Infosys reserves the right =20 >>>>>> to monitor and review the content of all messages sent to or =20 >>>>>> from this e-mail address. Messages sent to or from this e-mail =20= >>>>>> address may be stored on the Infosys e-mail system. >>>>>> ***INFOSYS******** End of Disclaimer ********INFOSYS*** >>>>>> >>>