Here is a JIRA issue which describes the problem and the fix along with the fixed version of PersistenceBrokerAbstractImpl attached.
http://issues.apache.org/jira/browse/OJB-114 It seems like if there was a way to get rid of the use of the finalize() method in this context that would be a superior long term solution. That way you wouldn't have to worry about the cost of both running the finalize method and synchronizing access to the underlying collections. However that may or may not be possible. I'm not really too familiar with the codebase ;) Thanks, Eric > -----Original Message----- > From: Jay Sissom [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 22, 2006 11:38 AM > To: OJB Users List > Subject: Re: ArrayIndexOutOfBoundsException > > 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( Un > known > > > > > > > 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.notifiyStateLis te > ner(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/or g/ > apache/ojb/broker/util/IdentityArrayList.java?view=log > > > http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/or g/ > 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 (U > nknown > > > > > > Source) > > > at > > > > org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unkno wn > > > Source) > > > at > > > > org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction (U > nknown > > > > > > Source) > > > at > > > > org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction (U > nknown > > > > > > Source) > > > at > > > > org.springframework.orm.ojb.PersistenceBrokerTransactionManager.doCommit (P > ersistenceBrokerTransactionManager.java:251) > > > > > > at > > > > org.springframework.transaction.support.AbstractPlatformTransactionManag er > .processCommit(AbstractPlatformTransactionManager.java:500) > > > > > > at > > > > org.springframework.transaction.support.AbstractPlatformTransactionManag er > .commit(AbstractPlatformTransactionManager.java:473) > > > > > > at > > > > org.springframework.transaction.interceptor.TransactionAspectSupport.doC om > mitTransactionAfterReturning(TransactionAspectSupport.java:267) > > > > > > at > > > > org.springframework.transaction.interceptor.TransactionInterceptor.invok e( > TransactionInterceptor.java:106) > > > > > > at > > > > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Ref le > ctiveMethodInvocation.java:170) > > > > > > at > > > > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAo pP > roxy.java:176) > > > > > > at $Proxy87.postMainEntries(Unknown Source) > > > at > > > > org.kuali.module.gl.batch.PosterEntriesStep.performStep(PosterEntriesSte p. > java:44) > > > > > > at > > > > org.kuali.core.batch.CommandLineStepRunner.main(CommandLineStepRunner.ja va > :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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
