ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexWebSphere Application ServerJBOSS EAP6.3 wmq.jmsra.rar rcvthread in thread dump

Post new topicReply to topic
JBOSS EAP6.3 wmq.jmsra.rar rcvthread in thread dump View previous topic :: View next topic
Author Message
amitjain1984
PostPosted: Mon Jan 09, 2017 12:45 am Post subject: JBOSS EAP6.3 wmq.jmsra.rar rcvthread in thread dump Reply with quote

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
View user's profile Send private message
tomleend
PostPosted: Thu Jan 19, 2017 12:16 pm Post subject: Reply with quote

Acolyte

Joined: 24 Jan 2014
Posts: 50

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
View user's profile Send private message
amitjain1984
PostPosted: Thu Jan 19, 2017 9:59 pm Post subject: Reply with quote

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
View user's profile Send private message
tomleend
PostPosted: Fri Jan 20, 2017 2:11 am Post subject: Reply with quote

Acolyte

Joined: 24 Jan 2014
Posts: 50

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
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexWebSphere Application ServerJBOSS EAP6.3 wmq.jmsra.rar rcvthread in thread dump
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.