[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1416) Provide complete message ordering
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1416?page=com.atlassian.ji...
]
Howard Gao commented on JBMESSAGING-1416:
-----------------------------------------
Hi Fusayuki,
"Would you elaborate "not to support selector at all" a little more,
please?
If JBM ignores the Ordering Group when we create consumers with selectors, it is fine for
us.
If JBM throws exceptions, then we cannot use the queues with JBoss ESB."
--- If we turn Ordering Group on, it always tries to keep strick ordering of the messages.
Using selectors on ordering group will not result in exceptions, but may result in
messages never being delivered.
"Let me explain our background using with message selectors.
For request-replay message pattern, we should specify connection factory names for a JBoss
ESB service.
But we can only specify one connection factory name applying both for request and reply
queues.
In other words, we cannot simply specify a connection factory name only for the reply
queue.
So we would like to use the queues with selectors even though it breaks FIFO.
Could you just ignore the message ordering when using with selectors, as if Ordering Group
is not used?"
--- I don't understand the use case. If ordering can be ignored, why we turn it on? We
just use normal delivery.
Can you give a very simple concrete case where ordering and selector are both needed and
also must be used together?
I don't think single connection factory would be a problem, because we can use
JBossMessageProducer's API to control ordering, if you don't want ordering all
over the connection factory scope.
Provide complete message ordering
---------------------------------
Key: JBMESSAGING-1416
URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1416
Project: JBoss Messaging
Issue Type: Feature Request
Reporter: Tim Fox
Assignee: Howard Gao
Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
As per customer request we would like to introduce new functionality over and above the
JMS ordering guarantees.
The idea is that the user should be able to determine an "ordering group". This
can be done by setting a reserved property on the message before sending.
The ordering group can be pinned to the producer or just be some other arbitrary string.
In order to guarantee strict ordering, even on rollback or in the presence of multiple
consumers or with xa transactions, the queue needs to ensure that no more than one message
with the value of ordering group is being delivered at any one time.
When that message has been acked, or cancelled the next one can be delivered.
This is of course will provide a performance penalty since we won't be able to do
consumer buffering, but that's the price you pay if you want such a strict ordering
guarantee.
We can subclass our MessageQueue class to do this. The sub-classed class can maintain a
map of ordering group-->boolean. Which will determine whether the queue is currently
delivering any messages with that ordering group value. It will consult that map when
delivering to decide whether it can deliver the next message.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira