| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Queuing ZIP files (if type matters) |
« View previous topic :: View next topic » |
| Author |
Message
|
| Sotorin |
 Posted: Fri Jul 25, 2008 9:28 am Post subject: Queuing ZIP files (if type matters) |
 |
|
Newbie
Joined: 23 Jul 2008
Posts: 6
|
My application will have to route ZIP files from one WMQ to another. I have some issues associated with putting and retrieval of these files. As I talk to people (here in company) they tell me "ohh, the queue just contains a regular ZIP file plus its name in the header", which is good when you are telling this to management but not nearly good enough if you have to programmatically manipulate these files. Sorry I just started working with MQ this Monday.
Q1: I don't know how they put these ZIP files in a queue and I'm not sure how to retrieve them.
Q2: Is there a way - just by looking at a message via the manager - to figure out what options were used to inset it via MQPUT (and get it out via MQGET)? Look at an attached image. Would be be able to figure out how I put it in there (even though I show code below)?
Q3: Since there are million and one different options to write and read from the queue I'm affraid that if I don't match it exactly I could be in trouble. Another way to put it; someone puts data via WriteInt or WriteBytes then can I use an arbitraty method of reading thes files or do I have to use ReadInt/ReadBytes?
This is my attempt to put and retrieve ZIP files (in .NET). Please critique and/or point me in the right direction (trying to show only relevant code);
| Code: |
// read ZIP file
StreamReader sr = new StreamReader(@"C:\my.zip", Encoding.UTF8);
string output = sr.ReadToEnd();
sr.Close();
// put it in a queue
Queue = Mgr.AccessQueue(QueueName, MQC.MQOO_OUTPUT | MQC.MQOO_FAIL_IF_QUIESCING);
Msg.WriteBytes(Message);
Pmo = new MQPutMessageOptions();
Queue.Put(Msg, Pmo);
// now I have message in a queue + Msg.MessageId to use next
Queue = Mgr.AccessQueue(QueueName, MQC.MQOO_INPUT_AS_Q_DEF | MQC.MQOO_FAIL_IF_QUIESCING);
retmsg.CorrelationId = MessageId;
Queue.Get(retmsg, Gmo);
// here I get "Error in application" (CompCode 2, reason 2233)
|
 |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Jul 25, 2008 9:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
MQRC 2233 is clearly documented in the InfoCenter.
Please don't use this forum as a substitute for training - this is a general comment not just directed at Sotorin.
Read, think, try, read think try. Repeat. Post.
Yes, if you do not know the contents of a message, you will have some significant difficulty figuring out how to deal with the bytes it contains. This is equally true of any random bitstream - all those 0's and 1's only have meaning if we give it to them.
The PUT options used to send a message are generally irrelevant to the application doing the GET. Everything you need to know about a message is either in the message, or in the design requirements for your application. If it is not, something is wrong and you need to fix either the message or the design requirements.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Jul 27, 2008 8:50 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Looks like the message data is the ZIP file image (first 2 bytes are PK) and the message format is blank (ie. none). Just get the msg into a suitably sized buffer and then write the entire buffer out as a new file. QED.
My reading of WMQ Messages manual is that 2233 cannot be returned to an app prog by MQ. It can only appear as the reason code embedded in a channel event message.
_________________
Glenn |
|
| Back to top |
|
|
| Sotorin |
| Posted: Mon Jul 28, 2008 5:03 am Post subject: |
|
|
Newbie
Joined: 23 Jul 2008
Posts: 6
|
| Thank you very much for your help. I'll try your suggestions immediately. Lack of predetermined buffer might be a problem since the code I listed was ripped from either WMQ's help files or some other website during my search for answers and what they were trying to put into a queue was a simple string/text based message "hello world". I tried to adapt it to include ZIPs. Thanks again! |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Jul 28, 2008 8:06 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
It looks like the PUT code is building a suitable buffer, as the queued message length is 260060.
The GET code needs to allocate 'retmsg' to be at least this big.
_________________
Glenn |
|
| Back to top |
|
|
| Sotorin |
| Posted: Tue Jul 29, 2008 8:07 am Post subject: |
|
|
Newbie
Joined: 23 Jul 2008
Posts: 6
|
| There must be a programmatic way of figuring out the size of output buffer before you start reading msg off the queue, right? Or is it the case that you just blindly set buffer size based on your rough estimates? |
|
| Back to top |
|
|
| bower5932 |
| Posted: Tue Jul 29, 2008 8:37 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| If you are designing the application, you usually know what the (max) size of a message will be on the queue. However, if this can fluctuate, you can pick a buffer size that covers the message most of the time. For the rest of the times, you can check the return code to see that your message was truncated. You can then see how big it was, get another buffer, and re-issue the mqget. |
|
| Back to top |
|
|
| Sotorin |
| Posted: Tue Jul 29, 2008 11:45 am Post subject: This is what worked for me. |
|
|
Newbie
Joined: 23 Jul 2008
Posts: 6
|
Here is how I did this. BTW, this also works for other binary files like PDF, EXE, etc. Now for the code (assume that basic plumbing like connecting to the manager, picking queue is already accomplished). This is .NET version.
1. Read (convert) binary file to be put in a queue into byte array. Use Length property to size up your buffer.
| Code: |
FileStream fs = new FileStream(@"C:\input.zip", FileMode.Open);
byte[] buffer = new byte[fs.Length];
fs.Read(buffer, 0, buffer.Length);
fs.Close();
|
2. Apply default settings and write buffer into the queue
| Code: |
mqMsg.Write(buffer,0, buffer.Length);
mqMsg.Format = MQC.MQFMT_NONE;
mqPutMsgOpts = new MQPutMessageOptions();
mqQueue.Put(mqMsg, mqPutMsgOpts);
|
// that's it ... your binary msg should be in a queue now.
3. To retrieve it first read message bytes then use stream writer to write it out to disk (or move it to another queue .. whatever)
| Code: |
byte[] b = mqMsg.ReadBytes(mqMsg.MessageLength);
FileStream fs = new FileStream(@"C:\output.zip", FileMode.CreateNew);
fs.Write(b, 0, b.Length);
fs.Close();
|
Confusing part for me (other that being a new to this) was use of Write and ReadBytes. Actually this turned out to be the correct way. I was using WriteBytes (wrong) followed by ReadBytes(). and my messages were not properly stored and/or retrieved. When I tried to open up output.zip it complained that the archive was corruput. Use length(s) property(ies) to size up your buffers.
Thats's all. Thanks for your help to all that contributed. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Jul 29, 2008 5:48 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bower5932 wrote: |
| If you are designing the application, you usually know what the (max) size of a message will be on the queue. However, if this can fluctuate, you can pick a buffer size that covers the message most of the time. For the rest of the times, you can check the return code to see that your message was truncated. You can then see how big it was, get another buffer, and re-issue the mqget. |
If the max size of a msg is widely variable and large, a common coding technique is to get the message with a 0 buffer size. MQ will return the MQMD and the length of the message. Then get the message again using its msgid & correlid, this time providing into a suitably sized msg data buffer.
MQ v7.0 introduces asychronous consume (aka callback) to the MQI, where MQ kindly allocates a buffer and returns a pointer to the msg data. See new calls MQCB and MQCTL.
_________________
Glenn |
|
| 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
|
|
|
|
