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]
