You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Keith W <ke...@gmail.com> on 2016/12/06 00:29:37 UTC
JMS - Behaviour of multiple invocations of QueueBrowser#getEnumeration
Hi all,
I'm looking at some fails reported by the Java System Testsuite when
run against the Qpid JMS Client.
One failing group is related to QueueBrowsers, for example
QueueBrowserAutoAckTest#testBrowsingWithSelector.
The test assumes that each invocation of QueueBrowser#getEnumeration()
produce a *distinct* browser which independently sees all the
(matching) messages on the queue. This was true for the legacy 0-x
Qpid JMS client (each call to getEnumeration creates a server side
queue browser) but not so for the Qpid JMS Client. The following code
behaves differently.
QueueBrowser browser = _clientSession.createBrowser(_queue);
final Enumeration enumeration1 = browser.getEnumeration();
final Enumeration enumeration2 = browser.getEnumeration();
assertNotSame(enumeration1, enumeration2)
The JMS 1.2 (and JMS 2.0) don't seem tremendously clear to me.
"The browse methods return a java.util.Enumeration that is used to
scan the queue’s messages. It may be an enumeration of the entire
content of a queue, or it may contain only the messages matching a
message selector."
However, from a quick look at the JMS RI, it looks like the Qpid JMS
Client follows the single enumeration approach.
I think the legacy client has wrong behaviour and the test wrong.
Any comments?
cheers Keith
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: JMS - Behaviour of multiple invocations of QueueBrowser#getEnumeration
Posted by Keith W <ke...@gmail.com>.
Thanks - the test is now changed and is passing.
On 6 December 2016 at 10:12, Robbie Gemmell <ro...@gmail.com> wrote:
> On 6 December 2016 at 00:41, Rob Godfrey <ro...@gmail.com> wrote:
>> On 6 December 2016 at 01:29, Keith W <ke...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm looking at some fails reported by the Java System Testsuite when
>>> run against the Qpid JMS Client.
>>>
>>> One failing group is related to QueueBrowsers, for example
>>> QueueBrowserAutoAckTest#testBrowsingWithSelector.
>>>
>>> The test assumes that each invocation of QueueBrowser#getEnumeration()
>>> produce a *distinct* browser which independently sees all the
>>> (matching) messages on the queue. This was true for the legacy 0-x
>>> Qpid JMS client (each call to getEnumeration creates a server side
>>> queue browser) but not so for the Qpid JMS Client. The following code
>>> behaves differently.
>>>
>>> QueueBrowser browser = _clientSession.createBrowser(_queue);
>>> final Enumeration enumeration1 = browser.getEnumeration();
>>> final Enumeration enumeration2 = browser.getEnumeration();
>>> assertNotSame(enumeration1, enumeration2)
>>>
>>> The JMS 1.2 (and JMS 2.0) don't seem tremendously clear to me.
>>>
>>> "The browse methods return a java.util.Enumeration that is used to
>>> scan the queue’s messages. It may be an enumeration of the entire
>>> content of a queue, or it may contain only the messages matching a
>>> message selector."
>>>
>>> However, from a quick look at the JMS RI, it looks like the Qpid JMS
>>> Client follows the single enumeration approach.
>>>
>>> I think the legacy client has wrong behaviour and the test wrong.
>>> Any comments?
>>>
>>> cheers Keith
>>>
>>
>>
>> Yes - it sounds to me that the test is wrong... it should instead create a
>> new browser for each time it wants to browse the queue, rather than relying
>> on getEnumeration() to requery on each invocation.
>>
>> -- Rob
>>
>
> Agreed
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: JMS - Behaviour of multiple invocations of QueueBrowser#getEnumeration
Posted by Robbie Gemmell <ro...@gmail.com>.
On 6 December 2016 at 00:41, Rob Godfrey <ro...@gmail.com> wrote:
> On 6 December 2016 at 01:29, Keith W <ke...@gmail.com> wrote:
>
>> Hi all,
>>
>> I'm looking at some fails reported by the Java System Testsuite when
>> run against the Qpid JMS Client.
>>
>> One failing group is related to QueueBrowsers, for example
>> QueueBrowserAutoAckTest#testBrowsingWithSelector.
>>
>> The test assumes that each invocation of QueueBrowser#getEnumeration()
>> produce a *distinct* browser which independently sees all the
>> (matching) messages on the queue. This was true for the legacy 0-x
>> Qpid JMS client (each call to getEnumeration creates a server side
>> queue browser) but not so for the Qpid JMS Client. The following code
>> behaves differently.
>>
>> QueueBrowser browser = _clientSession.createBrowser(_queue);
>> final Enumeration enumeration1 = browser.getEnumeration();
>> final Enumeration enumeration2 = browser.getEnumeration();
>> assertNotSame(enumeration1, enumeration2)
>>
>> The JMS 1.2 (and JMS 2.0) don't seem tremendously clear to me.
>>
>> "The browse methods return a java.util.Enumeration that is used to
>> scan the queue’s messages. It may be an enumeration of the entire
>> content of a queue, or it may contain only the messages matching a
>> message selector."
>>
>> However, from a quick look at the JMS RI, it looks like the Qpid JMS
>> Client follows the single enumeration approach.
>>
>> I think the legacy client has wrong behaviour and the test wrong.
>> Any comments?
>>
>> cheers Keith
>>
>
>
> Yes - it sounds to me that the test is wrong... it should instead create a
> new browser for each time it wants to browse the queue, rather than relying
> on getEnumeration() to requery on each invocation.
>
> -- Rob
>
Agreed
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: JMS - Behaviour of multiple invocations of QueueBrowser#getEnumeration
Posted by Rob Godfrey <ro...@gmail.com>.
On 6 December 2016 at 01:29, Keith W <ke...@gmail.com> wrote:
> Hi all,
>
> I'm looking at some fails reported by the Java System Testsuite when
> run against the Qpid JMS Client.
>
> One failing group is related to QueueBrowsers, for example
> QueueBrowserAutoAckTest#testBrowsingWithSelector.
>
> The test assumes that each invocation of QueueBrowser#getEnumeration()
> produce a *distinct* browser which independently sees all the
> (matching) messages on the queue. This was true for the legacy 0-x
> Qpid JMS client (each call to getEnumeration creates a server side
> queue browser) but not so for the Qpid JMS Client. The following code
> behaves differently.
>
> QueueBrowser browser = _clientSession.createBrowser(_queue);
> final Enumeration enumeration1 = browser.getEnumeration();
> final Enumeration enumeration2 = browser.getEnumeration();
> assertNotSame(enumeration1, enumeration2)
>
> The JMS 1.2 (and JMS 2.0) don't seem tremendously clear to me.
>
> "The browse methods return a java.util.Enumeration that is used to
> scan the queue’s messages. It may be an enumeration of the entire
> content of a queue, or it may contain only the messages matching a
> message selector."
>
> However, from a quick look at the JMS RI, it looks like the Qpid JMS
> Client follows the single enumeration approach.
>
> I think the legacy client has wrong behaviour and the test wrong.
> Any comments?
>
> cheers Keith
>
Yes - it sounds to me that the test is wrong... it should instead create a
new browser for each time it wants to browse the queue, rather than relying
on getEnumeration() to requery on each invocation.
-- Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>