This content has been marked as final.
Show 7 replies
-
1. Re: DefaultJMSPropertiesSetter, DefaultESBPropertiesSetter a
beve May 13, 2009 9:50 AM (in response to kconner)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 May 13, 2009 10:03 AM (in response to 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 May 13, 2009 11:03 AM (in response to kconner)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 May 13, 2009 11:14 AM (in response to 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 May 13, 2009 11:31 AM (in response to kconner)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 May 14, 2009 3:19 AM (in response to kconner)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 May 14, 2009 4:32 AM (in response to 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