MDB processing freezes

[aubourg]

Hi,

I am using MDBs to have long tasks perform asynchronously, in a batch-like manner.

The MDB pool has a strict limit of 2 instances, so only 2 tasks are performed at the same time.

Quite often, JBoss just idles in the middle of processing. If I kill it and restart it, it restarts processing the queued JMS messages...

There is no apparent deadlock. Mysql is idle, with no statement being processed.

I get some warnings in the logs :
2004-10-05 08:48:00,331 WARN [org.jboss.tm.TransactionImpl] Transaction TransactionImpl:XidImpl [FormatId=257, GlobalId=upena.cfht.hawaii.edu//6732, BranchQual=] timed out. status=STATUS_ACTIVE
2004-10-05 08:48:03,245 WARN [org.jboss.tm.TransactionImpl] Transaction TransactionImpl:XidImpl [FormatId=257, GlobalId=upena.cfht.hawaii.edu//6733, BranchQual=] timed out. status=STATUS_ACTIVE

Any hint ?
Thanks
Eric

[lucsky]

You should adjust your transaction timeout to solve this problem in conf/jboss-service.xml (default is 300 ms). This timeout must be higher than the max time for a MDB (or EJB) to be processed. Below it is set to 5 minutes.

<mbean code="org.jboss.tm.TransactionManagerService"
 name="jboss:service=TransactionManager"
 xmbean-dd="resource:xmdesc/TransactionManagerService-xmbean.xml">

 <attribute name="TransactionTimeout">300000</attribute>

 <depends optional-attribute-name="XidFactory">jboss:service=XidFactory</depends>
 </mbean>

[aubourg]

Thanks, I'll try that.

In fact my main mistake is to have left my MDB with a Required transaction type. It does not need to be transactional by itself : I also changed the demarcation. Session beans below in the call chain are transactional and make shorter transactions.

Eric

[aubourg]

I still have the problem, although I increased the time-out, and removed the useless top transaction.

JBoss will just stop doing anything. I don't think I have a deadlock anywhere, and I have the problem in two instances of JBoss 3.2.5. One is running with MySQL and with MDBs, the other has Oracle and the entry point is just a session bean. The common point is that it occurs as I am updating thousands of objects (I make the updates in intermediate size transactions, the top method has "NotSupported", and calls a "Required" method that updates a batch of objects).

I am using Standard CMP 2.x EntityBean with commit-option A and default locking where needed, and each time it is possible a NoLock policy. Instance per Transaction gives me a decrease in performance, and I was not able to use the new container configuration cmp2.x jdbc2 pm, I get a class cast exception in JBoss code at deploy time -- it is retrieving a collection of objects and try to cast all of them as jdbc2.* objects. I imagined it was impossible to mix the new and old configurations, so I tried to configure all my beans with the new pm and still got the class cast exception.

Thanks for any hint !

Eric

[genman]

There's a MDB pool (how many MDB objects JBoss creates) and a MDB invocation pool, which is the number concurrent JMS sessions JBoss creates. Take a look at the singleton configuration and copy it.

Likely, you only have two MDB instances but JBoss is still creating 5-15 JMS sessions, all competing for them.