Return-Path: Delivered-To: apmail-geronimo-user-archive@www.apache.org Received: (qmail 21116 invoked from network); 31 May 2006 22:02:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 31 May 2006 22:02:28 -0000 Received: (qmail 63579 invoked by uid 500); 31 May 2006 22:02:27 -0000 Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org Received: (qmail 62981 invoked by uid 500); 31 May 2006 22:02:25 -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 62970 invoked by uid 99); 31 May 2006 22:02:25 -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 15:02:25 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [217.160.108.180] (HELO yukon.coderesearch.com) (217.160.108.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 May 2006 15:02:24 -0700 Received: (qmail 20370 invoked from network); 1 Jun 2006 00:01:47 +0100 Received: from p54b84403.dip0.t-ipconnect.de (HELO ?192.168.8.11?) (84.184.68.3) by coderesearch.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Jun 2006 00:01:47 +0100 Message-ID: <447E124E.60202@coderesearch.com> Date: Thu, 01 Jun 2006 00:01:50 +0200 From: =?ISO-8859-1?Q?Mario_R=FCbsam?= User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: user@geronimo.apache.org Subject: Re: Problem with Geronimo 1.0, PreparedStatements, pools and MaxDB References: <4690875E336998438DF43A78B8E38CF2E4F5DF@BLRKECMSG01.ad.infosys.com> <447DDAF4.902@coderesearch.com> <447E0D05.9070208@coderesearch.com> <6A41F021-91AB-4A5C-A07E-D14651480A6A@yahoo.com> In-Reply-To: <6A41F021-91AB-4A5C-A07E-D14651480A6A@yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ok, checked it out, will try tommorow upps it tomorrow now :-) Thanks, Mario David Jencks wrote: > > On May 31, 2006, at 2:39 PM, Mario R�bsam 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 what > has been released it should be pretty close. > >> >> I have AutoCommit always off because I need the transaction >> control so CommitBeforeAutocommit=true 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 >>> set up for debugging you could get the tranql connector source code >>> and trace through starting at >>> org.tranql.connector.jdbc.ConnectionHandle.commit(). I don't see how >>> the commit call wouldn't get eventually to the db, but knowing which >>> path execution takes should make it simpler to figure out what is >>> going on. >>> BTW someone was mentioning setting CommitBeforeAutocommit to true. >>> You should only set this on very buggy jdbc drivers that violate the >>> jdbc spec by not committing pending work when you set autocommit to >>> true (axion). Any real database should not need this set. >>> thanks >>> david jencks >>> On May 31, 2006, at 11:05 AM, Mario R�bsam wrote: >>>> Santosh, >>>> >>>> I did the development mostly on PostgreSQL. It's working there 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 >>>> 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 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: >>>>> Wednesday, May 31, 2006 11:10 PM >>>>> To: user@geronimo.apache.org >>>>> Subject: RE: Problem with Geronimo 1.0, PreparedStatements, pools >>>>> and MaxDB >>>>> Mario, >>>>> I agree that is not a solution , but atleast it points out that the >>>>> problem is cornered around TranQL ?? . (That's what I suspect !! If >>>>> so, then look smething on transQL config, or may need to chk for >>>>> next release :) Time for the gurus to dive in here !! :) >>>>> Thanks, >>>>> Santosh. >>>>> "Don't talk about yourself; it will be done when you leave. " >>>>> -----Original Message----- >>>>> From: Mario R�bsam [mailto:mr@coderesearch.com] Sent: Wednesday, >>>>> May 31, 2006 10:55 PM >>>>> To: user@geronimo.apache.org >>>>> Subject: Re: Problem with Geronimo 1.0, PreparedStatements, 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, then >>>>>> bring the server down -> & then chk ur DB, whether commit is >>>>>> happening the moment u trigger the server with a shutdown 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 = mConnection.createStatement(); >>>>> tStatement.executeUpdate("COMMIT"); >>>>> this is dirty but working, all commits are registered on the MaxDB >>>>> server >>>>> this is bypassing all the commit stuff in the Tranql Connection object >>>>> and the driver >>>>> So I find me now debugging the commit stuff in the Connection >>>>> instance. >>>>> Thanks, >>>>> Mario >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Santosh. >>>>>> "Don't talk about yourself; it will be done when you leave. " >>>>>> >>>>>> -----Original Message----- >>>>>> From: Mario R�bsam [mailto:mr@coderesearch.com] Sent: Wednesday, >>>>>> May 31, 2006 9:54 PM >>>>>> To: user@geronimo.apache.org >>>>>> Subject: Re: Problem with Geronimo 1.0, PreparedStatements, 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 commitbeforeautocommit=true >>>>>> >>>>>> Strange is that CommitBeforeAutocommit is a workaround for >>>>>> 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="true" in ur db deployment plan. >>>>>>> >>>>>>> Not sure, but may work, I had the same problem with delayed >>>>>>> EJB's commit. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Santosh. >>>>>>> "Don't talk about yourself; it will be done when you leave. " >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Mario R�bsam [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, 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 environment. Can >>>>>>>> you try commenting out that line and see if it makes a difference? >>>>>>>> >>>>>>>> If that doesn't help, can you put printlns near where you close the >>>>>>>> connections and just convince yourself that they're definitely >>>>>>>> being >>>>>>>> closed? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Aaron >>>>>>>> >>>>>>>> On 5/31/06, Mario R�bsam wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I testet a bit further and tried the following situations: >>>>>>>>> >>>>>>>>> I used a direct driver connection without the Geronimo pool --> >>>>>>>>> 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 the >>>>>>>>> direct driver connection I can see the commits in the 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�bsam wrote: >>>>>>>>>> Aaron, >>>>>>>>>> >>>>>>>>>> here is a stack trace attached, it hangs sometimes when >>>>>>>>>> calling the >>>>>>>>>> prepareStatement and sometimes when executing the statement >>>>>>>>>> and it's >>>>>>>>>> not always the same statement. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Mario >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Mario R�bsam wrote: >>>>>>>>>>> Aaron, >>>>>>>>>>> >>>>>>>>>>> connections are correctly closed. If they are returned to the >>>>>>>>>>> pool, >>>>>>>>>>> don't know? >>>>>>>>>>> >>>>>>>>>>> The code that opens/closes connections is a bit widespread >>>>>>>>>>> and wrapped >>>>>>>>>>> into a db abstraction layer. Here are some code fragments >>>>>>>>>>> collected >>>>>>>>>>> together without the try catches. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> open connection: >>>>>>>>>>> >>>>>>>>>>> InitialContext tCtx = new InitialContext(); >>>>>>>>>>> >>>>>>>>>>> mJDBCDataSource = (DataSource)tCtx.lookup( >>>>>>>>>>> pDataSource.getString(PDbDataSource.URL)); >>>>>>>>>>> >>>>>>>>>>> String tUser = pDataSource.getString(PDbDataSource.USER, null); >>>>>>>>>>> String tPass = pDataSource.getString(PDbDataSource.PASS, null); >>>>>>>>>>> >>>>>>>>>>> if (tUser != null) { >>>>>>>>>>> mConnection = mJDBCDataSource.getConnection(tUser, tPass); >>>>>>>>>>> } else { >>>>>>>>>>> mConnection = mJDBCDataSource.getConnection(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> mConnection.setAutoCommit(false); >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> call statements: >>>>>>>>>>> >>>>>>>>>>> String tStmtSQL = "SELECT ...."; >>>>>>>>>>> PreparedStatement tStmt = >>>>>>>>>>> mConnection.prepareStatement(tStmtSQL); >>>>>>>>>>> >>>>>>>>>>> tStmt.setString(1, tName); >>>>>>>>>>> ResultSet tRS = 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 >>>>>>>>>>>> pool, though >>>>>>>>>>>> it's hard to know without a stack trace. Also, can you post >>>>>>>>>>>> the code >>>>>>>>>>>> you're using to access the connection pool, execute the >>>>>>>>>>>> prepared >>>>>>>>>>>> statements, and close the connection? And what kind of >>>>>>>>>>>> component is >>>>>>>>>>>> running these prepared statements? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Aaron >>>>>>>>>>>> >>>>>>>>>>>> On 5/30/06, Mario R�bsam wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I have some serious problems when executing prepared >>>>>>>>>>>>> statements >>>>>>>>>>>>> on MaxDB with pooled connections managed by Tranql in >>>>>>>>>>>>> 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 milliseconds >>>>>>>>> before. >>>>>>>>>>>>> There is no CPU load on the Geronimo machine and also no 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 >>>>>>>>>>>>> without any >>>>>>>>>>>>> Problems. Also no problems with a client app and MaxDB that do >>>>>>>>>>>>> a batch import and use exactly the same statements but >>>>>>>>>>>>> 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="http://geronimo.apache.org/xml/ns/j2ee/connector-1.0"> >>>>>>>>>>>>> >>>>>>>>>>>> xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.0"> >>>>>>>>>>>>> mysql/sapdbc/7.6/jar >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> javax.sql.DataSource >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> jdbc/default >>>>>>>>>>>>> >>>>>>>>>>>> name="UserName">sse >>>>>>>>>>>>> >>>>>>>>>>>> name="Password">sse >>>>>>>>>>>>> >>>>>>>>>>>> name="CommitBeforeAutocommit">false >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> name="Driver">com.sap.dbtech.jdbc.DriverSapDB >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> name="ExceptionSorterClass">org.tranql.connector.AllExceptionsAreFatalSorter >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> name="ConnectionURL">jdbc:sapdb://192.168.8.3/service >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 100 >>>>>>>>>>>>> 50 >>>>>>>>>>>>> >>>>>>>>>>>>> 60000 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 60 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Mario >>>>>>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>>> DEBUG DATE=2006-05-30 TIME=13:42:22:046 CATEGORY=cpa.db >>>>>>>>> SOURCE=mr@aeon:CDbContext.getPreparedStatement() SID=cpa.1-1-1.cpa >>>>>>>>> MESSAGE=prepare statement "SELECT >>>>>>>>> TbRegistryValues.TcValueText,TbRegistryValues.TcValueLineNo FROM >>>>>>>>> TbRegistry,TbRegistryValues WHERE >>>>>>>>> ((TbRegistry.TcEntityId=TbRegistryValues.TcEntityId) AND >>>>>>>>> (TbRegistry.TcDomain=?)) ORDER BY TbRegistryValues.TcValueLineNo" >>>>>>>>>> DEBUG DATE=2006-05-30 TIME=17:38:50:421 CATEGORY=cpa.db >>>>>>>>> SOURCE=mr@aeon:CDbContext.getPreparedStatement() SID=cpa.1-1-1.cpa >>>>>>>>> MESSAGE=prepared statement >>>>>>>>> "org.tranql.connector.jdbc.PreparedStatementHandle@1728a26" >>>>>>>>>> 13:42:22,046 WARN [GeronimoConnectionEventListener] >>>>>>>>> connectionErrorOccurred called with null >>>>>>>>>> com.sap.dbtech.jdbc.exceptions.ConnectionException: [-708] >>>>>>>>>> Timeout >>>>>>>>>> at >>>>>>>>> com.sap.dbtech.jdbc.ConnectionSapDB.execute(ConnectionSapDB.java:554) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> com.sap.dbtech.jdbc.CallableStatementSapDB.sendCommand(CallableStatementSapDB.java:1764) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> com.sap.dbtech.jdbc.StatementSapDB.sendSQL(StatementSapDB.java:808) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> com.sap.dbtech.jdbc.CallableStatementSapDB.doParse(CallableStatementSapDB.java:233) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> com.sap.dbtech.jdbc.CallableStatementSapDB.constructor(CallableStatementSapDB.java:186) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> com.sap.dbtech.jdbc.CallableStatementSapDB.(CallableStatementSapDB.java:88) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> com.sap.dbtech.jdbc.ConnectionSapDB.prepareStatement(ConnectionSapDB.java:803) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> org.tranql.connector.jdbc.ConnectionHandle.prepareStatement(ConnectionHandle.java:231) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> com.coderesearch.cpa.db.jdbc.CDbContext.getPreparedStatement(CDbContext.java:1131) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> com.coderesearch.cpa.reg.db.jdbc.CDbBrokerRegistry.lookup(CDbBrokerRegistry.java:129) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> com.coderesearch.cpa.reg.db.jdbc.CDbBrokerRegistry.query(CDbBrokerRegistry.java:430) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> com.coderesearch.cpa.naming.CPANamingContextDb.lookup(CPANamingContextDb.java:116) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> com.coderesearch.cpa.reg.CPARegistryContext.lookup(CPARegistryContext.java:256) >>>>>>>>> >>>>>>>>>> at >>>>>>>>>> com.coderesearch.cpa.reg.Registry.lookupInt(Registry.java:199) >>>>>>>>>> at >>>>>>>>> com.coderesearch.abp.index.srv.CRPIndex.countLogin(CRPIndex.java:140) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> com.coderesearch.abp.index.srv.CRPIndex.process(CRPIndex.java:266) >>>>>>>>>> at >>>>>>>>> com.coderesearch.abp.found.srv.MainServlet.process(MainServlet.java:482) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> com.coderesearch.abp.found.srv.MainServlet.doPost(MainServlet.java:610) >>>>>>>>> >>>>>>>>>> at >>>>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:615) >>>>>>>>>> at >>>>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:688) >>>>>>>>>> at >>>>>>>>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) >>>>>>>>> >>>>>>>>>> at >>>>>>>>>> org.mortbay.http.HttpContext.handle(HttpContext.java:1530) >>>>>>>>>> at >>>>>>>>> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) >>>>>>>>> >>>>>>>>>> at >>>>>>>>>> org.mortbay.http.HttpContext.handle(HttpContext.java:1482) >>>>>>>>>> at org.mortbay.http.HttpServer.service(HttpServer.java:909) >>>>>>>>>> at >>>>>>>>> org.mortbay.http.HttpConnection.service(HttpConnection.java:816) >>>>>>>>>> at >>>>>>>>> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) >>>>>>>>>> at >>>>>>>>> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) >>>>>>>>> >>>>>>>>>> at >>>>>>>>> org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) >>>>>>>>>> at >>>>>>>>> org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) >>>>>>>>> -- >>>>>>> >>>>>>> **************** CAUTION - Disclaimer ***************** >>>>>>> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION >>>>>>> intended solely for the use of the addressee(s). If you are not >>>>>>> the intended recipient, please notify the sender by e-mail and >>>>>>> delete the original message. Further, you are not to copy, >>>>>>> disclose, or distribute this e-mail or its contents to any other >>>>>>> person and any such actions are unlawful. This e-mail may contain >>>>>>> viruses. Infosys has taken every reasonable precaution to >>>>>>> minimize this risk, but is not liable for any damage you may >>>>>>> sustain as a result of any virus in this e-mail. You should carry >>>>>>> out your own virus checks before opening the e-mail or >>>>>>> attachment. Infosys reserves the right to monitor and review the >>>>>>> content of all messages sent to or from this e-mail address. >>>>>>> Messages sent to or from this e-mail address may be stored on the >>>>>>> Infosys e-mail system. >>>>>>> ***INFOSYS******** End of Disclaimer ********INFOSYS*** >>>>>>> >>>> > >