|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
JBOSS EAP6.3 wmq.jmsra.rar rcvthread in thread dump |
« View previous topic :: View next topic » |
Author |
Message
|
amitjain1984 |
Posted: Mon Jan 09, 2017 12:45 am Post subject: JBOSS EAP6.3 wmq.jmsra.rar rcvthread in thread dump |
|
|
Newbie
Joined: 20 Dec 2016 Posts: 4
|
Hi Team,
I am looking at thread dump of jboss server and seeing below threads which are created when message is put on the queue by some other programs but below thread does not get removed even after MDB work is complete.
rcvthread count keeps increasing and at one point server does not have thread left to serve user request.
Please suggest what is wrong with my code as I am not opening any queue session explicitly and I using MDB only to get message.
"RcvThread: com.ibm.mq.jmqi.remote.impl.RemoteTCPConnection@158323308[qmid=fclSIR11516MQ_2016-09-22_19.46.59,fap=12,channel=FCLMQCHN,ccsid=1208,sharecnv=10,hbint=300,peer=/10.20.106.171(4804),localport=38571,ssl=no,hConns=0,LastDataSend=1483948514846 (13ms ago),LastDataRecv=1483948514721 (138ms ago),]" #314 daemon prio=5 os_prio=0 tid=0x00007fca5d101800 nid=0x5f1c runnable [0x00007fca6488b000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at com.ibm.mq.jmqi.remote.impl.RemoteTCPConnection.receive(RemoteTCPConnection.java:1545)
at com.ibm.mq.jmqi.remote.impl.RemoteRcvThread.receiveBuffer(RemoteRcvThread.java:794)
at com.ibm.mq.jmqi.remote.impl.RemoteRcvThread.receiveOneTSH(RemoteRcvThread.java:757)
at com.ibm.mq.jmqi.remote.impl.RemoteRcvThread.run(RemoteRcvThread.java:150)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:214)
at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:105)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:229)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:303)
at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1219)
Locked ownable synchronizers:
- None |
|
Back to top |
|
 |
tomleend |
Posted: Thu Jan 19, 2017 12:16 pm Post subject: |
|
|
Acolyte
Joined: 24 Jan 2014 Posts: 51
|
Hi amitjain1984,
The thread you are referring to is called a "Remote Receive Thread". These are threads that are created internally by the MQ classes for JMS/Java for the sole purpose of reading data from a TCP/IP socket and handing it off to other threads to process.
For example, after an application attempts to get a message (perhaps by calling the JMS method MessageConsumer.receiveNoWait()), then the response from the queue manager (the message returned or 2033 RC) will be read off the socket by this Remote Receive Thread and then handed off to the waiting application thread.
There is one Remote Receive Thread per TCP/IP socket. So, if you have many of these threads, you have many open and active TCP/IP sockets between your application and the queue manager.
This can be quite normal in systems with lots of active concurrent connections.
You can see quite a lot of detail regarding the connection from the Remote Receive Thread dump. For example, your queue manager is called:
fclSIR11516MQ
it is running on the host with IP address:
10.20.106.171
listening on port:
4804
and the application is connecting over the server connection channel:
FCLMQCHN
This channel has the "Sharing Conversations" attribute set to the default value of 10, which you can see in the attribute here:
sharecnv=10
This means up to 10 logical connections to the queue manager (I'll call them conversations obut they are also referred to as hConns) can be multiplexed over and share the single TCP/IP socket serviced by this Remote Receive Thread.
Now, the MQ classes for JMS/Java will try and allocate a new conversation request (e.g., instantiation of an MQQueueManager object in the classes for Java or the creation of a JMS Connection / JMS Session in the classes for JMS) over an existing connection / network socket. If this fails, or all existing connections have the maximum allowable conversations on them, then a new socket is created.
The point is this:
If you have lots of Remote Receive Threads and the number keeps growing then, assuming all or most have ten conversations allocated on them, your application is probably creating lots of connections (JMS Connection / Session objects) and not closing them. Your application is probably leaking connections by not closing off objects properly when it has finished with them.
I hope this helps! |
|
Back to top |
|
 |
amitjain1984 |
Posted: Thu Jan 19, 2017 9:59 pm Post subject: |
|
|
Newbie
Joined: 20 Dec 2016 Posts: 4
|
Hi Tomleend,
Thanks for detailed information and direction for investigating the issue. Is there any way to enable MQ trace which will show which java class is requesting connection/session and not closing it.
Regards, |
|
Back to top |
|
 |
tomleend |
Posted: Fri Jan 20, 2017 2:11 am Post subject: |
|
|
Acolyte
Joined: 24 Jan 2014 Posts: 51
|
Although trace is normally just used by IBM Support engineers, I believe you can configure the MQ classes for JMS to perform an API level trace that is more friendly to an application developer.
The instructions are detailed in this Tehnote:
http://www-01.ibm.com/support/docview.wss?uid=swg21663158
The instructions involve creating a properties file to control the tracing and then starting the application JVM with a Java system property to point the MQ classes for JMS at this file.
With this, you should be able to see how many JMS Connection ad JMS Session objects (each requiring one conversation to the queue manager) are created by the application and how many are closed. |
|
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
|
|
|
|