[martin.wickus]

Two developers tried independently to reproduce this problem in our development environment, but no success. We've thusfar only seen it in our production and (thereafter) testing environments. The setups (firewall restrictions, machine architecture, etc) in those environment are very different from our "run everything on a windows box" development environment. I cannot rule out environmental/configuration issues our side, thus I'm not confident to claim this is a bug in JBM.

I am going to upgrade to JBoss EAP 4.3 standard and deploy for testing.

Tim, I think you could close the associated Jira as unable to reproduce. I'll let you know how it goes with JBoss EAP 4.3.

Regards,
Wickus

[timfox]

Wickus:

I have inspected the code and I believe I can see potential for a race condition, more here http://jira.jboss.org/jira/browse/JBMESSAGING-1245

[timfox]

Looking at http://jira.jboss.org/jira/browse/JBMESSAGING-1245, I believe I can see a potential race condition which might give the behaviour observed.

[martin.wickus]

Hi Tim

Glad to hear (that we tracked it down that is). Keep us posted how the testing goes.

Regards,
Wickus

[timfox]

Due to the non deterministic nature of thread scheduling this is hard to replicate since it requires, the call to changeRate to come in at that specific point, AFAICT this will only happen after the consumer is first created, so the condition is far more likely to occur if you are creating and closing consumers frequently.

However I can easily get the condition to occur by inserting an artifical Thread.sleep(10) here:

if (sendCount == num)
 {

*** here
 try
 {
 Thread.sleep(10);
 }
 catch (Exception e)
 {

 }
** end here


 clientAccepting = false;

 firstTime = false;
 }

Adding proper synchronization around changeRate solves the problem,