ClientConsumer with browser=true on core

[clebert.suconic]

Whenver you create a consumer with browseOnly = true, the server will not add it to bindables.

As a consequence: the following code would be "invalid":

ClientConsumer browser = coreSession.createConsumer(
"jms.queue.Queue1", true); 
browser.setMessageHandler(
new MessageHandler()      {
        ...
     });

The MessageHandler will never receive anything. As with browsers you should only use the ClientConsumer.receive method. (Similar as using the enumeration on JMS).

Well, It's not a big deal, but I think we should throw an exception if an user ever did this, just to make things clearer.

I will do it with my changes. I don't think anyone would be against it.. but let me know otherwise.

[timfox]

I'm not sure what you mean "add it to bindables". A ServerConsumer is not a bindable, it's a consumer of a queue. It's the queue that maps to the Bindable.

[clebert.suconic]

What I meant was: a Browser doesn't belong to the Consumer's list on the Queue, hence a MessageHandler will never get called.

The small change I want to make is to throw an Exception if an user sets a MessageHandler to a Consumer that was marked as browse only.

[timfox]

Message handlers should certainly work with browsers too. But that doesn't mean browsers shuold be on the consumer list. In fact, they shouldn't, since browser maintain their own iterator on the queue.

It shouldn't be an error to se a MessageHandler on a browser. This should already work (are there no tests for it?)

[clebert.suconic]

Browsers are currently only working with receiveImmediate. receive(Timeout) doesn't work either.

To have browsers working with messageHandlers, you would need to have a special list on the server that would deliver every single message to the browser after is received. I could write a couple tests where the browser doesn't iterate with messages after received.

IMO: Browsers should be just like they are on JMS (working with iterations).

[clebert.suconic]

.....(are there no tests for it?)

- There is BrowsersTest on JMS and JORAM Tests testing the Enumeration mechanism.

- There is QueueBrowserTest on tests.integration.client

This test is not validating receiving after the message was received.

- There is MessageHandlerTest

There are a few browser tests here with Handlers but they are not testing receiving messages after being sent. It's only navigating through the snapshot. I believe this was written back when we would only support a static snapshot of the queue.

[clebert.suconic]

IMO: Browsers should be just like they are on JMS (working with iterations).

I'm not going to change this. I will see if there's a way to update the Browser after receiving a message.

I have created a JIRA to verify this later: https://jira.jboss.org/browse/HORNETQ-561

[timfox]

I don't understand what you're getting at here.

Each ServerConsumer simply maintains an iterator, when promptDelivery is called that iterator is called.

This is all transparent to the client consumer. Clients should be able to set a message handler, call receive() etc no problem.

Please note that the iterator *is not* a static snapshot. The new iterators on the queue do see messages added after they are created.

And anyway.... there is no requirement in JMS (or core) for browsers to see messages added after they are created anyway.

So I'm not really sure what you're getting at here....

[clebert.suconic]

I knew the iterator is not a static snapshot.

It's just that I could get a couple of scenarios where the consumer was not getting messages. In one of the tests I wouldn't get the message unless I called receiveImmediate().

I was looking at how the iteration with paging should work, and I was a bit confused with Browsers, but I'm good now.

I will look later as it seems a core consumer will not get all the available messages on the server. (I could see a couple of failing scenarios). I will come back at this later with the JIRA I created

(and thanks a lot for the help)