It's all about the answers!

Ask a question

Identifying hanging threads

Ryan Boyce (3112) | asked Feb 03 '17, 7:16 p.m.

 Forum members,

I am getting hanging threads in my RTC application, which I can identify in the system.out log, and also the Active Services page in CCM's Application Adminstration, but I don't know where they are coming from. The user who gets the attribution is our common jts account.

Some commonalities are the following:
It is always our common account that sets it off
The scenario in the active services window is almost always Scenario:, though sometimes it is
The system.out log always notifies me of the hanging thread after 11 or so minutes, and the thread usually is closed by about 65 minutes
There is usually a user id that comes with the system.out entry, though it is apparently  useless, as the user in question knows nothing about the source of the hanging thread

I've been tracking this problem for several days. It seems random, there are no patterns to the events, and some days are really busy, while others are not. I've tried to analyze the stack traces that accompany the events, but I can't find anything conclusive. There are about 9 or 10 common .java files at the top of these traces, but they look to be just standard eclipse .java files, so I haven't learned anything from them.

Does anyone know if finding the cause of a hanging thread is even possible? Am I trying to tackle a problem too large? Any hints?

I appreciate your help.

One answer

permanent link
Donald Nong (14.5k414) | answered Feb 05 '17, 8:21 p.m.

If the threads eventually finish, they are not "hanging". I would call them "long-running" threads instead, but will use the term "hanging threads" thereafter to keep it simple.

Generally speaking, if no users are complaining about slow operations, or no significant performance issues are observed, you don't need to worry about those hanging threads. Just let them run their courses. The really worrying hanging threads are those never finish and keep popping up - they will eventually exhaust the thread pool and the server becomes unresponsive.

If however, you want to get to the bottom of it for whatever reason, what you have been doing is the right approach. The user ID associated with the thread is definitely the one initiated the operation (it may even be a background task in the user session), but the actual user may not recognize the operation. For example, if a user adds a member to the project area, the said operation will be triggered, but the user may not realize it. The stack trace should give you good indication of what the user is doing, but if you can't decipher, contact IBM Support.

Ryan Boyce commented Mar 16 '17, 1:04 p.m.

Thanks for your response. I think you were right; nothing really came of my investigation, and the problem didn't seem to be connected in any plausible way. 

Your answer

Register or to post your answer.