Unfortunately, I don't have a simple, repeatable test case right now. This happens on a long running process and is related to the GC.
We took the code in CVS mentioned in your email and tried it, but it didn't solve the problem. We added some synchronizing to it and that did solve it. This problem might have started when we switched to JDK 1.5. It happens on a Mac and Linux so it isn't based on a specific implementation. I'm not sure about this, but it could be when this started. We'll send the patch we made to make the problem go away a little later. Thanks Jay On 6/22/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
Hi Jay, Jay Sissom wrote: > Hello, I am using OJB 1.0.4 and Spring 1.2.8. A spring interceptor is > handling transactions for me. All my OJB code is written using the > Spring PersistenceBrokerDaoSupport class. > > I have a long running process that does quite a bit of data > manipulation. It is a single threaded app that starts up Spring, does > it's work, then ends. It runs from the command line. > > All the database work happens in a single Spring managed transaction > against a single Oracle database. > > If this process runs for a while, I will receive an exception in the > log like this: > If it isn't a concurrency issue (and it seems not, because you said it's a single threaded app) it seems to be a bug in OJB. > 2006-06-21 18:59:27,619 [Finalizer] ERROR > org.apache.ojb.broker.accesslayer.ReportQueryRsIterator :: Error when > try to remove RsIterator resource listener > java.lang.ArrayIndexOutOfBoundsException: 107 > at > org.apache.ojb.broker.core.PersistenceBrokerAbstractImpl.removeListener(Unknown > This seems to indicate a concurrency problem. The ArrayIndexOutOfBoundsException could only happen when at the same time different threads remove listener objects. I think it could be that the FinalizerThread conflicts with the application thread, because modern gc's do no longer stop all app threads before gc run. Anyway I can't reproduce your problem on my system. I run a test case (against hsql and maxDB) which does many PB.getIteratorByQuery(q) calls without iteration of all objects. This will prevent OJB from cleanup RsIterator resources (because the iterator still has next objects). I can see many info-log statements when RsIterator was finalized, but I never get your concurrency issue. The GC runs within the PB.getIteratorByQuery(q) calls but I don't know if app thread was stopped between the GC runs. > Source) > at org.apache.ojb.broker.accesslayer.RsIterator.release(Unknown > Source) > at > org.apache.ojb.broker.accesslayer.RsIterator.releaseDbResources(Unknown > Source) > at org.apache.ojb.broker.accesslayer.RsIterator.finalize(Unknown > Source) > at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method) > at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83) > at java.lang.ref.Finalizer.access$100(Finalizer.java:14) > at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160) > > This might happen many times during the process. The process doesn't > stop running after one of these exceptions. yep, these exceptions are caught (and logged) by class RsIterator, because call RsIterator.releaseDbResources cause "only" a resource cleanup issue. > At the end of the run, > when Spring should commit the transaction, it does a rollback with > this message: > > 2006-06-21 19:09:19,786 [main] ERROR > org.springframework.orm.ojb.PersistenceBrokerTransactionManager :: > Commit exception overridden by rollback exception > java.lang.NullPointerException > at > org.apache.ojb.broker.core.PersistenceBrokerAbstractImpl.notifiyStateListener(Unknown > This is strange. But maybe it's a subsequent error caused by the concurrency issue above. Currently we don't use synchronized methods in listener handling (because these methods are very often called). For OJB 1.0.5 I reworked this section some time ago (using IdentityArrayList for listener instead of array). If you replace the following sources in your 1.0.4 release source and recompile the OJB-jar (call "ant jar" on command line in db-ojb directory) we can try to fix this for the upcoming release. http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/util/IdentityArrayList.java?view=log http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/core/PersistenceBrokerAbstractImpl.java?view=log Or if possible get latest OJB version from SVN OJB_1_0_RELEASE branch, build OJB jar and run your test again. > It looks like the garbage collector is trying to collect an object > that is being used. Has anyone seen this before? Think this is the first time. > Any ideas how it > can be fixed? Maybe we have to synchronize some methods in PersistenceBrokerAbstractImpl - e.g. #removeListener regards, Armin > Source) > at > org.apache.ojb.broker.core.PersistenceBrokerAbstractImpl.fireBrokerEvent(Unknown > > Source) > at > org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unknown > Source) > at > org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unknown > > Source) > at > org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unknown > > Source) > at > org.springframework.orm.ojb.PersistenceBrokerTransactionManager.doCommit(PersistenceBrokerTransactionManager.java:251) > > at > org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:500) > > at > org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:473) > > at > org.springframework.transaction.interceptor.TransactionAspectSupport.doCommitTransactionAfterReturning(TransactionAspectSupport.java:267) > > at > org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106) > > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170) > > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176) > > at $Proxy87.postMainEntries(Unknown Source) > at > org.kuali.module.gl.batch.PosterEntriesStep.performStep(PosterEntriesStep.java:44) > > at > org.kuali.core.batch.CommandLineStepRunner.main(CommandLineStepRunner.java:63) > > 2006-06-21 19:09:19,787 [main] ERROR > org.apache.ojb.broker.core.PersistenceBrokerImpl :: Broker is still in > PB-transaction, do automatic abort before close! > > It looks like the garbage collector is trying to collect an object > that is being used. Has anyone seen this before? Any ideas how it > can be fixed? > > Thanks > Jay > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
