7 Replies Latest reply on May 14, 2009 4:32 AM by kconner

    DefaultJMSPropertiesSetter, DefaultESBPropertiesSetter and f

    kconner

      DefaultESBPropertiesSetter now includes the ability to filter some of the properties as they are imported from JMS, but the current implementation is only usable in certain circumstances.

      One area which cannot use the mapping is the JMSCourier, as the creation of the Setters are defaulted.

      I have been helping someone get this to work on Oracle AQ (10.2.3) which does not allow JMS_OracleXXX properties to be set (although 11g does).

      Tracking this through shows that we can filter on the gateway but, when the listener obtains the ESB aware message through the courier, these headers are reintroduced.

      So the questions I have are
      - why does the ESB aware need to handle property mappings?
      - should the DefaultJmsPropertiesSetter also be filtering?
      - should we be ignoring JMS_XXX on a global basis?

      Any thoughts?

      Thanks

      Kev

        • 1. Re: DefaultJMSPropertiesSetter, DefaultESBPropertiesSetter a
          beve

           

          why does the ESB aware need to handle property mappings?

          This is to support pass-through of JMS properties. Previously we just passed through all properties which caused problems with some JMS Providers.
          The issue we had was when working with IBMQ in combination with JBossMQ. JBossMQ throws an exception if a provider specific jms property, one starting with "JMS_verndor_name" was not recognized as it's own. JBoss Messaging would simply ignore an unrecognized provider property.
          The use case was a jms gateway that was connected to IBMQ. A JMS Message would in this case contain provider specific properties to IBMQ. By filtering out these properties they would never be seen by JBossMQ.
          We created this for cases where other JMS Providers might do the same as JBossMQ and added the ability to filter out properties.

          should the DefaultJmsPropertiesSetter also be filtering?

          Yeah, it probably should. If there is a mix of JMS Provders this will probably cause troubles like the one you are seeing at the moment :(

          should we be ignoring JMS_XXX on a global basis?

          Well this might make our life easier but perhaps this could hurt performance. These properties could be optimization properties that the provider can take advantage of.

          /Daniel



          • 2. Re: DefaultJMSPropertiesSetter, DefaultESBPropertiesSetter a
            kconner

             

            "beve" wrote:
            This is to support pass-through of JMS properties. Previously we just passed through all properties which caused problems with some JMS Providers.

            But should this not be the responsibility of the gateway and EPR to handle?

            "beve" wrote:
            The issue we had was when working with IBMQ in combination with JBossMQ. JBossMQ throws an exception if a provider specific jms property, one starting with "JMS_verndor_name" was not recognized as it's own.


            This was seen with a single provider, oracle, we were not passing these between different providers.

            "beve" wrote:
            Well this might make our life easier but perhaps this could hurt performance. These properties could be optimization properties that the provider can take advantage of.

            Okay, so it sounds like we need a more flexible solution. Do you have any examples of the properties which you are allowed to set?

            Kev


            • 3. Re: DefaultJMSPropertiesSetter, DefaultESBPropertiesSetter a
              beve

               

              But should this not be the responsibility of the gateway and EPR to handle?

              Well I though that would not be needed. Filtering this out when a message enters at the gateway would work if there was only one provider in the bus. The ESB Message could never contain the the filtered out property and this would not be set on the jms message being sent internally, be it by the courier, or an outbound jms router.

              This was seen with a single provider, oracle, we were not passing these between different providers.

              If it's the same provider it should not have this problem. What am I missing ? :)

              Do you have any examples of the properties which you are allowed to set?

              Any property not starting with 'JMS' is considered an application property.

              I really think that we should not filter at all and that it's strange that a jms provider can choose to reject another vendors properties like this. I would have thought that they would simply pick up the ones they are is interested in and ignore the others. I also thought that all jms header properties could be used in message selectors which would be another reason not to reject properties like this. But this is only my view of this matter. There might be other things to consider about this and perhaps rejecting is a valid implementation choice.

              /Daniel

              • 4. Re: DefaultJMSPropertiesSetter, DefaultESBPropertiesSetter a
                kconner

                 

                "beve" wrote:
                Well I though that would not be needed. Filtering this out when a message enters at the gateway would work if there was only one provider in the bus. The ESB Message could never contain the the filtered out property and this would not be set on the jms message being sent internally, be it by the courier, or an outbound jms router.

                Sure, the ESB message would not contain it and we would not set it but the provider may :)

                "beve" wrote:
                If it's the same provider it should not have this problem. What am I missing ? :)

                - Gateway reads message, transforms it (removing properties) and sends it to ESB listener.
                - Oracle attaches the properties on sending.
                - Listener reads message and, as it has no filter, attaches JMS_Oracle properties to ESB message
                - We then send this message, then attempting to set banned properties.

                So the properties always exist in Oracle, but are read-only.

                "beve" wrote:
                Any property not starting with 'JMS' is considered an application property.

                Sorry, I was asking for examples of those which start with JMS_. Are there any which we would want to initialise?

                "beve" wrote:
                I really think that we should not filter at all and that it's strange that a jms provider can choose to reject another vendors properties like this. I would have thought that they would simply pick up the ones they are is interested in and ignore the others. I also thought that all jms header properties could be used in message selectors which would be another reason not to reject properties like this. But this is only my view of this matter. There might be other things to consider about this and perhaps rejecting is a valid implementation choice.

                Well, the issue is what we pull into the ESB message and then set on outgoing messages, not really selectors. The reading of these properties are not prevented, but the setting of them is.

                Perhaps we need to flip this on its head, have a set of provider specific *writeable* properties in the EPR to cover read-only *and* providers which do not ignore properties from other providers.

                Kev


                • 5. Re: DefaultJMSPropertiesSetter, DefaultESBPropertiesSetter a
                  beve

                  OK, I got it now. I was too focused on the original issue we had which is not the same.


                  • 6. Re: DefaultJMSPropertiesSetter, DefaultESBPropertiesSetter a
                    beve

                     

                    Sorry, I was asking for examples of those which start with JMS_. Are there any which we would want to initialise?

                    Actually thinking about this I don't think so and the best option would probably to be filter out all provider/vendor specific properties that start with JMS_, and do the same with all jms defined properties starting with JMSX except for JMSXGroupID and JMSXGroupSeq which are standard properties clients should use if they want to group properties. These two are the only JMSX properties that clients can set as far as I know.

                    - should we be ignoring JMS_XXX on a global basis?

                    After wasting some of your time and basically re-stating your suggestion in your original post I think so :)



                    • 7. Re: DefaultJMSPropertiesSetter, DefaultESBPropertiesSetter a
                      kconner

                       

                      "beve" wrote:
                      Actually thinking about this I don't think so and the best option would probably to be filter out all provider/vendor specific properties that start with JMS_,


                      Okay, that makes things easier to handle in that case.

                      "beve" wrote:
                      and do the same with all jms defined properties starting with JMSX except for JMSXGroupID and JMSXGroupSeq which are standard properties clients should use if they want to group properties. These two are the only JMSX properties that clients can set as far as I know.

                      The JMSX ones are already handled by the DefaultJMSPropertiesSetter and it would be simple enough to add the JMS_ ones to that.

                      "beve" wrote:
                      After wasting some of your time and basically re-stating your suggestion in your original post I think so :)

                      This is not a waste of time :)

                      Kev