| Author |
Message
|
| balareddy |
 Posted: Tue Apr 04, 2006 1:56 am Post subject: JMS exception in multithreaded program |
 |
|
Acolyte
Joined: 06 Feb 2006
Posts: 54
|
Hi,
I am trying to execute application with standard JMS with MQSeries Queue for persistance. I am not using any App Server.
I have different Unix processes(again these are java programs) and each processor has some count(say 10 or 20,..) of threads. I created Connection Factory with JMSAdmin utility and using in Application with lookup. Every processor will create QManager at the begining and the same connection will be used by all the Threads in that processor.
If i run 2 or 3 processors, it will work fine. i.e. creates QM, getting connection,etc.. If i start more number of processors, it throws the following error and processor is crashed. but the processors which r already started works fine with same Context.
javax.jms.JMSException: MQJMS2005: failed to create MQQueueManager for 'sce1.de.db.com:QM.JMSMQ_TEST'
at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:556)
at com.ibm.mq.jms.MQConnection.createQM(MQConnection.java:2273)
at com.ibm.mq.jms.MQConnection.createQMNonXA(MQConnection.java:1701)
at com.ibm.mq.jms.MQQueueConnection.<init>(MQQueueConnection.java:144)
at com.ibm.mq.jms.MQQueueConnection.<init>(MQQueueConnection.java:54)
at com.ibm.mq.jms.MQQueueConnectionFactory.createQueueConnection(MQQueueConnectionFactory.java:106)
at de.gefm.cap2.processor.Config.<init>(Config.java:47)
Pls help me what is wrong here for running different Processors(java programs) with multithreading ???
I am running in AIX5.2 with MQ5.3 version.
_________________
bala |
|
| Back to top |
|
 |
| fschofer |
| Posted: Tue Apr 04, 2006 2:11 am Post subject: |
|
|
Knight
Joined: 02 Jul 2001
Posts: 524
Location: Mainz, Germany
|
Hi,
from Using Java manual:
| Quote: |
| MQJMS2005 Failed to create MQQueueManager for {0}. Explanation: JMS could not connect to a queue manager. {0} gives the name of the queue manager. User Response: Use the linked exception to determine the cause of this error. Check the queue manager is running and, if using client attach, that the listener is running and the channel, port and hostname are set correctly. If no queue manager name has been specified, check that the default queue manager has been defined. |
Can you please post the linked excpetion, there has to be some kind of MQ error code.
Greetings
Frank |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Apr 04, 2006 2:15 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
For one if you are running in an app server you need to really use JNDI to retrieve the connection factory otherwise you might be creating a pool of connections each time and end up consuming too many resources.
Do not forget to release resources no longer used. Finalizing will come way too late.
Each thread will need to create its own session. Close sessions before leaving the thread.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| balareddy |
| Posted: Tue Apr 04, 2006 2:30 am Post subject: |
|
|
Acolyte
Joined: 06 Feb 2006
Posts: 54
|
| fjb_saper wrote: |
For one if you are running in an app server you need to really use JNDI to retrieve the connection factory otherwise you might be creating a pool of connections each time and end up consuming too many resources.
Do not forget to release resources no longer used. Finalizing will come way too late.
Each thread will need to create its own session. Close sessions before leaving the thread.
Enjoy |
I used to get following linked exceptions::
javax.naming.ServiceUnavailableException: Unable to connect to the target queue manager sce1.de.db.com:1417/SYSTEM.DEF.SVRCONN. Root exception is com.ibm.mq.MQException: MQJE001: An MQException occured: Completion Code 2, Reason 2009
MQJE016: MQ queue manager closed channel immediately during connect
Closure reason = 2009
at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:242)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:276)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:296)
at com.ibm.mq.StoredManagedConnection.<init>(StoredManagedConnection.java:80)
at com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:171)
at com.ibm.mq.MQQueueManager.obtainBaseMQQueueManager(MQQueueManager.java:754)
at com.ibm.mq.MQQueueManager.construct(MQQueueManager.java:688)
at com.ibm.mq.MQQueueManager.<init>(MQQueueManager.java:417)
at com.ibm.mq.pcf.PCFAgent.connect(PCFAgent.java:317)
at com.ibm.mq.pcf.PCFAgent.<init>(PCFAgent.java:211)
at com.ibm.mq.pcf.PCFMessageAgent.<init>(PCFMessageAgent.java:150)
at com.ibm.mq.jms.context.MQContext.<init>(MQContext.java:131)
at com.ibm.mq.jms.context.WMQInitialContextFactory.getInitialContext(WMQInitialContextFactory.java:29)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:674)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:256)
at javax.naming.InitialContext.init(InitialContext.java:232)
at javax.naming.InitialContext.<init>(InitialContext.java:208)
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:93)
at de.gefm.cap2.processor.Config.getInitialContext(Config.java:5
at de.gefm.cap2.processor.Config.<init>(Config.java:44)
at de.gefm.cap2.processor.AbstractProcessor.<clinit>(AbstractProcessor.java:1632)
Caused by: com.ibm.mqservices.MQInternalException: MQJE001: An MQException occured: Completion Code 2, Reason 2009
MQJE016: MQ queue manager closed channel immediately during connect
Closure reason = 2009
at com.ibm.mq.MQInternalCommunications.establishChannel(MQInternalCommunications.java:1544)
at com.ibm.mq.MQInternalCommunications.<init>(MQInternalCommunications.java:523)
at com.ibm.mq.MQSESSIONClient.MQCONN(MQSESSIONClient.java:1316)
at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:218)
AND
javax.naming.NamingException: Caught a PCF Exception: com.ibm.mq.pcf.PCFException: MQJE001: Completion Code 2, Reason 2085. Root exception is com.ibm.mq.pcf.PCFException: MQJE001: Completion Code 2, Reason 2085
at com.ibm.mq.pcf.PCFMessageAgent.send(PCFMessageAgent.java:299)
at com.ibm.mq.pcf.PCFMessageAgent.send(PCFMessageAgent.java:224)
at com.ibm.mq.jms.context.MQContext.getAllQueues(MQContext.java:431)
at com.ibm.mq.jms.context.MQContext.list(MQContext.java:565)
at com.ibm.mq.jms.context.MQContext.list(MQContext.java:542)
at com.ibm.mq.jms.context.MQContext.lookup(MQContext.java:628)
at com.ibm.mq.jms.context.MQContext.lookup(MQContext.java:609)
at javax.naming.InitialContext.lookup(InitialContext.java:360)
Coming to your Question:
I can not release resources in each thread. because, all threads run indefinately in a loop. cosume msg from one Q and send msg to another Q..
_________________
bala |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Apr 04, 2006 12:09 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
When you get a reason code of 2009 MQRC_CONNECTION_BROKEN you have no choice but to close all open connections, re-establish them and recreate a session per thread.
The session consumes minimal time. The connection takes some time to establish and is usually cached in the App server's container...
What version and CSD are you at?
If you are using a MessageListener or MDB do you have as well a ConnectionListener to make sure you get notified on connection problems?
| Quote: |
| javax.naming.NamingException: Caught a PCF Exception: com.ibm.mq.pcf.PCFException: MQJE001: Completion Code 2, Reason 2085. Root exception is com.ibm.mq.pcf.PCFException: MQJE001: Completion Code 2, Reason 2085 |
2085 0x00000825 MQRC_UNKNOWN_OBJECT_NAME
Are you trying to access and object that is referenced in your jndi context but does not exist on the qmgr?
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| balareddy |
| Posted: Tue Apr 04, 2006 9:08 pm Post subject: |
|
|
Acolyte
Joined: 06 Feb 2006
Posts: 54
|
| fjb_saper wrote: |
When you get a reason code of 2009 MQRC_CONNECTION_BROKEN you have no choice but to close all open connections, re-establish them and recreate a session per thread.
The session consumes minimal time. The connection takes some time to establish and is usually cached in the App server's container...
What version and CSD are you at?
If you are using a MessageListener or MDB do you have as well a ConnectionListener to make sure you get notified on connection problems?
| Quote: |
| javax.naming.NamingException: Caught a PCF Exception: com.ibm.mq.pcf.PCFException: MQJE001: Completion Code 2, Reason 2085. Root exception is com.ibm.mq.pcf.PCFException: MQJE001: Completion Code 2, Reason 2085 |
2085 0x00000825 MQRC_UNKNOWN_OBJECT_NAME
Are you trying to access and object that is referenced in your jndi context but does not exist on the qmgr?
Enjoy |
Hi,
I am not using any App server in my application. it is standalone standard JMS programs accessing MQSeries thru JNDI context for connection factory and Q's.
| Quote: |
| Are you trying to access and object that is referenced in your jndi context but does not exist on the qmgr? |
I am trying to access existing objects in qmgr. bcz same of my processors are running fine.
Is there any limitation on creating Connections in qmgr?? bcz, i am creating connecton in each processor by getting connection factory thru JNDI. so every processor is trying to create one Connection.
_________________
bala |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Apr 05, 2006 2:19 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
As for the number of allowed connections and needed connections read the JMS topology red paper.
For the last 2085 says it clearly enough: Typo or bad jndi or bad case.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rkrier1964 |
| Posted: Sun Aug 13, 2006 4:26 pm Post subject: MQContext is not Thread Safe |
|
|
Newbie
Joined: 13 Aug 2006
Posts: 4
|
I've written a little java app that creates a MQContext object and JMS objects from it. If I do not close the context (context.close()), I don't have any problems, but this causes connection leaks. If I do close the context, other threads blow up when they try to create objects. Here is my app. It blows up consistently.
----------------------------
import javax.naming.Context;
import javax.naming.NamingException;
import javax.jms.*;
import java.util.Hashtable;
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.IOException;
public class MQContextTest {
public static void main(String[] args) {
int numThreads = 10;
TestThread[] threads = new TestThread[numThreads];
String jndiUrl = "host:1414/SYSTEM.DEF.SVRCONN";
String jmsQueueName = "myqueue";
String jmsQueueConnectionFactoryName = "myqueuemanager";
for (int i = 0; i < numThreads; i++) {
threads[i] = new TestThread(jndiUrl, jmsQueueName, jmsQueueConnectionFactoryName);
threads[i].start();
}
System.out.println("Press enter to exit.");
try {
new BufferedReader(new InputStreamReader(System.in)).readLine();
} catch (IOException e) { }
}
private static class TestThread extends Thread {
private String jndiUrl;
private String jmsQueueName;
private String jmsQueueConnectionFactoryName;
public TestThread(String jndiUrl, String jmsQueueName, String jmsQueueConnectionFactoryName) {
this.jndiUrl = jndiUrl;
this.jmsQueueName = jmsQueueName;
this.jmsQueueConnectionFactoryName = jmsQueueConnectionFactoryName;
}
public void run()
{
try {
MQContext context = getContext();
System.out.println(getName() + " Created context.");
Queue jmsQueue = (Queue) context.lookup(jmsQueueName);
QueueConnectionFactory qcf = (QueueConnectionFactory) context.lookup(jmsQueueConnectionFactoryName);
QueueConnection jmsQueueConnection = qcf.createQueueConnection();
QueueSession jmsQueueSession = jmsQueueConnection.createQueueSession(false, Session.CLIENT_ACKNOWLEDGE);
jmsQueueConnection.start();
System.out.println(getName() + " Created session.");
jmsQueueSession.close();
jmsQueueConnection.stop();
jmsQueueConnection.close();
jmsQueue = null;
jmsQueueSession = null;
jmsQueueConnection = null;
System.out.println(getName() + " Session closed.");
context.close();
System.out.println(getName() + " Closed context.");
} catch (Exception e) {
e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates.
}
}
protected MQContext getContext()
throws NamingException {
Hashtable environment = new Hashtable();
environment.put(Context.PROVIDER_URL, jndiUrl);
// environment.put(Context.INITIAL_CONTEXT_FACTORY, jndiFactory);
MQContext context;
try {
context = new MQContext(environment);
}
catch (NamingException e) {
throw e;
}
return context;
}
}
} |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Aug 13, 2006 4:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you tried using the file context instead? I prefer working with the file context: no leakage everything works fine and is appserver ready (Used in ATG...).
And if you need you can close the context before closing the JVM...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rkrier1964 |
| Posted: Sun Aug 13, 2006 8:52 pm Post subject: |
|
|
Newbie
Joined: 13 Aug 2006
Posts: 4
|
Well for starters, I think the file context is merely a reference implementation that never made it out of beta. Unless I'm wrong, Sun has end-of-life'd it. At least that is what I can tell.
Also, the problem comes with the fact that there is a lot more administration. We have to keep our ".bindings" file in synch between our client apps and the MQ servers and our MQ administrator has to set up JMS as an extra step on the server side to create the binding in the first place. For internal reasons I won't go into, this is not the most favorable of solutions. I would prefer to have MQContext just work or if there is another JMS/MQ provider that works better, I would love to use it.
Thanks for the info though!!!
Bob |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 14, 2006 2:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Use an LDAP context.
The MQ context is a Support Pack. And it's category 2, so it's only supported by the authors, not IBM.
And you only need one copy of the .bindings file, and it can be created and built on any machine. And I strongly suspect that use of the file context with JMS admin would be supported by IBM, even if the context itself is not supported by Sun.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| vennela |
| Posted: Mon Aug 14, 2006 6:46 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| Quote: |
| Also, the problem comes with the fact that there is a lot more administration. |
I think it is the other way around. I think there is very little administration with FileSystem.
| Quote: |
| We have to keep our ".bindings" file in synch |
If you ever need to synch, you can synch (even with various contexts) using another support pac called MS0N or JMSAdmin GUI version |
|
| Back to top |
|
|
| rkrier1964 |
| Posted: Mon Aug 14, 2006 9:04 am Post subject: |
|
|
Newbie
Joined: 13 Aug 2006
Posts: 4
|
Thanks all for the posts. This is very good information. Regardless of how much or how little work is involved in keeping the .bindings file in synch, it is something we would prefer to avoid. Our app produces and consumes from dozens of queues and these queues can live in various and sundry machines.
I have worked around my problem by going to com.ibm.mq.jms.MQQueueConnectionFactory directly. This is essentially what FSContext does under the covers, but I don't need a .bindings file to do it.
Thanks again!
Bob |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Aug 14, 2006 12:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rkrier1964 wrote: |
Thanks all for the posts. This is very good information. Regardless of how much or how little work is involved in keeping the .bindings file in synch, it is something we would prefer to avoid. Our app produces and consumes from dozens of queues and these queues can live in various and sundry machines.
I have worked around my problem by going to com.ibm.mq.jms.MQQueueConnectionFactory directly. This is essentially what FSContext does under the covers, but I don't need a .bindings file to do it.
Thanks again!
Bob |
Sure but you have tapped into provider specific code and are no longer JMS provider neutral. That is your option and prerogative.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rkrier1964 |
| Posted: Mon Aug 14, 2006 1:31 pm Post subject: |
|
|
Newbie
Joined: 13 Aug 2006
Posts: 4
|
Again, thanks for the info. In this particular case, the application supports an implementation of a interface that creates the QueueConnectionFactory and a Queue.
Again my goal was to get rid of ".binding" files. I don't need them with Weblogic JMS or others that I know of.
Bob |
|
| Back to top |
|
|
|
|
