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/jbos...
<
http://fisheye.jboss.com/browse/JBossAS/trunk/testsuite/src/main/org/jbos...
(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-Test...
>>>
>>> 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(a)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(a)redhat.com