| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Perl script to Move messages between queues & retain con |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjb_saper |
 Posted: Wed Feb 03, 2016 5:50 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
Again your MQGET has a dangerous option:
| Code: |
| MQGET Successful using MQGMO_FAIL_IF_QUIESCING | MQGMO_ACCEPT_TRUNCATED_MSG | MQGMO_BROWSE_NEXT |
Please remove MQGMO_ACCEPT_TRUNCATED_MSG and handle the error by increasing the buffer accordingly...
How would you like for your application to have only a fragment of the original message, if you do have to resend / reprocess that message? 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| LouML |
| Posted: Wed Feb 03, 2016 6:21 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| fjb_saper wrote: |
Again your MQGET has a dangerous option:
| Code: |
| MQGET Successful using MQGMO_FAIL_IF_QUIESCING | MQGMO_ACCEPT_TRUNCATED_MSG | MQGMO_BROWSE_NEXT |
Please remove MQGMO_ACCEPT_TRUNCATED_MSG and handle the error by increasing the buffer accordingly...
How would you like for your application to have only a fragment of the original message, if you do have to resend / reprocess that message? |
I have BufferLength set to 4MB on the MQGET call, which is much larger than any message we deal with. It seems unlikely that this will occur. However, your objection is noted.
Maybe I'll make it an optional runtime flag, to allow or disallow truncated msgs.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 03, 2016 6:35 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
MQ will always return a buffer that holds the entire message (unless accept truncated messages), and it won't pad this to the size of the passed in buffer.
So if 4MB is significantly larger than your message size, you'll never get a full 4MB buffer.
And if you use accept truncated messages on some other queue, where the messages are much larger - how will your user know that the message that was copied/moved is now smaller than the original?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| LouML |
| Posted: Thu Feb 04, 2016 5:26 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| mqjeff wrote: |
MQ will always return a buffer that holds the entire message (unless accept truncated messages), and it won't pad this to the size of the passed in buffer.
So if 4MB is significantly larger than your message size, you'll never get a full 4MB buffer.
And if you use accept truncated messages on some other queue, where the messages are much larger - how will your user know that the message that was copied/moved is now smaller than the original? |
Let me start off by saying I've removed the MQGMO_ACCEPT_TRUNCATED_MSG option so I can focus on the context issue.
In hindsight, I should not have used it since (IMHO) I don’t believe I ever would have received a truncated message.
However, this was my rationale for using MQGMO_ACCEPT_TRUNCATED_MSG.
-The queue definitions in our firm are the same between Prod and DR. So if a queue has a MAX length of 4194304 in Prod, it has it in DR.
-4MB is larger by far than any message on any queue in our firm .
-To me, if a message was successfully Put to the Source queue by an application, it should make it to the Target queue without any issues.
So, If I set BufferLength (input) to 4MB, it should accommodate any message I could possibly receive
If any of my assumptions above were incorrect, then I suppose I’d have learned the hard way.
I must say, I truly do appreciate the opinions and insights from so many of the senior members of this forum. Even when opinions vary, it's nice to hear all sides.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| LouML |
| Posted: Thu Feb 04, 2016 5:40 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| mqjeff wrote: |
| It's odd that adding the context would alter which mqconn you get. But there at least were some old restrictions on using more than one qmgr connection in a single thread - that you would always get the same handle back. This does match your situation, except for the part about working without context options. |
I'm not sure I follow. I get the correct mqconn both ways. Did you get this from the output I posted? If so, I can see the confusion.
I basically test this by moving the messages back and forth between the two QM/Q's. So, to do this, I change the command line options (source values use 1 and Target options use 2).
This moves mesages from QMTEST1 to QMTEST2
| Code: |
[mqm@mqm3d ~]$ ./Queue2QueueNEW.pl -m1 QMTEST1 -q1 QL.DEV.TEST2 -x1 'NMS.SVRCONN/TCP/mqdev(1418)' -m2 QMTEST2 -q2 QL.DEV.TEST2 -x2 'NMS.SVRCONN/TCP/mqdev(1419)'
---------------------------- Move FROM -----------------------------
MQ Queue Manager = QMTEST1
Queue Name = QL.DEV.TEST2
MQSERVER = NMS.SVRCONN/TCP/mqdev(1418)
Channel = NMS.SVRCONN
Transport = TCP
Hostname(port) = mqdev(1418)
---------------------------- TO -------------------------------------
MQ Queue Manager = QMTEST2
Queue Name = QL.DEV.TEST2
MQSERVER = NMS.SVRCONN/TCP/mqdev(1419)
Channel = NMS.SVRCONN
Transport = TCP
Hostname(port) = mqdev(1419)
---------------------------------------------------------------------
Connected to QMTEST1 (HConn1 = 16777222) at mqdev(1418) using channel NMS.SVRCONN
Connected to QMTEST2 (HConn2 = 16777224) at mqdev(1419) using channel NMS.SVRCONN
---------------------------------------------------------------------
[mqm@mqm3d ~]$ |
This moves mesages from QMTEST2 to QMTEST1
| Code: |
[mqm@mqm3d ~]$ ./Queue2QueueNEW.pl -m2 QMTEST1 -q2 QL.DEV.TEST2 -x2 'NMS.SVRCONN/TCP/mqdev(1418)' -m1 QMTEST2 -q1 QL.DEV.TEST2 -x1 'NMS.SVRCONN/TCP/mqdev(1419)'---------------------------- Copy FROM -----------------------------
MQ Queue Manager = QMTEST2
Queue Name = QL.DEV.TEST2
MQSERVER = NMS.SVRCONN/TCP/mqdev(1419)
Channel = NMS.SVRCONN
Transport = TCP
Hostname(port) = mqdev(1419)
---------------------------- TO -------------------------------------
MQ Queue Manager = QMTEST1
Queue Name = QL.DEV.TEST2
MQSERVER = NMS.SVRCONN/TCP/mqdev(1418)
Channel = NMS.SVRCONN
Transport = TCP
Hostname(port) = mqdev(1418)
---------------------------------------------------------------------
Connected to QMTEST2 (HConn1 = 16777222) at mqdev(1419) using channel NMS.SVRCONN
Connected to QMTEST1 (HConn2 = 16777224) at mqdev(1418) using channel NMS.SVRCONN
---------------------------------------------------------------------
[mqm@mqm3d ~]$
|
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 04, 2016 5:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| LouML wrote: |
| mqjeff wrote: |
| It's odd that adding the context would alter which mqconn you get. But there at least were some old restrictions on using more than one qmgr connection in a single thread - that you would always get the same handle back. This does match your situation, except for the part about working without context options. |
I'm not sure I follow. I get the correct mqconn both ways. Did you get this from the output I posted? If so, I can see the confusion. |
No, sorry. I was responding to the bit where you said that using context options didn't work for MOVE. Or at least it looked like it didn't. And I had misunderstood the conditions that you said were relevant when this happened.
If that's not at all what you're talking about, then 
 
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 04, 2016 5:59 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
So what you're saying is that when you're moving the messages between 2 qmgrs context option SAVEALL does not work for you?
Has the id / group been authorized for SAVEALL on the target object?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
