views:

161

answers:

2

Hi,

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 ?

+1  A: 

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);

NOTE: I think you can still specify it that way. I'm not anywhere near where I can test it right now.

gwhitake
hey thanks, will try it and let you know
Anand
hey thanks dude it works, I just tried your fix. now I will have to understand what it means
Anand
Well, since you did a workaround in code rather than setting the managed object it means any other apps or modules sending JMS messages to that destination will also have the same problem. Set it in the administered objects (.bindings file, LDAP or whatever) and it is fixed without code and across all apps using that managed object.
T.Rob
@T.Rob - I agree that he should get the administered object setup to correctly receive jms messages, but from his question it appears that he has no control over the endpoint.
gwhitake
@gwhitake I wonder if we are talking about different things. The administered object I'm referring to is either the .bindings file, LDAP or managed by the local web app server, depending on how his app is running. So even if he has no control over the endpoint, *somebody* generated the WMQ Connection Factory managed object that his app fetches. If that person sets targclient then any code using that managed object works without modification.
T.Rob
Of course, the app may not even use JNDI to fetch the CF in which case this all doesn't apply and code modification is the only answer. But if there is a managed object then there's an opportunity to do the right thing not just with targclient but also with FAILIFQUIESCE and half a dozen other properties that are significant at run time. The scalable strategy is not to do this in code where every app has to be aware of the differences, code properly and then recode after upgrading to v7, but rather to do it in the managed objects where it is leveraged across many apps.
T.Rob
+1  A: 

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 at http://bit.ly/SupportPacMQC7

T.Rob