Author |
Message
|
chetan_aggarwal_in |
Posted: Fri Jun 04, 2010 4:34 am Post subject: Thread blocked at MQQueueManagerFactory.createQueueManager |
|
|
Newbie
Joined: 04 Jun 2010 Posts: 2
|
Hi,
We are using 6.x Websphere MQ.
We have two MBeans M1 and M2. M1 will connect to QM1 and open/close session every 1 minute to check whether QM1 is up or not. Similarly M2 will connect to QM2 and open/close session every 1 minute to check QM2 availablity.
Now when QM2 goes down, M1 thread (Which connects to QM1) is getting blocked. Following is the stack trace:
Code: |
Thread: Thread-11 : priority:5, demon:false, threadId:201, threadState:BLOCKED,
threadLockName:java.lang.Object@5a44b57
com.ibm.mq.MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:127)
com.ibm.mq.MQQueueManager.(MQQueueManager.java:526)
com.ibm.mq.MQSPIQueueManager.(MQSPIQueueManager.java:69)
com.ibm.mq.jms.MQConnection.createQM(MQConnection.java:2007)
com.ibm.mq.jms.MQConnection.createQMNonXA(MQConnection.java:1496)
com.ibm.mq.jms.MQQueueConnection.(MQQueueConnection.java:150)
com.ibm.mq.jms.MQQueueConnectionFactory.createQueueConnection(MQQueueConnectionFactory.java:185)
|
QM1 and QM2 are queue managers on different machines.
Any help will be appreciated.
Thanks. |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Jun 04, 2010 4:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
This is a terrible way to check for qmgr availability, and will likely lead to excessive stale svrconn channels and other bad results.
It also only tells you that during the exact instant that you checked, the qmgr happened to be available, and nothing about whether the qmgr is available the very next instant.
That said, you have shown nothing about how you have coded your queue manager connection, so we can not tell you more about why it is "locking" up, nor even whether the thread lock has anything to do with MQ or not. |
|
Back to top |
|
 |
kvmkreddy |
Posted: Fri Jun 04, 2010 5:29 am Post subject: |
|
|
Newbie
Joined: 21 Jan 2010 Posts: 2
|
Hi,
First of all Thank you for your prompt reply.
Please find the below code that we are using for this. This code will be running in a separate thread then the MBean main thread.
Code: |
public void ping() throws Exception {
QueueSession session = null;
try {
QueueConnection connection = (QueueConnection) getConnection();
session = connection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
} catch (Exception e) {
close();
throw e;
} finally {
close(session);
}
}
protected Connection getConnection() throws Exception {
if (connection == null) {
connection = createConnection();
}
return connection;
}
protected Connection createConnection() throws Exception {
return connectionFactory.createQueueConnection();
}
|
|
|
Back to top |
|
 |
Vitor |
Posted: Fri Jun 04, 2010 7:14 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
kvmkreddy wrote: |
First of all Thank you for your prompt reply.
|
Reply? You seem to be a different poster.
I agree with mqjeff - this is not a good thing to do even if you can get it to work. What exactly is the requirement here? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Jun 04, 2010 7:00 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Check the samples, your close statements are all wrong  _________________ MQ & Broker admin |
|
Back to top |
|
 |
chetan_aggarwal_in |
Posted: Sun Jun 06, 2010 5:24 am Post subject: |
|
|
Newbie
Joined: 04 Jun 2010 Posts: 2
|
Hi Vitor, KVMReddy and me are working on this requirement together.
Our requirement is to implement a High availability solution for MQ. We have two Qmgrs, a primary and backup. We keep sending messages to Primary Qm. If it goes down, we start sending messages to QM2.
To keep track of both QMs availability, we have a separate thread which keeps polling primary and secondory QMs every minute and maintains state for both QMs.
Main client check with state to find out which QM is up and then send message.
As mentioned in code below, to check availbity of QM, we create a Queue session then close it. If an exception is raised, then we close connection and mark it as NULL. So that in next attempt, it will try to recreate a new connection.
Please let us know best ways to handle this scenario?? Quick links to good examples will be great.
Thanks |
|
Back to top |
|
 |
PeterPotkay |
Posted: Sun Jun 06, 2010 5:57 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
chetan_aggarwal_in wrote: |
Our requirement is to implement a High availability solution for MQ. We have two Qmgrs, a primary and backup. We keep sending messages to Primary Qm. If it goes down, we start sending messages to QM2. |
That is not High Availability.
chetan_aggarwal_in wrote: |
To keep track of both QMs availability, we have a separate thread which keeps polling primary and secondory QMs every minute and maintains state for both QMs.
|
That is a poor design. You seem to think that if you check the QM availability at 12:03:00 and it is up, you are guaranteed that the QM will be up until 12:04:00? Why can't the QM go down at 12:03:01? Will you check every second then? Why can't it go down at 12:03:00.001?
Use MQ 7.0.1.2, use MQ Client Channel Tables, connect, open and start putting. If any calls fail, reconnect (the channel tables will take you to an available QM) open and start putting again.
Checking for QM availability is pointless. Do you have code that checks the q depth before doing an MQ get, which is just as bad? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Vitor |
Posted: Sun Jun 06, 2010 4:53 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
chetan_aggarwal_in wrote: |
Please let us know best ways to handle this scenario?? |
Buy High Availability software rather than reinventing the wheel. Especially this wheel, which as my worthy associate points out is not a circular wheel but rather a square one (i.e. it doesn't run all that well!) _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
kvmkreddy |
Posted: Wed Jun 16, 2010 4:54 am Post subject: |
|
|
Newbie
Joined: 21 Jan 2010 Posts: 2
|
Hi All,
After googling the error, I am able to find this is an existing MQ issue and had the fix for this.
IZ33798: DEADLOCK IF MULTIPLE THREADS ARE ACCESSING WEBSPHERE MQ BASE JAVA METHODS CONCURRENTLY AND A COMMUNICATIONS FAILURE OCCURS:
http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg1IZ33798
Fortunately, my MQ server is 6.0.2.8. I upgraded my MQ client jars to 6.0.2.8 which resolved this DEAD LOCK problem.
Thanks
Murali |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Jun 16, 2010 8:11 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
I am sure this is not your problem as it talks about java base and you are using JMS. However the fix packs have also a lot of JMS fixes... so it could well be that your problem is taken care of in the fixpack.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jun 17, 2010 5:21 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
kvmkreddy wrote: |
Fortunately, my MQ server is 6.0.2.8. I upgraded my MQ client jars to 6.0.2.8 which resolved this DEAD LOCK problem.
|
And resolving this problem doesn't resolve the problem articulated further up this thread with your design. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|