Issue #212: InternalException during producer/consumer scenario

Hi,

I'm trying to use objectdb in a producer/consumer scenario. Producer threads put message objects into a table while consumer threads remove the objects based on age, priority, etc.

There are 2 main motivations for using objectdb for this purpose rather than a queue or similar data structure:

1) The consumer can select the "next" object based on a range of potentially complex criteria.

2) The number of objects produced can be potentially exceed available memory so can be held on disk within the objectdb file.

I've created a simple test case based on a small message object with 5 producers and 5 consumers. The "next" object is selected based on a query with MaxResults set to 1 and LockMode set to PESSIMISTIC_WRITE. This results in the exceptions below.

Could you advise on the errors and whether it is even possible/advisable to use objectdb for this purpose?

Thanks for your help

Exception 1: WARN [Thread-5] (MultiThreadedTestRunner.java:276) - A test thread caused an exception.
rbccm.felix.framework.ApplicationException: Error taking message from ObjectDB queue
at rbccm.felix.objectdb.messaging.ObjectDbMessagePipe.take(ObjectDbMessagePipe.java:105)
at rbccm.felix.objectdb.test.TestObjectDB$ObjectDbConsumer.runTest(TestObjectDB.java:126)
at net.sourceforge.groboutils.junit.v1.TestRunnable.run(TestRunnable.java:154)
at java.lang.Thread.run(Thread.java:595)
Caused by: com.objectdb.o.InternalException: Unexpected internal exception
at com.objectdb.o.JPE.h(JPE.java:161)
at com.objectdb.o.ERR.f(ERR.java:68)
at com.objectdb.o.OBC.onObjectDBError(OBC.java:1386)
at com.objectdb.jpa.EMImpl.remove(EMImpl.java:377)
at rbccm.felix.objectdb.messaging.ObjectDbMessagePipe.take(ObjectDbMessagePipe.java:97)
... 3 more
Caused by: java.lang.NullPointerException
at com.objectdb.o.TYM.aq(TYM.java:840)
at com.objectdb.o.TVS.g(TVS.java:93)
at com.objectdb.jpa.EMImpl.remove(EMImpl.java:374)
... 4 more

Exception 2: WARN [Thread-10] (MultiThreadedTestRunner.java:276) - A test thread caused an exception.
rbccm.felix.framework.ApplicationException: Error putting message on objectdb queue
at rbccm.felix.objectdb.messaging.ObjectDbMessagePipe.put(ObjectDbMessagePipe.java:61)
at rbccm.felix.objectdb.test.TestObjectDB$ObjectDbProducer.runTest(TestObjectDB.java:110)
at net.sourceforge.groboutils.junit.v1.TestRunnable.run(TestRunnable.java:154)
at java.lang.Thread.run(Thread.java:595)
Caused by: com.objectdb.o._RollbackException: Failed to commit transaction: Unexpected internal exception
at com.objectdb.o.JPE.g(JPE.java:86)
at com.objectdb.o.ERR.f(ERR.java:59)
at com.objectdb.o.OBC.onObjectDBError(OBC.java:1386)
at com.objectdb.jpa.EMImpl.commit(EMImpl.java:259)
at rbccm.felix.objectdb.messaging.ObjectDbMessagePipe.put(ObjectDbMessagePipe.java:57)
... 3 more
Caused by: com.objectdb.o.InternalException: Unexpected internal exception
at com.objectdb.o.WSM.UX(WSM.java:179)
at com.objectdb.o.OBM.bH(OBM.java:896)
at com.objectdb.o.OBM.bF(OBM.java:801)
at com.objectdb.o.OBM.bD(OBM.java:711)
at com.objectdb.jpa.EMImpl.commit(EMImpl.java:256)
... 4 more
Caused by: java.lang.InterruptedException
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1177)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:272)
at com.objectdb.o.WSM.UX(WSM.java:171)
... 8 more

I know about at least one system that uses ObjectDB in a similar consumer / producer scenario, so it should be possible.

Could you please try setting the max-threads attribute in your configuration to 0? 1000?

If this doesn't affect - is it possible to get access to the test program (i.e. by posting it here or in a private support ticket)?

Thank you for the test program. The test demonstrates two problems:

• A query that starts before commit of another user and ends after that commit might succeed in locking an object that was locked by the committed transaction.
• Passing null to EntityManager's methods, such as remove, caused internal exception, instead of IllegalArgumentException, as required.

Version 2.2.1 fixes these problems. Thank you for this report.