"gaohoward" wrote : Help and comments are definitely needed, please! | | Below is a sum of factors I found and how should an order group deal with them (by default). Some of the choices the order group impl makes may not be appropriate all the time, and if so, we can make them configurable to suit different needs. | | 1. Message Priority: messages with higher priorities may jump ahead of the messages with lower ones, even if the lower ones may have been created ahead of the higher ones; | | /In Ordering Group/ -- Messages in an ordering group will be ignored of their priorities in the ordering of their delivery. | We can support priority within the ordering group, just not a total priority order in the queue anonymous wrote : | 2. Persistency: Non-persistent messages and persistent ones. They are two seperate categories with respect to ordering. Non persistent messages are not guaranteed to survive a server failure and thus may mess up the ordering group processing. | | /In Ordering Group/ -- We may force that all messages in the ordering group to be of PERSISTENT delivery mode. | I don't think there is any need to force. If a user uses a non persistent message they do so with the understanding this does not survive restart anonymous wrote : | 3. Message redelivery: In case of message redelivery (if required), new messages may be delivered to the Queue the same time as that of redelivery. | | /In Ordering Group/ -- the message to be redelivered, if in an ordering group, must block any subsequent messages that are in the same message ordering group. | ok anonymous wrote : | 4. Message Ack Modes -- dup_ok/auto/client, the three ack mode affects the acknowledgement timing but shouldn't change the message ordering group's behavior. | | /In Ordering Group/ -- The order group will wait for the acknowledge of the current message before delivering the next one, regardless the ack mode. | How would this work with transactions? In JBM 1.4 deliveries in a tx aren't acked until commit anonymous wrote : | 5. Message selector -- the filtering of messages causes some messages not selected to drop from the subscribers. | | /In Ordering Group/ -- We can forbid using selectors, or we can make the selector process always pass any messages that belong to an ordering group, or we can deem the drop of a unsatisfied message to be an effective acknowledgement of completion. Not sure!! | If users use a selector with an ordering group, they do so with the understanding that some messages may be missing. Order is still correct but it contains "holes". anonymous wrote : | 6. JMS Replyto -- during a ordered delivery, if some messages has reploy to header specified, this will yield another message delivery. | | /In Odering Group/ -- We should ignore this case. as long as we get acked from the message delivery, we consider it's completed. | I don't understand the issue here anonymous wrote : | 7. Expired/Dead Messages -- if some messages expires or failed to deliver for n times, they will go to the expiryQueue or DLQ. Consumer won't get them. If a dead or expired message drops from the ordering group, the order is broken. | | /In Ordering Group/ -- We can treat all members in an ordering group as never expires or never be dead, or we treat expired message and dead message as unfinished until they are fetched from the expiryQueue or DLQ and acked (or the transaction containing those messages are committed or rolled back). | No need for special treatment here. anonymous wrote : | 8. Transactions -- transactions makes the messages delivery subject to an atomic operation. | | /In Ordering Group/ -- If any message in the ordering group is participates in any active transaction, its delivery won't be treated as completed until the transaction is committed or rolled back. | How do you cope with starvation? If only one message is delivered at a time anonymous wrote : | 9. Ordering Scope -- messages can be sent from different sessions, on different connections, or from different client applications to different destinations (queues or topics). | | /In Ordering Group/ -- We can guarantee the ordering delivery of a ordering group easily if all the messages in an ordering group are produced(sent) within one same session and all the messsages are targeted at one same destination. Messages from different sessions imply different work threads (which makes the message order depending on thread scheduling) and different transactions (which needs more care for ordering). Messages of an ordering group on different destinations is also hard to handle even if they are from one session. | ok anonymous wrote : | 10. ConnectionConsumer -- This is a special case of message delivery. | | /In Ordering Group/ -- If messages of an ordering group is consumed this way, we should also keep the ordering correctly even if the consumer can handle the messages concurrently. But in this case we can't guarantee the messages are all processed by one same Session in the pool. | The user will have to set session pool to 1 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180944#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...