| Author |
Message
|
| Mut1ey |
 Posted: Fri Apr 21, 2006 3:46 am Post subject: accessQueue Hangs |
 |
|
Acolyte
Joined: 07 Oct 2005
Posts: 74
Location: England
|
Hello
We are having a strange problem with a base Java application that used to work but doesn't seem to anymore. When the client reverts to an earlier version of the code, that used to work, it still does not. There have been no changes to the MQ infrastructure and no changes to the MQ code except at the message level, which is clearly after the accessQueue command. Debug information reports that the accessQueue call does not return control to the thread.
MQ5.3 CSD 10 Windows 2000
The form of the command is:
MQQueue outgoingQueue = qManager.accessQueue(queueName, OUTGOING_OPEN_QUEUE_OPTIONS, queueManager, null, null);
No error is thrown/ caught and the command does not complete. We have even tested with hard coded queue and qmanager values that are do not exist with the same result. If I use the API exerciser I can write to this queue ( a local non-clustered queue resolved through the cluster - hence the qmgr name in the call).
Does anyone have any ideas? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Apr 21, 2006 3:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
"local non-clustered queue resolved through the cluster"?
What?
Is it a QLOCAL on the qmgr, or a QCLUSTER?
If it's a QLOCAL and it's not shared in the cluster, you can't use the cluster to resolve it! If it's shared in the cluster, it's not a "non-clustered queue"!
Is the queueName you are passing the actual name of the queue, or the name of an alias to the queue?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Mut1ey |
| Posted: Fri Apr 21, 2006 3:56 am Post subject: |
|
|
Acolyte
Joined: 07 Oct 2005
Posts: 74
Location: England
|
| Maybe resolved is the wrong word, it is routed via the cluster. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Apr 21, 2006 4:01 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
That doesn't clear up my confusion.
On the queue manager you are connecting to, is the queue a QLOCAL or a QCLUSTER?
Is the QLOCAL, wherever it is, shared in the cluster or not?
Is the name you are passing in the variable "queueName" the actual name of the queue?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Mut1ey |
| Posted: Fri Apr 21, 2006 4:19 am Post subject: |
|
|
Acolyte
Joined: 07 Oct 2005
Posts: 74
Location: England
|
Jeff
We issue the accessQueue call on the Windows machine. There are no local/ remote/ alias queues that match the name on the local qmgr. Ther is no cluster q that matches the name. However, on the accessQueue call we also specify the remote qmgr name. The queue that we are accessing is a local queue that resides on this remote qmgr. Because that qmgr is known about in the cluster the message is routed to it.
HTH
Neil |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Apr 21, 2006 4:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Okay. So it's a remote queue that you are referencing directly, without using a QREMOTE.
What happens if you create a qremote or share the queue in the cluster - does the accessQueue return?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Mut1ey |
| Posted: Mon Apr 24, 2006 5:01 am Post subject: |
|
|
Acolyte
Joined: 07 Oct 2005
Posts: 74
Location: England
|
| The application developers are checking their code again. I will keep you posted. |
|
| Back to top |
|
|
| Mut1ey |
| Posted: Wed May 24, 2006 4:11 am Post subject: |
|
|
Acolyte
Joined: 07 Oct 2005
Posts: 74
Location: England
|
Yes, indeed the developers had coded incorrectly, not realising that the queuemanager object blocks between application requets.
| Quote: |
| The implementation of WebSphere MQ classes for Java ensures that, for a given connection (MQQueueManager object instance), all access to the target WebSphere MQ queue manager is synchronized. A thread that wants to issue a call to a queue manager is blocked until all other calls in progress for that connection are complete. If you require simultaneous access to the same queue manager from multiple threads within your program, create a new MQQueueManager object for each thread that requires concurrent access. (This is equivalent to issuing a separate MQCONN call for each thread.) |
Although their application seemed to work before, they were not doing the first step. which blocks the second request. This is consistent with no-error being returned but the call appearing to "hang".
Thanks
Neil |
|
| Back to top |
|
|
|
|
