Thanks - the test is now changed and is passing. On 6 December 2016 at 10:12, Robbie Gemmell <[email protected]> wrote: > 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] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
