Hi Tom, On 30 March 2013 00:43, Tom M <td.hom...@gmail.com> wrote:
> We are presently are using the Java broker have now found a need to send > message with the destination address in some messages different than the > default address for a session. > > I was wondering if the Java Broker still has a problem with setting routing > key at message level (can not set the message's routing key different than > the session was created with) > I'll start by addressing the email subject directly in saying that the broker plays no part in setting the routingKey on messages being sent, it is a client-side concern, so there is no 'problem' with the broker here. I'm going to assume you meant default Destination for a MessageProducer, as Sessions do not have Destinations. JMS as an API offers two basic choices for influencing where a message is sent to, neither of which involve setting the Destination (which ultimately influences the underlying routingKey that will be used) on the Message itself: - When creating a MessageProducer (using e.g http://docs.oracle.com/javaee/6/api/javax/jms/Session.html#createConsumer%28javax.jms.Destination%29) you can supply a specific Destination that will be used for *all* Messages sent with the MessageProducer using one of the two send() methods on it that do not have a Destination argument ( e.g http://docs.oracle.com/javaee/6/api/javax/jms/MessageProducer.html#send(javax.jms.Message,%20int,%20int,%20long)). - Alternatively, if you want to use a single MessageProducer to send messages to a variety of Destinations, you can instead create one with no specific Destination specified (by passing null as the Destination, which creates what is often referred to as an 'anonymous producer' or 'unidentified producer') such that you have to supply the Destination when sending *every* Message by using one of the two send() methods that does include a Destination argument (e.g: http://docs.oracle.com/javaee/6/api/javax/jms/MessageProducer.html#send(javax.jms.Destination,%20javax.jms.Message,%20int,%20int,%20long)). The second way mentioned above is how to do what you seem to want by using the JMS API in the intended vendor-neutral way (which would isolate your application from use of vendor specific features and/or code), by creating an anonymous producer and then supplying the particular Destination with each call to send(). You can create Destinations on the fly using session.createQueue() and session.createTopic() calls. There is additioanlly a Qpid-specific (and additionally, specific only to the AMQP 0-10 path of the JMS client) way of influencing the routingKey that gets used (for Topics) by specifying a specific property on the Message, which I will talk to more below. > as described in ncdc's answer in: > > > http://stackoverflow.com/questions/9189379/apache-qpid-set-routing-key-at-message-level > > He points out in: > > > https://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageProducer_0_10.java > , > you'll see code like this: > > String routingKey = destination.getRoutingKey().toString();if > (deliveryProp.getRoutingKey() == null || ! > deliveryProp.getRoutingKey().equals(routingKey)){ > deliveryProp.setRoutingKey(routingKey);} > > > which would mean that even if you set a routing key on your message, it > will be replaced by the destination's routing key if the message's routing > key differs from the destination's routing key. > > I still see this code at this link, but I don't know if this is still the > active code. > What ncdc was trying to do ultimately fell foul of reaching into a vendor-specific and subject-to-change implementation class of the clients Message implementation to try and do something outwith the intended JMS behaviour of the client (where Destinations are controlled by the producer, and in no way by the message) and ran into the MessageProducer doing what the JMS spec defined it should do by sending the Message to the Destination it was given. The routingKey related code accessed via the message implementation is not intended to be used in that way or for that purpose, and so trying to do so did not work. There is a subsequent reply on that thread from Rajith (one of the Qpid developers) that you may have overlooked, and which is related here: "This can be easily done by specifying a per message subject. The "subject" as defined by the Qpid address scheme, would map to the routing key for Topics when using the 0-10 protocol. Message m = ssn.createMessage(); m.setStringProperty("qpid.subject", "my-subject"); prod.send(m); This allows you to use standard JMS interfacing while still using the Qpid add-ons." This would seem to offer an alternative to the standard vendor-neutral JMS approach discussed above, allowing you to actually influence the routingKey by setting the subject on the message, should you find that preferable to creating the Destination objects and happen to be using Topics. If you are using Queues, you would need to use the vendor-neutral JMS approach from above. > > If so, does this apply to "messaging" lib (vs. the "client" lib)? > > Also, does this apply if using a C++ client into the Java broker? And/or a > Java client into the Java broker? > > If still a limition of the Java broker, is it also a limitation of the C++ > broker? > I'm not particularly familiar with the C++ client I'm afraid so I'll have to let someone else really answer that point, however as the JMS client is able to do this in either a vendor neutral or vendor specific way I would expect the c++ client is too. As mentioned initially, the setting of the routingKey is entirely client side and so any behaviour there is entirely independent of which broker you are using. Robbie