7 Replies Latest reply on Sep 1, 2005 2:47 PM by Elias Ross

    Design discussions belong in the forums - Compatibility

    Adrian Brock Master

      E

      "
      The intent was to place expired messages from queue A to queue B, and really has nothing to do with the existing DLQ feature. It may make sense to change the default configuration for all queues to expire messages into the DLQ.

      Longer term, there should be a "total solution" that deals with (in an easily configurable manner) the lifecycle of all messages on the server, from inception, to attempted delivery, to eventually being expired from the DLQ, into some sort of reporting database or logfile or whatever. (By the way, I never got to hear your long term design goals for this on the forum.)

      Many of the public interface changes and thread pool changes I made are not necessary to implement this feature, although it seemed logical for JBossMQ to unify, at least on the server, the pool it was using. These thread pooling changes could be left out of 4.0, or back-ported (once "fixed") by somebody. Personally, I never knew enough about JBossMQ internals or what was deemed "public" or not to design the correct fix for this.

      I would be happy to apply a minimal set of changes to 4.0, after 4.0.3 release, with your support. This would include changes to TimeoutFactory, BasicQueue, DestinationMBean/MBeanSupport, and SpySession (remove isOutdated()).
      "

        • 1. Re: Question from JIRA
          Adrian Brock Master

          I moved your comment/question from JIRA.

          We need to distinguish "things that need doing"- JIRA tasks
          from design discussion, questions and help - design forums

          Otherwise the JIRA tasks are useless as release notes, because they become
          unreadable for users.

          I should really have added my comments as subtasks, but I'm not sure you are
          on the JIRA mailing list. I just wanted to flag that the patch as it stands is not
          acceptable.

          • 2. Re: Question from JIRA
            Adrian Brock Master

             


            The intent was to place expired messages from queue A to queue B, and really has nothing to do with the existing DLQ feature. It may make sense to change the default configuration for all queues to expire messages into the DLQ.


            That could be an optional configuration, e.g. on the destination manager
            But it should never be the default. The default is for expired messages to be
            deleted (as anticpated in the spec).
            This is what countless users of JBossMQ already expect to happen.


            Many of the public interface changes and thread pool changes I made are not necessary to implement this feature, although it seemed logical for JBossMQ to unify, at least on the server, the pool it was using. These thread pooling changes could be left out of 4.0, or back-ported (once "fixed") by somebody. Personally, I never knew enough about JBossMQ internals or what was deemed "public" or not to design the correct fix for this.

            I would be happy to apply a minimal set of changes to 4.0, after 4.0.3 release, with your support. This would include changes to TimeoutFactory, BasicQueue, DestinationMBean/MBeanSupport, and SpySession (remove isOutdated()).


            Anything that says "public" could be used by a user. It should not be changed unless:
            1) It is absolutely required to fix a bug (e.g. the spec demands it), in which case
            we should try to provide an error message that explains the incompatible change
            2) If it is not required, the api should be flagged as deprecated and then changed in the next major release, or preferably the one after that.

            This includes a change to semantics, not just the signature of the method.
            e.g. new AcknowledgementRequest() has always created NACK until your change.

            • 3. Re: Question from JIRA
              Adrian Brock Master

               

              These thread pooling changes could be left out of 4.0, or back-ported (once "fixed") by somebody. Personally, I never knew enough about JBossMQ internals or what was deemed "public" or not to design the correct fix for this.


              I will only consider these thread pooling changes complete when you can reproduce
              the old configuration. i.e. somebody should be able to revert to the old semantics
              if they have problems.

              And as a matter of good design, it should be possible to use different thread pools
              in different areas. e.g. UIL2 could do the following logic:

              1) Use Pool configured on MBean
              2) Use Pool from destination manager (if I can get at it and it is configured)
              3) Default back to old behaviour

              • 4. Re: Question from JIRA
                Ovidiu Feodorov Master

                What JIRA issue?
                Would you be so kind to also link to it?
                And maybe use a more explicit title?

                • 5. Re: Question from JIRA
                  Adrian Brock Master

                   

                  "adrian@jboss.org" wrote:

                  2) If it is not required, the api should be flagged as deprecated and then changed in the next major release, or preferably the one after that.


                  There is also the additional considersation in that why should we make it harder to
                  migrate between versions, just because we want to refactor some code.

                  e.g. although the default config of the jbossmq xml has changed quite a lot over the
                  years to take advantage of new features, better implementation and config options,
                  it is still in principle possible to drop the original 2.4.x config into 3.2.7

                  ok, you have to make a few small changes, like add the MessageCache mbean
                  that wasn't in 2.4.x and revert the login-config.xml
                  One example that makes it more difficult, is some idiot refactored the name of the
                  destination manager in 3.0.0alpha for no good reason.

                  The reason why you can't do the same in 4.0.x is because the deprecated file pm
                  and crappy ILs are gone in that release. But it waited for a major release for
                  this to happen and the 4.0.x config is practically the same as 3.2.x

                  • 6. Re: Question from JIRA
                    Adrian Brock Master

                     

                    "ovidiu.feodorov@jboss.com" wrote:
                    What JIRA issue?
                    Would you be so kind to also link to it?
                    And maybe use a more explicit title?


                    http://jira.jboss.com/jira/browse/JBAS-2156

                    • 7. Re: Design discussions belong in the forums - Compatibility
                      Elias Ross Master


                      Adrian,

                      The behavior, as it is now in JBoss HEAD, is largely the same as 4.0 and was intended to work for 99.9% of your customers. Yes, there are incompatible changes I made within what I suspected were internal interfaces. Yes, I made some obvious mistakes with my check-ins, though all unit tests passed ...

                      I would be happy if you just told me precisely what you want including rollback in head, deletion of this patch/issue, a rewrite, etc. I'm more interested in cooperation than education, though education is appreciated, it isn't really letting me reach my goal here, which is eventual inclusion in JBoss 4.

                      I do appreciate your time here. If I were you, I'd probably would have taken the efficient route and rejected the patch outright, requested a rewrite until things were acceptable, etc. I do want to contribute, not generate a lot of bother.

                      And I take back what I said about you not being affectionate, I think you are. If you didn't care about me, you wouldn't have bothered to try to communicate so much.