-
1. Re: Messaging Core Specification - Revision 1
adrian.brock Jun 10, 2005 4:08 PM (in response to ovidiu.feodorov)Since you didn't update the original page....
Can you post a "diff" that summarises the changes? -
2. Re: Messaging Core Specification - Revision 1
ovidiu.feodorov Jun 10, 2005 4:52 PM (in response to ovidiu.feodorov)The new document presents mainly concepts that haven't been sufficiently qualified by the first version. If you think about it in terms of diff, the revision should be merged in the first version, the overlap is minimal. I will eventually do that and produce a consolidated version, but only after I have at least a working beta out. Until them, here are some highlights:
The AcknowledgmentStore was renamed ChannelState (since it contains more than acknowledgments).
The first document doesn't specify too much about transactional and reliable handling. Revision 1 does. It's true that further work needs to be done on a more detailed specification for persistence. I will do that soon.
The first document doesn't specify anything about an individual message state. Revision 1 does.
The revision also highlights the changes that have been applied to the Channel interface.
New subjects are filters and message order. -
3. Re: Messaging Core Specification - Revision 1
adrian.brock Jun 10, 2005 7:50 PM (in response to ovidiu.feodorov)I've created a separate thread to get your opinion on the acknowledgement/delivery/message state handling, especially WRT to your
identified race conditions.
I think the key part is that you need to setup a unique identity of each delivery
operation before you perform it. Then it is a QOS thing on handling spurious
acks.
i.e. If I know what I'm doing and can guarantee ack recovery and correct semantics,
I can avoid storing acks in previous parts of the pipe.
However, if I don't trust things further down the pipe (like JMS clients)
then I need to take extra steps. -
4. Re: Messaging Core Specification - Revision 1
adrian.brock Jun 10, 2005 7:55 PM (in response to ovidiu.feodorov)I do want to see the persistence stuff, especially when it is peer-peer.
This is the killer feature. ;-) -
5. Re: Messaging Core Specification - Revision 1
ovidiu.feodorov Jun 10, 2005 8:07 PM (in response to ovidiu.feodorov)I agree about the "identity of each delivery operation".
The queue (the asynchronous channel) can guarantee recovery so it ACKs to its sender. The way can guarantee that it is by maintaing what you call delivery identity, for each message. In my case, the delivery identity is part of the message state ("DELIVERED"), as maintained by the channel. Since a channel can deliver to many receivers, the message state maintains multiple NACKs (or ACKs).
Thanks for the code, I am currently analyzing it and I will update the design documents as soon as the elightnment happens :) -
6. Re: Messaging Core Specification - Revision 1
ovidiu.feodorov Jun 10, 2005 8:11 PM (in response to ovidiu.feodorov)I do want to see the persistence stuff, especially when it is peer-peer.
You will. But let's first make sure this guy knows how to deal with mundane things such as JMS 1.1 compliance :) -
7. Re: Messaging Core Specification - Revision 1
adrian.brock Jun 10, 2005 8:19 PM (in response to ovidiu.feodorov)"ovidiu.feodorov@jboss.com" wrote:
I agree about the "identity of each delivery operation".
You've got part of the enlightment.
The other part is the stateless design. By passing around a "Delivery" object
you remove the need to perform HashMap lookups in the optimized in memory case.
You are doing call-by-reference all the way through, rather the call-by-value
that is done in JBossMQ with the BasicQueue acknowledgement maps.
This is essentially the same optimization I did to JCA in 3.2.2 to remove map lookups
as points of contentions (beside the fact that it is needless work :-). -
8. Re: Messaging Core Specification - Revision 1
ovidiu.feodorov Aug 29, 2005 12:14 AM (in response to ovidiu.feodorov)Thanks for the idea. It is integrated now in the new implementation of the core. This is how the core works now:
The channel instance delivers a message to its receivers according a "routing policy" encapsulated by a synchronous router, internal to the channel. The first delivery attempt is synchronous, and each receiver returns either null (which means it is not interested in the message), a Delivery instance or throws an unchecked exception (which means the receiver is broken and should be ignored).
A Delivery instances embodies the "identity of the delivery". Each delivery has a state: it is either "done" or "active". It also maintains a hard reference of the routable the delivery is attempted for.
If a receiver synchronously returns a "done" Delivery instance, the sender considers itself free of any responsibility related to that particular message and can safely forget the message. If the receiver returns an "active" delivery, the channel maintains a reference to that delivery, and implicitly to Routable instance the delivery is attempted for. A reliable channel persist the routable reliably, so the message being delivered survives failures.
When the receiver decides it completely processed the message, it acknowledges the delivery, which propagates the acknowledgment back to its associated DeliveryObserver, which is the channel. A set of acknowledgments can be sent atomically or not, depending on the receiver's intention. Once the channel receives an acknowledgment, it forgets about that delivery and the message associated with it. The receiver can also ask for redelivery or it can cancel a delivery.
A channel it is a receiver itself, so the above discussion applies to the behavior of the channel relative to its senders. In most of cases, because channels are reliable, they will immediately return a "done" delivery to their sender. However, this is not absolutely necessary, the channel can return an "active" delivery itself.The other part is the stateless design. By passing around a "Delivery" object you remove the need to perform HashMap lookups in the optimized in memory case.
Sending an acknowledgment back to the channel cannot be done without a hashmap lookup: the channel has to decide if the delivery being acknowledged it is its "own" delivery, so it has to look it up in a map or a list, internally. Othewise, I can create my own Delivery and hand it over to the channel, saying "acknowledge this". The channel needs a way to figure out whether that "this" it is something it has seen before.