14 Replies Latest reply on Oct 7, 2008 10:18 AM by timfox

    Adding Ordering Group Features in JBM 1.4

    gaohoward

      https://jira.jboss.org/jira/browse/JBMESSAGING-1416

      I'm trying to add this feature to JBM 1.4. Below is a draft design and I'm considering Tim's suggestion to make changes to our MessagingQueue to implement it. The implementation detail will be posted later as I need more time to understand our code. Please help to review and see if anything is wrong or missing.

      I Enable Ordering Group by programming

      JBossMessageProducer::setOrderingGroup(); //sys generated name
      JBossMessageProducer::setOrderingGroup(String name); //user specified name

      The two methods enable/disable the JBossMessageProducer to produce messages that belong to a named ordering group. Messages in a named ordering group will be processed strictly in the order they are produced (sent). Calling setOrderingGroup(null) will reset the producer to be a normal JMS producer.

      Once thus set, the producer will set a reserved message property JBM_ORDERING_GROUP_ID to the name of the ordering group on each message sent through it.

      JBossMessages that have this property set are treated as ordering group messages and those that have one same value form an ordering group.

      Other Processing Rules of Ordering Group Messages

      1. The order of delivery will not be affected by sort criteria, priority, or filters.
      2. Only if one message has been processed (acked, committed, rolled back, expired) can next message be delivered.
      3. Uncommitted or unacked Messages in one ordering group must be within the same JMSSession or same transaction.
      4. The processing of ordering group messages applies to both Queues and Topics.

      II Enable Ordering Group by Administration

      1. A ConnectionFactory can be configured to have ordering group enabled by default, i.e. all producers created from this factory have ordering group enabled. The user can override the default ordering group settings on the producer later by calling setOrderingGroup() methods.

      2. A Destination can be configured to have ordering group enabled by default, i.e., any messages sent to this destination will automatically set to belong to the configured default ordering group if they haven't already belonged to one.


        • 1. Re: Adding Ordering Group Features in JBM 1.4
          gaohoward

          ====update version: api changed======

          An ordering group is a set of messages that needs to be delivered sequentially exactly in the same order as they are produced.

          I Enable Ordering Group by programming

          JBossMessageProducer::enableOrderingGroup(String name); //user specified name, null for sys generated
          JBossMessageProducer::disableOrderingGroup();

          The two methods enable/disable the JBossMessageProducer to produce messages that belong to a named ordering group. Messages in a named ordering group will be processed strictly in the order they are produced (sent). The enableOrderingGroup(name) will set producer's ordering group to the specified name, or an auto-generated name if passing a null parameter. Calling disableOrderingGroup() will reset the producer to be a normal JMS producer.

          Once thus set, the producer will set a reserved message property JBM_ORDERING_GROUP_ID to the name of the ordering group on each message sent through it.

          JBossMessages that have this property set are treated as ordering group messages and those that have one same value form an ordering group.

          Other Processing Rules of Ordering Group Messages

          1. The order of delivery will not be affected by sort criteria, priority, or filters.
          2. Only if one message has been processed (acked, committed, rolled back, expired) can next message be delivered.
          3. Uncommitted or unacked Messages in one ordering group must be within the same JMSSession or same transaction.
          4. The processing of ordering group messages applies to both Queues and Topics.

          II Enable Ordering Group by Administration

          1. A ConnectionFactory can be configured to have ordering group enabled by default, i.e. all producers created from this factory have ordering group enabled. The user can override the default ordering group settings on the producer later by calling setOrderingGroup() methods.

          2. A Destination can be configured to have ordering group enabled by default, i.e., any messages sent to this destination will automatically set to belong to the configured default ordering group if they haven't already belonged to one.

          • 2. Re: Adding Ordering Group Features in JBM 1.4
            clebert.suconic

            It looks that this feature wouldn't be released on the next CP04.

            If you could please hold the commit until we tag CP04. I'm now investigating some failures on the testsuite.. which won't probably cause any changes.

            If you need to commit it now (for backup maybe?), maybe you should create a temporary branch, and commit it on Branch_1_4 right after we tag CP04.


            Thanks

            • 3. Re: Adding Ordering Group Features in JBM 1.4
              clebert.suconic

               

              "clebert.suconic@jboss.com" wrote:

              If you could please hold the commit until we tag CP04. I'm now investigating some failures on the testsuite.. which won't probably cause any changes.



              I have figured out about the failures.

              NullPersistenceTest was setting the test.database system property to "null", what was making subsequent tests to not use any persistence.

              The testsuite on the client aways use a single VM from back to back, so if you have to make those types of changes, you should aways set them back on tearDown.

              It would be better if we could use the ServiceAttributeOverrides on startServer for this.. but since the persistence is started somewhere else, and what would require some more changes, I'm just changing the system property back on tear down, what should fix the testsuite.

              • 4. Re: Adding Ordering Group Features in JBM 1.4
                gaohoward

                Thanks for the fix Clebert. It's my fault.

                • 5. Re: Adding Ordering Group Features in JBM 1.4
                  clebert.suconic

                  np


                  I just tagged the branch.. so you're free to use Branch_1_4 again.

                  • 6. Re: Adding Ordering Group Features in JBM 1.4
                    timfox

                    Please don't use that branch.

                    The release will need to be re-tagged since readme and docs weren't updated properly.

                    The release notes still refer to 1.4.1.beta1 (!) and reference the incorrect project in JIRA, as does the documentation.

                    • 7. Re: Adding Ordering Group Features in JBM 1.4
                      timfox

                      I deleted the tag to prevent anyone taking it prematurely.

                      Next time, I want to see a review process before tagging.

                      This same mistake of not updating readme and documentation seems to happen regularly every single time.. :(

                      • 8. Re: Adding Ordering Group Features in JBM 1.4
                        timfox

                        I have updated the docs and readme so they reference the correct jar versions and release numbers.

                        I have also released the project in JIRA

                        What remains to be done before releasing:

                        1) Make sure all the examples run through
                        2) Update remoting config in the docs with the version in the release

                        Other things to do (maybe done already?)

                        1) Make sure eap 4.3 service binding manager config is updated with our new config.

                        2) Make sure any JBM config files in EAP 4.3 have been updated with our new config.

                        • 9. Re: Adding Ordering Group Features in JBM 1.4
                          clebert.suconic

                           

                          "timfox" wrote:

                          This same mistake of not updating readme and documentation seems to happen regularly every single time.. :(


                          This is not true.. .It has happened before, but it doesn't happen every single time.

                          The CP update only takes the JAR... no docs. This is not a complete community release.


                          • 10. Re: Adding Ordering Group Features in JBM 1.4
                            timfox

                             

                            "clebert.suconic@jboss.com" wrote:
                            kes the JAR... no docs. This is not a complete community release.


                            It doesn't matter.

                            A release is a release. The documentation and readme must be accurate. It will cause one hell of a confusion if the readme and documentation talks about 1.4.1beta and older versions of remoting and other jars.

                            People DO read the readmes for CP releases. (I have referred support customers to it before). They use the readme and documentation to determine what correct versions of remoting etc to use.

                            The proper release procedure MUST be carried out for every release.

                            • 11. Re: Adding Ordering Group Features in JBM 1.4
                              timfox

                               

                              "clebert.suconic@jboss.com" wrote:

                              This is not true.. .It has happened before, but it doesn't happen every single time.


                              It's happened at least four or five times. ALL by the same person! ;)


                              • 12. Re: Adding Ordering Group Features in JBM 1.4
                                ataylor

                                What/Where is the release process. It probably should be a JIRA then things wouldn't be forgotten.

                                • 13. Re: Adding Ordering Group Features in JBM 1.4
                                  clebert.suconic

                                  AFAIC, The EAP-CP Release process is taking in parallel.

                                  https://jira.jboss.org/jira/browse/JBPAPP

                                  And I've sent a private email about that yesterday... (BTW the EAP is an internal process.. so.. this should be a private thread).

                                  If you don't agree with that, we just change the docs... that's it.. not big deal about it. I don't get why this is being such a big deal in public.

                                  I only tagged the release so Howard would be able to keep his work, and we could make any minor other changes on the TAG later.

                                  • 14. Re: Adding Ordering Group Features in JBM 1.4
                                    timfox

                                    I am a bit worried why you don't understand why it is wrong to tag a release that includes a README from a previous release and old documentation.

                                    The README and docs must be accurate for each release. Period. As I've already said, people do read these, even for CP releases. Can you imagine how confusing it is for a user who takes the CP release and follows the instructions and ends up using the wrong remoting version, and nothing works? And then we have to deal with that on the forums?

                                    And yes, community users DO use CP releases too - these are publicly avaikable in SVN, and they DO install them into JBoss AS.

                                    It only takes 5 mins to update the docs and readme.

                                    Hopefully next time you won't forget.

                                    But from now on, please clear with me before tagging any release.

                                    BTW this is not a new process. This is the way we have always done it.

                                    It's fundamental that the README for a release is the actual README for the release, not some other random version.