8 Replies Latest reply on Aug 29, 2005 12:14 AM by ovidiu.feodorov

    Messaging Core Specification - Revision 1

    ovidiu.feodorov


      I have just posted a new revision of the Messaging Core specifications on the wiki: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingCoreRevision1

      The original version can be found here http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingCore

      The new revision completes and further qualifies the initial specifications for channels, persistence, message state, message ordering etc.

      Most of the changes are the direct result of using the current core implementation with the JMS facade. Most of the concepts discussed here are already implemented in the core, but the revision also contains proposals that may lead to semantic/interface changes .

      Please post your comments and suggestions on this thread.

        • 1. Re: Messaging Core Specification - Revision 1

          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

            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

              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

                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

                  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

                     

                    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

                       

                      "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

                        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.