I'm using Spring jms to send jms messages to websphere mq using the target client as 1 at the destination resolver. However this causing to drop all the custom headers I've set to the jms message. When I set the target client as 0 it works perfectly bt I need to keep it at 1 for some other reason. Can somebody explain whats happening here and a possible solution. Thanks.
In MQ JMS headers are implemented as properties in an MQ RFH2 header on the message. By specifying a target client of WMQ_TARGET_DEST_MQ (1) you're instructing the MQ JMS client to strip the RFH2 header away. Which in your case means you lose your custom headers. So by setting WMQ_TARGET_DEST_MQ you're essentially opting out of this feature.
You either need to use WMQ_TARGET_DEST_JMS (0) which you know works, or find another way to pass the data in your custom headers to the receiving application.
One option if you want to continue with WMQ_TARGET_DEST_MQ is to include your custom headers in the message body as name/value pairs - you just need to make sure the receiving application can understand it.
Related
We are using Istio/Zipkin as a tracing system on our server to add the dynamic headers through Istio sidecar proxy for tracing the request later on using Zipkin. Is there anyway we could disable istio for a certain request.
Problem is, we are working with JMS queues, and when JMS listener tries to listen to a certain queue, it sees the headers like x-request-id added by the istio dynamically and it gives an error (as it'll accept header keys only in camelCase or with underScore or $). We can change header keys added by istio, so we want either istio to not to add headers in some specific requests (the one queue is making).
I've searched google but couldn't find anything about it.
Following is the error message we are getting:
Setup of JMS message listener invoker failed for destination 'queue' - trying to recover.
Cause: Identifier contains invalid JMS identifier character '-': 'x-request-id'
I'm using jmeter to put message to websphere mq and my another program will pick up that message from mq queue.
When I put manually to mq queue, the message I pick up from my program is exactly the same message I put.
However, when I put message to mq queue using jmeter, the message I pick up from my program became 'RFH :)'. I guess I need to remove RFH header or change the way to put message using Jmeter.
any pointer would be appreciated
Thanks
thank you #siarheib. I set property control to 'None' for message queue. and It works.
I have a Java JMS application that reads messages from a MQ queue. My application can successfully read a message and pull out the JMS headers (e.g. JMSDeliveryMode, JMSPriority etc) and the message body, but I can not access the <usr> folder part of the message.
I am placing messages on a queue using RFHutil. Under the RFH tab I am ticking 'Include RFH V2 Headers' and 'usr', and under the usr tab I have test1=1. I can see the <usr><test1>1</test1></usr> in the message if I browse the queue using MQExplorer, so I think I'm setting the usr folder correctly.
I have outputted the whole of message.getPropertyNames() enumeration (as discussed at topic JMS passing entire Application data <usr> block, but my usr fields are not under there. My message body also does not contain my usr fields.
I've also read on the MQ v7 info center you need to set WMQ_MESSAGE_BODY to WMQ_MESSAGE_BODY_MQ, but I am using v6MQ and do not know if this is relevant/how to set this value.
How can I get access to the usr folder using the JMS API?
Any help/pointers would be much appreciated as I am fairly new to JMS programming.
A first question is why is the USR folder of importance? Are you attempting to get your JMS application to interoperate with messages that put using another application that writes custom RFH2 headers.
RFHUtil is primarily used for test purposes.
MQ JMS originally used the RFH2 heasder to specifically send the JMS properties. Therefore the MQ JMS code reads the message, removes the RFH2 and processes it into a full JMS Message.
If you want the JMS API to fully read the RFH2, then the properties for reading the MQ message you've highlighted are correct. However those are not in MQ v6. Be aware that mq v6 and V7.0.1 are now out of support. Would strongly recommend that you investigate upgrading to MQ v8 - at minimum MQ 7.5.
CLients are freely downloadable if you are a developer and connecting to an estbalished QueueManager. Client versions don't have to match the QM.
I am sending messages to a remote queue, to which I have no control.
I send a xml file as message but when the application reads the message it gets a message header like
<mcd><Msd>jms_text</Msd></mcd> \0\0\0l<jms><Dst>queue:///TEST</Dst><Tms>1281475843707</Tms><Cid></Cid><Dlv>1</Dlv></jms>
i don't want this message header to be present and my code for sending this message is as follows:
Properties props = new Properties();
props.setProperty("java.naming.factory.initial",this.initialFactory);
props.setProperty("java.naming.provider.url", url);
Context context = new InitialContext(props);
QueueConnectionFactory qcf = (QueueConnectionFactory) context.lookup(this.context);
qConn = qcf.createQueueConnection();
queue = (Queue)context.lookup(name);
qSession = qConn.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
qConn.start();
QueueSender send = qSession.createSender(queue);
String text = "My xml file";
TextMessage tm = qSession.createTextMessage(text);
send.send(tm);
send.close();
How do I avoid this ?
It appears that you are sending a jms message to a non jms destination. How is the message being consumed on the destination? Is it expecting a native MQ message? The receiver is not understanding the MQRFH2 header that stores the JMS header properties.
You should either configure the destination to understand jms or your can do something like the following to tell the mq jms that your receiver is a non-jms client.
((com.ibm.mq.jms.MQQueue) queue).setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ);
Have a look at the properties for JMS objects as listed in the docs. On the administered object there is a property called TARGCLIENT which should be set to 'MQ'. Although you may have no control over the administered object, it is the responsibility of the person who administers the managed objects to set this property correctly. If the destination does not understand the RFH2 headers (which WMQ v6 uses to hold JMS properties) then any WMQ JMS applications which send messages to that destination must have that property set.
Incidentally, the fact that you are having this problem tends to indicate that the application consuming messages is still at v6. Please be aware that v6.0 of WMQ is end-of-life as of Sept 2011. If you switch to v7 now at both the QMgr and the client side, you can manage this with simple settings on the queue itself. The legacy app will understand the messages regardless of whether they have an RFH2 attached and the client app will see the responses as JMS messages regardless of whether the legacy app adds RFH2 headers. Move to v7 now, save your self a whole lot of trouble developing this app and also avoid having to migrate to v7 next year.
WMQ v7 client downloads are available here
Update: End-of-life for WMQ V6 was pushed back to September 2012.
I have a system in which different server processes are handling requests passed as JMS messages from various clients via a JMS broker.
I am trying to identify the source of the messages. Is there a way to get the IP or some identifying information about the origin ?
Clarification: I already have the client deployed by unknown users, so I'm trying to avoid changing message classes...
There is an optional JMS header mentioned in the JMS specification called JMSXUserID which which identifies the user sending a message (which the broker validates and ensures is correct to avoid spoofing) which some JMS providers support.
For example here is how to enable it in Apache ActiveMQ
I do not believe so. At least I was not able to find a way.
If you need to send a reply back to the source of the message, you can have the sender set the "JMSReplyTo" property and reply back to that destination.
Or, you could change your messaging schema slightly and embed the source information message itself. The sender would identify himself in the message and the receive could read it from there.
If you have control over the construction of the messages being sent, you can always add the IP address to the message as a property. Then you could check for the value with the getStringProperty method on Message.
If you control the code of the clients sending the messages, you could invent some property name, say "IPOfSender", and include that property on every message with Message.setStringProperty().
// client code
String myIPString = ...;
Message m = session.createTextMessage();
m.setStringProperty("IPOfSender", myIPString);
...
Its depends on your JMS Server. Some servers have Admin tools/API's that allow you to view connection details.
Using glassfish, if you look at the getJMSMessageID() of the message, you should see a string to the effect of "ID:40-192.168.0.242(f5:62:c6:58:22:6f)-52506-122885191641". It appears as though the IP is a substring of the message id.
Please note that this is what I can see under our setup, so there may be other factors at play (ie. spring), but I know that string wasn't created by us programatically.
Short answer: NO