| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQPUT1 equivalent in Java? |
« View previous topic :: View next topic » |
| Author |
Message
|
| Trinition |
 Posted: Wed May 07, 2003 8:40 am Post subject: MQPUT1 equivalent in Java? |
 |
|
Newbie
Joined: 07 May 2003
Posts: 2
|
As far as I can tell, there is no direct equivalent of MQPUT1 in the Java API for MQ. In trying to replicate the same functionality, I've come to believe that you can't make a 100% equivalent sequence of calls, either.
MQPUT1 is basically a OPEN, PUT and CLOSE. It is the open I truly have a problem with. The MQPUT1 call takes a connection handle as its first argument. As I understand it, this is a handle to the network connection to the MQ series server you received with MQCONN. Thus, when you call MQPUT1, you've already established a connection and you're only accessing the resource.
In the Java API, though, there is no rudimentary connection. It is buried underneath the MQQueueManager object. So, in order to do an MQPUT1 in Java, you must first connect to the queue manager, and then the queue, then PUT and then CLOSE. Doing it this way will open a new new network connection as part of the MQQeueueManager construction for each invocation.
The original code runs on a UNISYS mainframe and looks something like this, in pseudo-code:
| Code: |
hcon = MQCONN
while(true) {
msg = MQGET(hcon, ...)
reply = Process(msg)
MQPUT1(hcon, msg.replyToQMgr, msg.replyToQ, reply)
}
|
Thus, I do not know in advance what queue manager and queue the reply will go to, thus MQPUT1 is nice. But MQPUT1 gets to re-use the same connection handle (hcon) thus avoiding an additional network connection.
In my Java version, I'm forced to implicitly make a new network connection for every iteration of the loop since I must construct an MQQueueManager for the reply.
Any advice? I mean, maybe I've understood things incorrectly (I am a newbie). But this opening of a connection is killing me! |
|
| Back to top |
|
 |
| dnaren |
| Posted: Wed May 07, 2003 7:11 pm Post subject: |
|
|
Apprentice
Joined: 10 Aug 2001
Posts: 45
Location: Charlotte, NC
|
MQPUT1 is just an encapsulation of three calls OPEN, PUT and CLOSE. It doesn't do anything different when compared to issuing those three calls in sequence. Other than making your code smaller, it has no extraordinary benifits. Both MQPUT and MQPUT1 require a connection to the queue manager to OPEN a queue. You are not avoiding the OPEN call by using MQPUT1.
Looking at your code, Why don't you instantiate the MQQueueManager object before the loop (same place where you have hcon = MQCONN) and use that object inside your loop? |
|
| Back to top |
|
|
| Trinition |
| Posted: Thu May 08, 2003 3:39 am Post subject: QueueManager could "theoretically" vary |
|
|
Newbie
Joined: 07 May 2003
Posts: 2
|
The queue manager to reply to is specified by the incoming message. Thus, the incoming messages could specify different queue managers each time. It would be impossible to connect to the proper queue manager for reply before knowing what that proper queue manager is.
I've personally only ever used the Java API. The API in my pseudo-code is actually from am ALGOL program running on a Unisys mainframe. At first glance, it seems fairly similar to what I recall reading about the C API for MQ. In that, there is a call to establish a connection separete from opening either a queue manager or a queue. So, it was my belief that since I pass the handle (hcon) to the opened connection into MQPUT1 in the pseudo-code, the network connection is re-used to open both the queue manager and the queue for the put. The mere step of avoiding the establishment of a new network connection is a good optimization. However, this is all determined from guesswork, not concrete facts. |
|
| Back to top |
|
|
| JohnMN |
| Posted: Thu May 08, 2003 6:54 am Post subject: |
|
|
Novice
Joined: 26 Feb 2003
Posts: 19
|
When you issue a reply message, you stay connected to your local queue manager. You can "open" the replyToQ, even if that queue is on another queue manager.
I can explain the process in C terminology, but the basic concepts apply in any language.
When you issue the MQOPEN, you set the MQOD.ObjectName and MQOD.ObjectQMgr to the queue name and Qmgr name that you want to reply to.
You never actually connect to the ObjectQMgr. Your local QMgr looks at the ObjectQMgr field, and says "Is this Me?" If not, your QMgr will figure out where the ObjectQMgr is, and will send the message to the appropriate XMITQ to get it to that Qmgr.
But through the whole process, the hcon refers to your local queue manager. |
|
| Back to top |
|
|
| dnaren |
| Posted: Thu May 08, 2003 9:24 am Post subject: |
|
|
Apprentice
Joined: 10 Aug 2001
Posts: 45
Location: Charlotte, NC
|
MQPUT1(hcon, msg.replyToQMgr, msg.replyToQ, reply)
I would guess differently looking at the above line...
with msg.replyToQMgr and msg.replyToQ, you are just modifying/setting the message header (MQMD).
The queue manager and the application that's processing this posted message should deal with those replyToQMgr and replyToQ fields in the message header.
Just my opinion |
|
| Back to top |
|
|
| JohnMN |
| Posted: Thu May 08, 2003 10:10 am Post subject: |
|
|
Novice
Joined: 26 Feb 2003
Posts: 19
|
| dnaren wrote: |
MQPUT1(hcon, msg.replyToQMgr, msg.replyToQ, reply)
I would guess differently looking at the above line...
with msg.replyToQMgr and msg.replyToQ, you are just modifying/setting the message header (MQMD).
The queue manager and the application that's processing this posted message should deal with those replyToQMgr and replyToQ fields in the message header.
Just my opinion |
The line of code you reference is pseudo-code. The prototype of MQPUT1 from the API Reference is:
MQPUT1 (Hconn, ObjDesc, MsgDesc, PutMsgOpts, BufferLength,
Buffer, CompCode, Reason)
ObjDesc is the MQOD. In this structure, you indicate the name of the target queue manager (ObjectQMgr) and the queue (ObjectName) for where the message is to be sent.
MsgDesc is the MQMD. In this structure you can specify the name of a ReplyToQMgr and a ReplyToQ.
To reply to an incoming message, you copy values from the incoming MQMD (inMD) into the outgoing MQOD (outOD):
outOD.ObjectQmgr = inMD.ReplyToQMgr
outOD.ObjectName = inMD.ReplyToQ
In any event, the Hconn remains constant, and always refers to the local queue manager. |
|
| 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
|
|
|
|
