Clebert,
On 11/11/2011 17:23, Clebert Suconic wrote:
> Nigel,
>
> I agree this is a good proposal... please ignore my previous email on RequestResponse.
>
> Regarding the receiveSyncMessage on Connection
>
> - Would you still be able to create a Consumer and do a receive(timeout) or receiveImmediate() on the Consumer?
I think I had a cut-n-paste error in my earlier email. I'm suggesting:
MessagingContext context = connectionFactory.createContext(false,Session.AUTO_ACKNOWLEDGE);
SyncConsumer syncConsumer = context.createAsyncConsumer(queue,messageListener,messageSelector,noLocal);
Message someMessage1 = syncConsumer .receive(timeout);
Message someMessage2 = syncConsumer .receive(timeout);
Message someMessage3 = syncConsumer .receive(timeout);
syncConsumer.close()
(I've also renamed newConnection to messagngContext)
There would also be receiveNoWait() and receive() methods. This is intended to be very similar to the current API,
except that it would be for sync receive only.
> - If that's the only way to do receive a message blocked (sync), then I see an issue on performance / caching
>
> - Also: Maybe I misunderstood what you said about marking the intention for next messages, but assuming first a read
> to assume the connection would cache messages would IMO be too much of a inference on what the user will do next.
I'm not sure whether I've addressed your concerns now. Let me know if I haven't. But basically I think that for sync
receive we still need a separate consumer object with a separate lifecycle from the connection/session. This is the one
area where we can't simplify the API as much as we might like. If we put the receive() methods directly on the context
object we would be introducing restrictions on the implementer. The current API doesn't require implementations to cache
messages in the consumer but allows them to do so if they want. I think we need to keep this flexibility.
This issue does not arise for async delivery since the call to
context.setMessageListener(queue,messageListener,messageSelector,noLocal);
can be the point where the JMS client starts caching messages if it wants to.
Perhaps we want a removeMessageListener method as well which does the equivalent of javax.jms.MessageConsumer.close().
>
> Regarding the Producer
> - I like the idea of not having a MessageProducer at all (any flow control needed on the implementation can be
> encapsulated here).
>
> Even on the Consumer case, you could probably do: consumer.getConnection().send(queue, message);
>
That is a possibility, but not essential. The existing API doesn't have a javax.jms.Session.getConnection() method.
I'll write the whole thing up shortly.
Nigel