Service Bean - Strange behaviour on redeploy

[rnicholson10]

I have a service bean, that spawns a thread, which reads messages from one queue and sends them out on another.

The thread is correctly stopped in both the stop and destroy methods of the bean.

Everything works as expected if it's a fresh startup of JBoss or the service bean is deployed for the first time. But when I re-deploy the service bean message receives are intermittent. I can see the messages that never get consumed in the MySQL DB. Restarting Jboss solves this problem.

I'm running this on AS5.0.0.GA. Has anyone else had a similar problem or have any solution to this. For the moment the solution is to restart JBoss every time I redeploy the bean.

P.S. I don't see any error messages in the log indicating there is a problem. However after a number of deploys I sometimes get a debug message "Thread pool class supplied is not an object name."

The following is the log when I send 10 messages to the queue. As you can see from the log only 4 messages are received (and there are only 7 responses (line delimited) in the log from the 10 sends I do). The other 6 are still in the DB. If I then restart JBoss the remaining 6 messages are read and the behaviour is once more normal.

2009-03-04 12:21:52,544 DEBUG [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (WorkerThread#1[172.16.66.231:59738]) No SecurityMetadadata was available for speQueueEngineIn, using default security config

2009-03-04 12:22:07,998 DEBUG [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (WorkerThread#1[172.16.66.231:59738]) No SecurityMetadadata was available for speQueueEngineIn, using default security config

2009-03-04 12:22:08,011 DEBUG [org.jboss.remoting.ServerInvoker] (WorkerThread#0[172.16.66.231:59737]) Thread pool class supplied is not an object name.
2009-03-04 12:22:08,014 INFO [STDOUT] (Thread-48) MessageRoutingBeanService - MessageReceived
2009-03-04 12:22:08,015 INFO [STDOUT] (Thread-48) ----------------
2009-03-04 12:22:08,015 INFO [STDOUT] (Thread-48) Received message
2009-03-04 12:22:08,015 INFO [STDOUT] (Thread-48) Routing to DS
2009-03-04 12:22:08,015 INFO [STDOUT] (Thread-48) ----------------
2009-03-04 12:22:08,015 INFO [STDOUT] (Thread-48) Time to test: 1236169328058
2009-03-04 12:22:08,016 DEBUG [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (Thread-48) No SecurityMetadadata was available for speQueueDownstreamOut, using default security config

2009-03-04 12:22:34,902 DEBUG [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (WorkerThread#1[172.16.66.231:59738]) No SecurityMetadadata was available for speQueueEngineIn, using default security config

2009-03-04 12:22:39,365 DEBUG [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (WorkerThread#0[172.16.66.231:59737]) No SecurityMetadadata was available for speQueueEngineIn, using default security config
2009-03-04 12:22:39,379 INFO [STDOUT] (Thread-48) MessageRoutingBeanService - MessageReceived
2009-03-04 12:22:39,379 INFO [STDOUT] (Thread-48) ----------------
2009-03-04 12:22:39,379 INFO [STDOUT] (Thread-48) Received message
2009-03-04 12:22:39,379 INFO [STDOUT] (Thread-48) Routing to DS
2009-03-04 12:22:39,380 INFO [STDOUT] (Thread-48) ----------------
2009-03-04 12:22:39,380 INFO [STDOUT] (Thread-48) Time to test: 1236169359426
2009-03-04 12:22:39,380 DEBUG [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (Thread-48) No SecurityMetadadata was available for speQueueDownstreamOut, using default security config

2009-03-04 12:22:47,535 INFO [STDOUT] (Thread-48) MessageRoutingBeanService - MessageReceived
2009-03-04 12:22:47,535 INFO [STDOUT] (Thread-48) ----------------
2009-03-04 12:22:47,536 INFO [STDOUT] (Thread-48) Received message
2009-03-04 12:22:47,536 INFO [STDOUT] (Thread-48) Routing to DS
2009-03-04 12:22:47,536 INFO [STDOUT] (Thread-48) ----------------
2009-03-04 12:22:47,536 INFO [STDOUT] (Thread-48) Time to test: 1236169367584

2009-03-04 12:22:55,115 INFO [STDOUT] (Thread-48) MessageRoutingBeanService - MessageReceived
2009-03-04 12:22:55,115 INFO [STDOUT] (Thread-48) ----------------
2009-03-04 12:22:55,116 INFO [STDOUT] (Thread-48) Received message
2009-03-04 12:22:55,116 INFO [STDOUT] (Thread-48) Routing to DS
2009-03-04 12:22:55,116 INFO [STDOUT] (Thread-48) ----------------
2009-03-04 12:22:55,116 INFO [STDOUT] (Thread-48) Time to test: 1236169375163

A similar thread runs fine from a servlet with no problems even after redeploy. Hence the reason I'm posting this in the EJB3.0 forum.

[jaikiran]

I have a service bean, that spawns a thread, which reads messages from one queue and sends them out on another.

Why not use an MDB instead?

[rnicholson10]

Because for the moment message order is critical, and allows us to design/test both source and destination systems knowing that message order is preserved.

Eventually we will use MDB's (for performance reasons) but they will still need to be sorted/processed at a central location, which will most likely be a service bean in our case.

Regardless of this fact, the issue clearly lies in that a service bean behaves differently depending on whether it is deployed for the first time or it is redeployed. This should not be the case, surely behaviour should be the same in either instance?

I guess the question I really want to ask is, is this a bug? Has anyone seen this type of behaviour before?