Author |
Message
|
jcv |
Posted: Fri Sep 14, 2012 5:45 am Post subject: how to get qmgr name of the remote clustered queue |
|
|
 Chevalier
Joined: 07 May 2007 Posts: 411 Location: Zagreb
|
How to get qmgr name of the remote clustered queue using Java?
Queue is open by using accessQueue method of MQQueueManager class returning MQQueue object, and don't know how to get that attribute from it. |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Sep 14, 2012 5:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
You can't.
Among other things, with a 'remote clustered queue', there might be MANY of them, that have MANY queue manager names.
If it is important that you address a message to a specific queue manager, then you either need to have configuration information that tells you what queue manager receives what message, or you need to use the Reply properties on the message itself to identify this.
There is no general purpose way to ask a local queue manager to find out the name of the queue manager hosting some remote queue. Even if the local queue manager knows the name of that remote queue directly, there can be an infinite number of name changes between the local queue manager and the real queue manager. |
|
Back to top |
|
 |
jcv |
Posted: Fri Sep 14, 2012 6:28 am Post subject: |
|
|
 Chevalier
Joined: 07 May 2007 Posts: 411 Location: Zagreb
|
Hence, this attribute of ImqQueue C++ class:
Quote: |
queue manager name
Name of the queue manager (possibly remote) where the queue resides. Do not confuse the queue manager named here with the ImqObject connection reference, which references the (local) queue manager providing a connection. The initial value is null.
|
is not exactly what I'm looking for here in Java? I always thought (without checking it by doing some sample app) that after opening queue without specifying qmgr where it resides, resolved qmgr name should be visible in that attribute. Or is it that such thing exists in C++ but not in Java? |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Sep 14, 2012 7:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
jcv wrote: |
is not exactly what I'm looking for here in Java? I always thought (without checking it by doing some sample app) that after opening queue without specifying qmgr where it resides, resolved qmgr name should be visible in that attribute. Or is it that such thing exists in C++ but not in Java? |
I wouldn't trust it in the C++ implementation.
But you might be able to get something using the getAttributeString method. |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Sep 14, 2012 8:23 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
if you need to lock in the qmgr for messages within a group, just use the pmo option open(fixed). You don't have to know where the queue resides. All you need to know is that all messages sent to the queue opened with "FIXED" go to the same qmgr. To resume load balancing open the same queue with option "NOT FIXED" and load balancing will happen when using this queue object..
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
jcv |
Posted: Mon Sep 17, 2012 11:15 am Post subject: |
|
|
 Chevalier
Joined: 07 May 2007 Posts: 411 Location: Zagreb
|
I don't know exactly why I actually thought that that attribute would contain resolved qmgr name, when there is one that according to its name looks like more appropriate candidate. Anyway, I printed out all possible candidates and learned that none of them was updated upon neither open nor put (meaning that it printed empty strings):
Code: |
...
ImqQueue * q = new ImqQueue();
q->setName("X");
q->setConnectionReference(manager);
q->setOpenOptions(MQOO_OUTPUT+MQOO_BIND_NOT_FIXED);
ImqMessage * msg = new ImqMessage();
ImqString strText( "Hello world!" );
msg->writeItem( strText );
for (int i=0;i<5;i++){
if (q->put(* msg)) {
cout << "put successful" << endl;
cout << "queueManagerName: " << q->queueManagerName() << endl;
cout << "resolvedQueueManagerName: " << q->resolvedQueueManagerName() << endl;
cout << "remoteQueueManagerName: " << q->remoteQueueManagerName() << endl;
} else cout << "put error: " << q->reasonCode() << endl;
}
...
|
Nothing really changed when I opened queue explicitely before entering for loop with q->open(), or when I additionally printed out these attributes immediately after open, or when I replaced MQOO_BIND_NOT_FIXED with MQOO_BIND_ON_OPEN (with respect to what's been printed, of course that it changed message routing behaviour from round robin to fixed, as expected). Only setting with q->setQueueManagerName resulted in queueManagerName() to return that same string.
@fjb_saper: Of course that I knew that, and these are by the way open options (MQOO_*), not pmo options, that one uses for opening queues. But I have a colleague, chief architect, who is especially inventive in finding areas which are not sufficiently covered with usual mq use cases. Although I told him on several occasions that using mq clusters can upset logic of applications with message affinities, he came up with even better idea, and now he wants to use qmgr cluster load balancing and fail over capabilities, but he needs to know to which instance message was put, because he needs to put another related message to the same qmgr but to another queue.
@mqjeff: I guess you were right about C++, at least about that particular implementation that I tried with (slightly older mq version). With respect to Java, we (him and I) tried that getAttributeString method without success, prior to my first post. Would you care to post a code sample if possible? |
|
Back to top |
|
 |
jcv |
Posted: Tue Sep 18, 2012 10:53 am Post subject: |
|
|
 Chevalier
Joined: 07 May 2007 Posts: 411 Location: Zagreb
|
We agreed on using client connection load balancing and fail over reconnection capabilities, so forget about this whole cluster thing and why queue attributes are not populated. It really doesn't matter at all. |
|
Back to top |
|
 |
jcv |
Posted: Thu Sep 20, 2012 3:09 pm Post subject: |
|
|
 Chevalier
Joined: 07 May 2007 Posts: 411 Location: Zagreb
|
Actually, resolvedQueueManagerName is an output field that can be found in MQPutMessageOptions Java class. And in my C++ sample, things somewhat changed when I added MQOO_INQUIRE, but not radically. Enough for me to realize that I coded it carelessly without checking q->reasonCode() after issuing getters. And last two return 6127 and 6101 without MQOO_INQUIRE, and 6127 and 2068 with it. Probably some MQOO_ is still missing there, but not of much use anyway, or importance since there's no need to use cluster. |
|
Back to top |
|
 |
jcv |
Posted: Sat Sep 22, 2012 10:33 am Post subject: |
|
|
 Chevalier
Joined: 07 May 2007 Posts: 411 Location: Zagreb
|
What was missing was realization that sw provides uniformity over APIs to a certain extent, and that resolvedQueueManagerName exists in ImqPutMessageOptions C++ class too, and this works (displays round robin):
Code: |
...
ImqQueue * q = new ImqQueue();
q->setName("X");
q->setConnectionReference(manager);
q->setOpenOptions(MQOO_OUTPUT+MQOO_BIND_NOT_FIXED/*+MQOO_INQUIRE*/);
ImqPutMessageOptions *pmo= new ImqPutMessageOptions();
ImqMessage * msg = new ImqMessage();
ImqString strText( "Hello world!" );
msg->writeItem( strText );
for (int i=0;i<5;i++){
if (q->put(* msg, *pmo)) {
cout << "put successful" << endl;
cout << "resolvedQueueManagerName: " << pmo->resolvedQueueManagerName() << endl;
} else cout << "put error: " << q->reasonCode() << endl;
}
...
|
Hence, without trying, I would say the same thing must work in Java too, although I must admit that when I spotted it for the first time I was sceptical and didn't feel like trying it, partially due to mqjeff's input. |
|
Back to top |
|
 |
mqjeff |
Posted: Sat Sep 22, 2012 2:48 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
The point about the resolved qmgr name is that there is no reason that it will in any way actually refer to a real qmgr name on a remote system, unless your MQ topology actually makes it true that way.
I.e. just because my app connects to QmgrA and decides that it is sending a message to QmgrB, there's no reason to expect that the message will actually arrive at QmgrB. it could arrive at QmgrXYZ through five other stops, due to name resolution.
So the only real reason to write code to get this is to attempt to provide some level of debugging - but it's just as easy to use amqsputc with the same values in order to do troubleshooting. |
|
Back to top |
|
 |
fjb_saper |
Posted: Sun Sep 23, 2012 3:37 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
mqjeff wrote: |
The point about the resolved qmgr name is that there is no reason that it will in any way actually refer to a real qmgr name on a remote system, unless your MQ topology actually makes it true that way.
I.e. just because my app connects to QmgrA and decides that it is sending a message to QmgrB, there's no reason to expect that the message will actually arrive at QmgrB. it could arrive at QmgrXYZ through five other stops, due to name resolution.
So the only real reason to write code to get this is to attempt to provide some level of debugging - but it's just as easy to use amqsputc with the same values in order to do troubleshooting. |
My preference would go to an MQTrace message to retrace the path(s) taken (see monitoring section of MQ manual)... and you might need to send more then one to see the alternatives...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
|