1 2 Previous Next 25 Replies Latest reply on Jul 10, 2013 8:07 AM by ataylor

    JMS 2 Dev Thread

    clebert.suconic

      First things first: I've been looking at Andy Taylor's Branch, which was imported from Jeff, and now it's imported on mine...

       

       

      well... it's time to have a central repo for that..  I have created a temporary branch on the main repo called jms2. So we can better interact.  We can later squash it and push whatever we want to master. (that's just a temporary branch).

       

       

       

      Second thing: JMSContext is using a Connection.  a JMSContext is a direct mapping of our ClientSession approach, so no need to use any JMS Object withing a JMSContext.. it's just straight core-api.

       

       

       

      Third thing: It doesn't look as complex as I thought... although I'm not sure how JCA is doing with JMSContext yet. That's one thing we will have to figure out.

        • 1. Re: JMS 2 Dev Thread
          ataylor

          Second thing: JMSContext is using a Connection.  a JMSContext is a direct mapping of our ClientSession approach, so no need to use any JMS Object withing a JMSContext.. it's just straight core-api.

          I disagree, JMSContext basically delegates to the Session API, using core would actually make it more complex, for instance:

           

          JMSContext.createSharedConsumer() -> Session.createSharedConsumer()

           

          Also in JEE you would create the JMSContext and inject a connection factory something like:

           

          @Inject

          @JMSConnectionFactory("jms/JmsXA")

          JMSContext context

          • 2. Re: JMS 2 Dev Thread
            clebert.suconic

            The idea of JMSContext was to replace Session and Connection.

             

             

            Having a Conenction / Session pair will make us having two ClientSession instances.

             

             

            Besides the design / proposal of JMSContext always had the idea of a direct core implementation.

             

             

             

            You can inject a JMSContext straight from ConnectionFactory->createJMSContext.

            • 3. Re: JMS 2 Dev Thread
              ataylor

              The idea of JMSContext was to replace Session and Connection.

              Most the methods that are in JMSContext are also in Session, seems like if we use core we will have duplicate code. Its already in HornetQSession so why not use it. Looks to me that JMSContext encapsulates a session and connection and removes you having to use boiler plate code, I still think as it should be.

              • 4. Re: JMS 2 Dev Thread
                clebert.suconic

                JMSContext came as a replacement of JMSSession. We could refactor stuff in such way you reuse code. But you can't have JMSContext depending on JMSSession. It has to be a map to CoreSession.

                 

                It has to be as light as possible also.

                 

                 

                JMS2 couldn't remove JMSSession and JMSConnection in a deprecate fashion because of EE rules... but that's the idea behind it.

                • 5. Re: JMS 2 Dev Thread
                  ataylor

                  JMSContext came as a replacement of JMSSession. We could refactor stuff in such way you reuse code. But you can't have JMSContext depending on JMSSession. It has to be a map to CoreSession.

                  Why not use the code thats in HornetQSession, it will be the same, i cant see why using the same code elsewhere would make it lighter, its exactly the same

                  • 6. Re: JMS 2 Dev Thread
                    clebert.suconic

                    you are creating a Connection in order to create a Session, which defied the purpose of the JMSContext...

                     

                    You will have an extra layer of calls for anything done on JMSContext. the JMSContex is not an utility to make a translation into a JMSSession / JMSConnection.

                     

                     

                    Think this way, We didn't like the Connection / Session approach, then we implement the Core api with that approach.

                     

                     

                    Now we have JMSContext which has accepted our concept of an unified approach, then we will translate a JMSContext into a pair of Connection / Session which will be translated back to ClientSession (or core session). It seems too many layers... i would simplify it and go straight to ClientSession.

                    • 7. Re: JMS 2 Dev Thread
                      ataylor

                      my point is the code to do something in core is exactly the same as in HornetQSession, there is no difference, so re use it. yes its there to remove having both a session and a connection but this is at an API level, what we do under the covers doesnt atter, using HornetQsession will be no different than using core, its just abstracting some of the core functionality so why not re use it

                      • 8. Re: JMS 2 Dev Thread
                        clebert.suconic

                        As long as we have no Connection/Session pair...  and the use of the JMSEssion is just a way to avoid duplicated code.

                         

                        As I said we could always refactor stuff into a third class to make things clearer.

                        • 9. Re: JMS 2 Dev Thread
                          ataylor

                          As long as we have no Connection/Session pair...  and the use of the JMSEssion is just a way to avoid duplicated code.

                          It makes no difference if we use a connection/session pair

                          As I said we could always refactor stuff into a third class to make things clearer.

                          which is no different, we will be making the same calls to core just from a different class rather than HornetQSession

                           

                          why dont you show me an example?

                          • 10. Re: JMS 2 Dev Thread
                            clebert.suconic

                            We are currently sharing a connection upong jmsContext.createContext();

                             

                             

                            I'm checking with the jms spec group if that's the expected behaviour, or if the state should be independently.

                             

                             

                            Say, if you created a new jmsContext with

                             

                            JMSContext jmsContext2 = jmsContext.createContext(); and then did :

                             

                            jmsContext2.setClientID();

                             

                             

                            should jmsContext.getClientID be == jmsContext2.getClientID or not?

                             

                             

                             

                            I believe it may be independent, but since it's a builder pattern maybe it could reuse the same inner connection.

                             

                             

                            I'm checking on that and i will get back as soon as possible. if that's separate we will probably have to redo a bit of a refactoring on our implementation. I have been looking into that today.

                            • 11. Re: JMS 2 Dev Thread
                              borges

                              @clebert,

                               

                              With regards to using an embedded Session or not.

                               

                              If you read the Javadocs of JMSContext, you will notice that it seems to assume the presence of a Session.

                               

                              {code}

                              /**

                              ...

                                   * If {@code sessionMode} is set to

                                   * {@code JMSContext.SESSION_TRANSACTED} then the session will use a

                                   * local transaction which may subsequently be committed or rolled back by

                                   * calling the {@code JMSContext}'s {@code commit} or

                                   * {@code rollback} methods.

                              ...

                              */

                              {code}

                               

                              Regardless of whichever weight we should give to that, I must say that I agree with Andy Taylor here and think we should just combine a Session and a Connection (like our jms2 currently does). I believe that Andy is correct in pointing out that refactoring the Session code somewhere else will not magically make it more efficient.

                               

                              With regards to sharing a connection when calling JMSContext.createContext(): that is a requirement well spelled out in JMSContext javadocs. The first paragraph of this method's javadoc states:

                               

                               

                              {code}

                              /**  Creates a new {@code JMSContext} with the specified session mode

                                   * using the same connection as this {@code JMSContext} and creating a

                                   * new session.

                              ...

                              */

                              {code}

                              • 12. Re: JMS 2 Dev Thread
                                borges

                                Clebert Suconic wrote:

                                 

                                We are currently sharing a connection upong jmsContext.createContext();

                                 

                                I'm checking with the jms spec group if that's the expected behaviour, or if the state should be independently.

                                 

                                 

                                Say, if you created a new jmsContext with

                                 

                                JMSContext jmsContext2 = jmsContext.createContext(); and then did :

                                 

                                jmsContext2.setClientID();

                                 

                                 

                                should jmsContext.getClientID be == jmsContext2.getClientID or not?

                                The connection is shared. The Javadoc even spells the expected behavior when calling JMSContext.close().

                                 

                                With regards to JMSContext.setClientID(), its javadoc states:

                                 

                                {code}/** Sets the client identifier for the JMSContext's connection. .... */{code}

                                 

                                (See the rest of the method's Javadoc as well...)

                                • 13. Re: JMS 2 Dev Thread
                                  clebert.suconic

                                  It wasn't clear to me if connection meant a JMSConnection... or if the state would be kept on the connection. anyway.

                                   

                                  I've read that but I wanted to make sure about it...  I doubled checked with the spec group and we're clear.

                                  • 14. Re: JMS 2 Dev Thread
                                    clebert.suconic

                                    My Progress today:

                                     

                                    I have written a few local tests here on Shared Subscription, non Shared Subscription...

                                     

                                    We will have to redo some of those things... I should be able to commit it tomorrow.

                                     

                                     

                                    It will be more important to write tests than anything else. Especially on JMSContext... I will write some tomorrow but we should focus on that as well.

                                    1 2 Previous Next