geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Rübsam ...@coderesearch.com>
Subject Re: Problem with Geronimo 1.0, PreparedStatements, pools and MaxDB
Date Wed, 31 May 2006 22:01:50 GMT
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 <mr@coderesearch.com> 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 <mr@coderesearch.com>
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:
>>>>>>>>>>>>>
>>>>>>>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>>>>>>>> <connector configId="user/database-pool-jdbc/default/1/car"
>>>>>>>>>>>>> xmlns="http://geronimo.apache.org/xml/ns/j2ee/connector-1.0">
>>>>>>>>>>>>>      <dep:dependency
>>>>>>>>>>>>> xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.0">
>>>>>>>>>>>>>          <dep:uri>mysql/sapdbc/7.6/jar</dep:uri>
>>>>>>>>>>>>>      </dep:dependency>
>>>>>>>>>>>>>      <resourceadapter>
>>>>>>>>>>>>>          <outbound-resourceadapter>
>>>>>>>>>>>>>              <connection-definition>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> <connectionfactory-interface>javax.sql.DataSource</connectionfactory-interface>

>>>>>>>>>
>>>>>>>>>>>>>                  <connectiondefinition-instance>
>>>>>>>>>>>>>                      <name>jdbc/default</name>
>>>>>>>>>>>>>                      <config-property-setting
>>>>>>>>>>>>> name="UserName">sse</config-property-setting>
>>>>>>>>>>>>>                      <config-property-setting
>>>>>>>>>>>>> name="Password">sse</config-property-setting>
>>>>>>>>>>>>>                      <config-property-setting
>>>>>>>>>>>>> name="CommitBeforeAutocommit">false</config-property-setting>
>>>>>>>>>>>>>                      <config-property-setting
>>>>>>>>>>>>>
>>>>>>>>> name="Driver">com.sap.dbtech.jdbc.DriverSapDB</config-property-setting>

>>>>>>>>>
>>>>>>>>>>>>>                      <config-property-setting
>>>>>>>>>>>>>
>>>>>>>>> name="ExceptionSorterClass">org.tranql.connector.AllExceptionsAreFatalSorter</config-property-setting>

>>>>>>>>>
>>>>>>>>>>>>>                      <config-property-setting
>>>>>>>>>>>>>
>>>>>>>>> name="ConnectionURL">jdbc:sapdb://192.168.8.3/service</config-property-setting>

>>>>>>>>>
>>>>>>>>>>>>>                      <connectionmanager>
>>>>>>>>>>>>>                          <local-transaction/>
>>>>>>>>>>>>>                          <single-pool>
>>>>>>>>>>>>>                              <max-size>100</max-size>
>>>>>>>>>>>>>                              <min-size>50</min-size>
>>>>>>>>>>>>>
>>>>>>>>>>>>> <blocking-timeout-milliseconds>60000</blocking-timeout-milliseconds>

>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> <idle-timeout-minutes>60</idle-timeout-minutes>
>>>>>>>>>>>>>                              <match-one/>
>>>>>>>>>>>>>                          </single-pool>
>>>>>>>>>>>>>                      </connectionmanager>
>>>>>>>>>>>>>                  </connectiondefinition-instance>
>>>>>>>>>>>>>              </connection-definition>
>>>>>>>>>>>>>          </outbound-resourceadapter>
>>>>>>>>>>>>>      </resourceadapter>
>>>>>>>>>>>>> </connector>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.<init>(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***
>>>>>>>
>>>>
> 
> 


Mime
View raw message