Thanks for your help. I'm glad this update will be in 1.0.5.
Jay On 6/23/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
Hi Eric, Westfall, Eric Curtis wrote: > 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 > Many thanks for the patch! I checked in the new version of PBAbstractImpl (in OJB_1_0_RELEASE branch) and close the issue in JIRA. > 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. I think this isn't possible, because you can't decide whether or not a started Iterator (Iterator it = broker.getIteratorByQuery(q)) will be used later. Only if - the user does a complete loop - the PB was closed (all connection resources closed) - the Iterator instance itself was GC it's allowed to close the underlying DB resources. Nevertheless, I look forward to your suggestions ;-) regards, Armin > 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] > > --------------------------------------------------------------------- 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]
