On 6 December 2016 at 00:41, Rob Godfrey <[email protected]> wrote: > On 6 December 2016 at 01:29, Keith W <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
