| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MSGSELECTION(CLIENT) vs MSGSELECTION(BROKER) |
« View previous topic :: View next topic » |
| Author |
Message
|
| matthewr |
 Posted: Mon Jan 27, 2003 5:28 am Post subject: MSGSELECTION(CLIENT) vs MSGSELECTION(BROKER) |
 |
|
Newbie
Joined: 09 Jan 2003
Posts: 8
Location: London
|
The TopicConnectionFactory has a property of MSGSELECTION. By default this is CLIENT. It can be changed to BROKER.
However this feature appears undocumented. Does anyone have any information about it? My best guess is this is where the evaluation of message selectors occurs.
The documentation in "MQ Using Java.pdf", page 288, appears counterintuitive:
"A property value might duplicate a value in a message’s body. JMS does not define a policy for what should or should not be made into a property. However, application developers must be aware that JMS providers probably handle data in a message’s body more efficiently than data in a message’s properties. For best performance, applications must use message properties only when they need to customize a message’s header. The primary reason for doing this is to support customized message selection."
Surely the properties in the header would be more efficient? Particularly if the message wasn't in the MRM? Can anyone explain this.
Thanks for any help. Cheers - Matthew
_________________
Cheerio |
|
| Back to top |
|
 |
| kingdon |
| Posted: Mon Jan 27, 2003 7:44 am Post subject: |
|
|
Acolyte
Joined: 14 Jan 2002
Posts: 63
Location: UK
|
Yes, MSGSELECTION(BROKER) means that the ability of the broker to evaluate message selectors can be exploited. To make use of this you need to be using one of MQSI, EventBroker or the embedded JMS provider in WAS5. The MA0C broker can't support server side selectors.
The section on message properties you refer to is a rather generic statement, which is basically trying to say that user properties are likely to have a higher cost than the same data carried in the message body. The higher cost might be in terms of a less compact data representation, or a cpu overhead in sending and receiving the message. In particular, if someone choose to place several thousand properties in the message header then this would likely have a negative impact on the performance of message selection. For this reason, the recommendation is to only place those data items that you actually want to use for message selection in the user properties, and put everything else in the message body. (Remember that from JMS a selector can only refer to properties, and not to the message body.)
Regards,
James. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
