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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
