WMQJCAResourceAdapter - Thread hung error while starting EJB application

[Suhel Sayyed]

Hello everyone,

I am facing a strange error while deploying and starting an EJB application which has message driven beans configured. I am using XL Deploy (Deploy IT) to deploy it to Websphere Application Server 8.

Everything goes well, till we reach to the stage where application is to be started.

There are multiple message-driven ids configured in ejb-jar.xml (which is quite obvious) and <activation-config> is specified for each message-driven id. Now what happens is that <activation-config> is read and activated for first 4 message-driven ids. Then for the fifth message-driven id it waits and waits and finally starts giving following exception -

WSVR0605W: Thread "WMQJCAResourceAdapter : 8" (0000002e) has been active for 686641 milliseconds and may be hung. There is/are 1 thread(s) in total in the server that may be hung.

I know that WAS must be waiting for response and thus it goes into hung state.

Now this is interesting. The code which I am deploying, is there for long and has not changed. It is working in production region quite well. Recently there was some MQ port change in test region (where I am deploying).

My questions are as following -

1. What configuration change could help in getting rid of this issue?

2. Do you think, changing configuration in code will serve any purpose.

3. Is it possible that if there are a large number of messages in queue, EAR start can go for a toss?

Any help would be highly appreciated.

Suhel

[Claude Moore]

I would try to modify my code and use only the problematic JMS Topic/Queue so that I could verify if the issue may be related only to that source - for example, like you suggested, a large number of messages may exhaust appserver's memory capabilities - by isolating it.
I used to see hung threads in websphere when I had some leakage of resources - tipically connections in a Connection Pool, which are obtained but never released. Maybe a big number may lead quickly to exhaustion of available JMS connections, if there's some leakage.