Well these are just several wild guesses, but I am curious.
If you generate the SalesRank arraylist without reference to the db, like
from random numbers, do you _ever_ get the hang?
I assume getSalesRankData closes whatever resultsets and statements it
uses? How about the connection?
I don't know much about postgres but have heard rumors it has snapshot
isolation/versioning similar to firebird/interbase. If so, have you
committed after your (presumably read only) query in getSalesRankData?
Thanks
david jencks
On 2001.07.23 17:37:50 -0400 David Esposito wrote:
> Hello all,
>
> Let's start with the summary of my problem: My client application hangs
> after a while when working with CMP Entity beans
>
> Environment:
>
> JBOSS is running on AppServer.mycompany.com (2.4.0.6 Beta) on Sun JDK
> 1.3.0_03
>
> PostGreSQL 7.1.2 is running on DBServer.mycompany.com
>
> My client application is ALSO running on DBServer.mycompany.com on Sun
> JDK
> 1.3.0_03
>
> so it makes a nifty little out-and-back loop ... my client opens up a
> connection to JBOSS over the network, then JBOSS contacts the DB via JDBC
> over the network ...
>
> Here's the pseudocode of what happens:
>
> void run()
> {
> //Perform some aggregate operation on the rows in my table
> //This is a straight SQL query executed over a direct JDBC
> connection
> ArrayList salesRank = getSalesRankData();
>
> //Get all of the records from my table (~1500 records)
> Enumeration beans = myHome.findAll();
>
> while(beans.hasMoreElements())
> {
> //Get the new value for this row
> Float curSalesRank = (Float)salesRank.get(i++);
>
> //Get the remote interface
> MyBean curBean = beans.nextElement();
>
> //Set the sales rank
> curBean.setSalesRank(curSalesRank);
>
> }
>
> }
>
> The problem is that, without warning, the while() loop gets stuck at the
> setSalesRank() call ... I installed OptimizeIt which was able to reveal
> the
> following stack trace:
>
> 100.0% - 653169 ms - java.net.SocketInputStream.socketRead()
> 100.0% - 653169 ms - java.net.SocketInputStream.read()
> 100.0% - 653169 ms - java.io.BufferedInputStream.fill()
> 100.0% - 653169 ms - java.io.BufferedInputStream.read()
> 100.0% - 653169 ms - java.io.DataInputStream.readByte()
> 100.0% - 653169 ms -
> sun.rmi.transport.StreamRemoteCall.executeCall()
> 100.0% - 653169 ms - sun.rmi.server.UnicastRef.invoke()
> 100.0% - 653169 ms -
> org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_Stub.invoke()
> 100.0% - 653169 ms -
> org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer()
> 100.0% - 653169 ms -
> org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invoke()
> 100.0% - 653169 ms - $Proxy5.setSalesRank()
> 100.0% - 653169 ms -
> com.mycompany.CatalogItemSalesRankHandler.handleEvent()
> 100.0% - 653169 ms -
> com.mycompany.EventServer.doJob()
> 100.0% - 653169 ms -
> com.mycompany.EventServer.run()
> 100.0% - 653169 ms -
> java.lang.Thread.run()
>
>
>
> Back on the JBOSS box, after at least a minute or so, the following
> exception shows up:
>
> [Catalog_Item] XAException: tx=XidImpl [FormatId=257,
> GlobalId=timqa1.amsnet.com//193493, BranchQual=] errorCode=XA_UNKNOWN(0)
> [Catalog_Item] javax.transaction.xa.XAException: Rollback failed: An I/O
> error has occured while flushing the output - Exception:
> java.io.IOException: Broken pipe
> [Catalog_Item] Stack Trace:
> [Catalog_Item]
> [Catalog_Item] java.io.IOException: Broken pipe
> [Catalog_Item] at java.net.SocketOutputStream.socketWrite(Native Method)
> [Catalog_Item] at
> java.net.SocketOutputStream.write(SocketOutputStream.java:83)
> [Catalog_Item] at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:72)
> [Catalog_Item] at
> java.io.BufferedOutputStream.flush(BufferedOutputStream.java:130)
> [Catalog_Item] at org.postgresql.PG_Stream.flush(PG_Stream.java:414)
> [Catalog_Item] at org.postgresql.Connection.ExecSQL(Connection.java:464)
> [Catalog_Item] at org.postgresql.Connection.ExecSQL(Connection.java:400)
> [Catalog_Item] at
> org.postgresql.jdbc2.Connection.rollback(Connection.java:242)
> [Catalog_Item] at
> org.jboss.pool.jdbc.xa.wrapper.XAResourceImpl.rollback(XAResourceImpl.java:2
> 17)
> [Catalog_Item] at
> org.jboss.tm.TxCapsule.rollbackResources(TxCapsule.java:1539)
> [Catalog_Item] at org.jboss.tm.TxCapsule.rollback(TxCapsule.java:394)
> [Catalog_Item] at
> org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:88)
> [Catalog_Item] at
> org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.
> java:343)
> [Catalog_Item] at
> org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
> [Catalog_Item] at
> org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:12
> 7)
> [Catalog_Item] at
> org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)
> [Catalog_Item] at
> org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:349)
> [Catalog_Item] at
> org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerI
> nvoker.java:390)
> [Catalog_Item] at java.lang.reflect.Method.invoke(Native Method)
> [Catalog_Item] at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241)
> [Catalog_Item] at sun.rmi.transport.Transport$1.run(Transport.java:142)
> [Catalog_Item] at java.security.AccessController.doPrivileged(Native
> Method)
> [Catalog_Item] at
> sun.rmi.transport.Transport.serviceCall(Transport.java:139)
> [Catalog_Item] at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:443)
> [Catalog_Item] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:6
> 43)
> [Catalog_Item] at java.lang.Thread.run(Thread.java:484)
> [Catalog_Item] End of Stack Trace
>
> (I have more stack traces ... in fact, it generated about 8 of them ...
> all
> seem to be related to some connectivity issue between Postgres and JBOSS)
> ... i'll forward them along if you'd like more ...
>
> I've played with the standardjboss.xml to adjust the bean cache sizes and
> this has had no effect on the hanging ...
>
> So there are a couple of questions:
>
> 1) What is causing JBOSS to hang with, in my opinion, pretty lightweight
> stuff ... If it's related to the DB driver, why doesn't an exception get
> propagated back to my client app?
>
> 2) What could be causing a broken pipe between PG and JBOSS ... My guess
> is
> that it has to do with #1 and the fact that there has been too much
> inactivity between PG and JBOSS and PG has decided to drop the connection
> ... I'm going under the assumption that #2 is a result of #1 ...
>
> Luckily, I can replicate this problem fairly quickly ... (usually it
> won't
> go for more than an hour or two without getting stuck) ... so if there is
> anything that you can think of that I should be trying, please let me
> know
> and I'll try to run some more tests ASAP ..
>
> -Dave
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
