I am consuming message from IBM MQ queue. Messages are of format MQSTR. But message data is TEXT+Binary. This Binary data is nothing but a JPG image
When these messages are consumed by my JMS consumer, I can see some encoding issue for Binary data, due to which transformed image is distorted from original.
I have tried every possible aspect (different IBM specification). But was not able to make through.
If someone already faced such issue please suggest possible solution for it.
If the message has an MQSTR MQMD.Format, then it must be a text string. MQ will convert text strings between codepages when required (eg ASCII to Unicode). If the message is not meant to be a string - which it sounds like from your limited description - then whoever creates the message needs to set the format suitably, and the receiving app must be prepared to parse and convert the message body components.
Related
We are using JmsTemplate to send messages to an IBM MQ's local queue. We set MQMD property MsgType to 1, but when viewing the message header from the queue, the value is interpreted as MQMT_SYSTEM_FIRST instead of MQMT_REQUEST. Why is that? Is this the reason why the other party's system cannot return the reply message?
We are doing debugging with another system. According to their feedback, they checked our message header in the queue like this.
enter image description here
But based on past experience, our message should look like this (Please focus only on the MsgType field).
enter image description here
And there is no clue as to why these two different situations occur. Their values are both 1, but MQMT_SYSTEM_FIRST and MQMT_REQUEST are displayed respectively.
I suspect this is just a flaw in whatever you use to view the header in that it does not realize MQMT_SYSTEM_FIRST is never 'set', it is just a range identifier.
What are you using to view the header?
This question is really a duplicate of IBM MQMD header how to distinguish
I am looking to build an IM app using the Sinch SDK, but wanted to know what the max number of characters that I can send in a message is? Can't see that in the documentation.
There isn’t a fixed limit to how many characters can be included in a message. Messages will be split into multiple if size is too large, however we discourage from sending very large messages such as encoding images into headers…
I'm new to JMS and HornetQ.
I'm wondering if there is a way to implement Message Translator Pattern using HornetQ to split data from a message in a set of smaller data and send them. I explored Bridge and Divert solutions but I can't get how to do it using org.hornetq.core.server.cluster.Transformer and org.hornetq.core.server.ServerMessage. Where can I find some docs about it? Am I looking in the right direction?
In short no(I've no Idea on camel). You cannot modify the jms body once sent until its consumed by a client(body is immutable). However you can change message headers and message properties. The org.hornetq.core.server.cluster.Transformer interface is used for modifying the headers/properties. Hence you are left with two options.
Consume the message, chunk the message based on your algorithem and send to other queues or put back to the queue(but be careful to avoid loop, by having suitable selector).
Other approach is chunk the message then send with message property to differentiate the message. And use the diverter with filter based on the message property(you can use exclusive/non exclusive strategy to send only/send copy of message to the other queue.)
In the following JBoss/HornetQ user manual page you can see how HornetQ provides a mechanism for streaming data to a Message for a Queue using a java.io.InputStream. A JMS version of the same code is given. Has anyone come across an equivalent using IBM MQSeries / WebsphereMQ?
Say I have a large amount of data to place in the JMS Message which to me is just a stream of bytes. In the Hornet example, the stream is only read when the message is sent, so if it is, say a FileInputStream, then we only need enough memory to buffer a chunk of the bytes. I can use a javax.jms.BytesMessage to send in chunks of bytes and use the BytesMessage to buffer them. The problem with this is that the IBM implementation of BytesMessage (com.ibm.msg.client.jms.internal.JmsBytesMessageImpl) has to cache them until the Message is sent and if that is a large amount of data it is a problem. Worse it appears that although I am only sending bytes, the IBM implementation appears to keep duplicate copies, one in a BytesArrayOutputStream the other in a DataOutputStream.
In WebSphere MQ the closest thing to what you describe is a reference message. The method described in the Infocenter requires custom programming of channel exits to grab the filesystem object and put it into a message before it is transmitted over the channel. A complementary exit on the remote side saves the payload to a file and puts a reference to the file in the message that is returned to the app.
We also have programs in WMQ that take STDIN or a pipe at one end and put messages to a queue on the other end. A pair of these can act as a pipe through which line-oriented ASCII data flows between processes on separate machines. However, there's no JMS implementation of this and it doesn't work too well for binary data.
In WMQ, we have concept of Group and Segment.
Segmentation is supported in all OS except Z/OS.
Check for details here Segmentation In WMQ
Make use of GroupId, MsgSeqNumber, and Offset while putting the message.
While getting the message if you give MQGMO_COMPLETE_MSG in GMO, then all segments are joined automatically according to the MsgSeqNumber and
you will get a single message on the recieving application with a
single GET.
We are trying to use JMS to communicate with IMS region. The message reaches IMS and gets dropped since the message is not in the "required" format i.e. MQIMS.
How do we set the message sent from JMS code in MQIMS format? Is there an explicit way of setting the message format in the header? Do we need to set the LL, ZZ segments or do they get set automatically?
There is a property on your JMS container called something like "targetServer". Changing that to reflect MQ or MQIMS will prevent the sending of the MQRFH2 header and should fix your problem.