Bug 1463123

Summary: [GSS](6.4.z) EJB subsystem thread-pool statistics largest-thread-count is counting threads instead of show the peak of parallel use
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: wfink
Component: EJBAssignee: Petr Jurak <pjurak>
Status: CLOSED NOTABUG QA Contact: Jiří Bílek <jbilek>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.4.14CC: bmaxwell, david.lloyd, jbaesner, pjurak
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-11-01 07:50:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description wfink 2017-06-20 08:00:45 UTC 
Description of problem:

The description of "largest-thread-count" is
=> "The largest number of threads that have ever simultaneously been in the pool."

But the behaviour at runtime shows that it is handled similar to task-count.
If only one thread is used it will increased for every invocation until max-threads.
As result the largest-thread-count is == max-threads after a short time.

The helpful metrict to check whether the threads are exhaused is missing!


How reproducible:
Use a simple EJB scheduled timer and see that the largest-thread-count is increased for every invocation.

Expected results:
Show the peak number of used threads in parallel
Comment 1 Petr Jurak 2017-11-01 07:50:02 UTC 
Not a bug. It shows exactly the largest number of threads in the pool. The reason it ends up with the value equal to max pool size is that core threads count is equal to max pool size for this executor. And core threads will not expire.