[jboss-dev] Re: org.jboss.test.timer.test.BasicTimerUnitTestCase.testMDBTimer

[Tim Fox]

Here's my irc conversation with Jesper on this subject:

(14:24:42) *jpederse:* jbossfox: Shouldn't receiveNoWait() sync up with 
the server side before returning ?
(14:25:24) *jpederse:* jbossfox: see 
http://fisheye.jboss.com/browse/JBossAS/trunk/testsuite/src/main/org/jboss/test/timer/test/BasicTimerUnitTestCase.java?r1=77774&r2=77970 
<http://fisheye.jboss.com/browse/JBossAS/trunk/testsuite/src/main/org/jboss/test/timer/test/BasicTimerUnitTestCase.java?r1=77774&r2=77970>
(14:28:44) *jpederse:* jbossfox: messages are leaking into the testcase 
making it fail...
(14:29:07) *jpederse:* jbossfox: So if what Clebert told me - it should 
pass on the next run
(14:29:48) *jbossfox:* jpederse: ner, there's no obligation for 
receiveNoWait to call the server each time
(14:29:55) *jbossfox:* jpederse: it did in jbossmq, but it doesn't in jbm
(14:30:17) *jpederse:* jbossfox: yeah, that is why the testcase started 
failing
(14:30:40) *jpederse:* jbossfox: it is documented somewhere in the JBM doc ?
(14:31:16) *jbossfox:* jpederse: i don't think so. this is legal behaviour
(14:31:19) *jpederse:* jbossfox: Looking at the JMS API JavaDoc you dont 
get that behavior
(14:31:47) *jpederse:* jbossfox: I mean that the client doesn't sync 
with the server
(14:31:52) *jbossfox:* jpederse: there's nothing in JMS that requires 
you to go to server each time
(14:32:11) *jbossfox:* jpederse: there have been several threads about 
this on the forums
(14:32:26) *jbossfox:* jpederse: going to the server each time would be 
extremely slow
(14:32:49) *jpederse:* jbossfox: yeah I know
(14:32:55) *jbossfox:* jpederse: if the test is assuming that 
receiveNoWait goes to the server each time, then the test is broken imho
(14:33:32) *jpederse:* jbossfox: I added the receiveNoWait() in order to 
clear the queue before running the rest of the testcase
(14:33:59) *jbossfox:* jpederse: yeah that's not guaranteed to work. you 
should use receive(timeout)
(14:34:25) *jpederse:* jbossfox: yeah, that is the code now
(14:34:41) *jbossfox:* jpederse: JMS just says receiveNoWait should 
return a message if one is "available" but does not define what 
available means
(14:34:52) *jpederse:* jbossfox: ok :)
(14:35:00) *jbossfox:* jpederse: most messaging systems interpret 
available to mean "in the client side buffer"
(14:35:10) *jbossfox:* jpederse: since otherwise it would be horribly slow
(14:35:22) *jpederse:* jbossfox: I guess that JBM is client side and 
JBossMQ was server side
(14:35:41) *jbossfox:* jpederse: yes jbossmq was unusual in it went to 
the server each time
(14:36:20) *jpederse:* jbossfox: I got the reason for the change -- 
learn something new each day :)
(14:36:42) *jpederse:* jbossfox: Thanks for taking the time, Tim !
(14:36:48) *jbossfox:* jpederse: you can think of receiveNoWait like a 
non blocking read
(14:37:08) *jbossfox:* jpederse: like a non blocking socket read - it 
will only return with a message if one is available right there right noe
(14:37:23) *jpederse:* jbossfox: yeah
(14:37:33) *jbossfox:* jpederse: but there could be a message in transit
(14:38:08) *jpederse:* jbossfox: which is properly the thing going on, 
since there is a message in the queue
(14:38:29) *jpederse:* jbossfox: well, at least one ;)
(14:38:46) *jbossfox:* jpederse: it's like non blocking socket read will 
return null if there's nothing in the tcp buffer
(14:39:00) *jbossfox:* jpederse: but there might well be data in transit

Adrian Brock wrote:
> I was expecting to see the clearing of the queue
> in the test setup. ;-)
>
> Since JBoss Messaging behaves differently on receiveNoWait()
> to JBossMQ (which always checks the server if their is nothing
> locally buffered), I've changed the clearing of the queue
> to use receive(1000) instead.
>
> Let's see whether that solves the problem.
>
> This test would be less brittle to garbage lying around from other tests
> if the reply queue was a temporary queue?
>
> On Thu, 2008-09-04 at 14:24 +0200, Carlo de Wolf wrote:
>   
>> Test is a persistent reply coming in, while the bean sends a
>> non-persistent reply, so definitely the wrong message.
>>
>> The test tries to clear the queue with receiveNoWait, but that only
>> clears the client side of the queue. (I think it was you who mentioned
>> that some time ago.) So while the receiving end is fully established
>> that wrong message is dropped in the client side queue.
>>
>> Carlo
>>
>> On Thu, 2008-09-04 at 13:15 +0200, Adrian Brock wrote:
>>     
>>> Isn't it just messages leaking across tests?
>>>
>>> java.lang.NumberFormatException: Message property 'UNIQUE_ID' not set.
>>> 	at org.jboss.jms.message.JBossMessage.getIntProperty(JBossMessage.java:636)
>>>
>>> I'll bet clearing the queue at the start of the test 
>>> (and end so it doesn't leak messages when it fails)
>>> fixes the problem.
>>>
>>> But we still need to locate the "dirty" test that is leaving messages
>>> lying around.
>>>
>>> On Thu, 2008-09-04 at 14:02 +0300, Dimitris Andreadis wrote:
>>>       
>>>> We have been stuck on this testcase that passes locally, but fails on hudson for a long time 
>>>> now:
>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-TestSuite-sun15/878/testReport/org.jboss.test.timer.test/BasicTimerUnitTestCase/testMDBTimer/
>>>>
>>>> I don't know if it's related to the fact that a different messaging provider is used in AS5 
>>>> (JBoss Messaging vs JBossMQ), but if you have any idea how to fix it, please give a hand.
>>>>
>>>> https://jira.jboss.org/jira/browse/JBAS-5866
>>>>
>>>> Thanks
>>>>         
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>     


-- 
Tim Fox
Messaging Lead
JBoss - a division of Red Hat

http://jbossfox.blogspot.com/

irc.freenode.net#jbossmessaging

fox at redhat.com