[Bug 64155] Tomcat 7 Performance: acceptor thread bottleneck at getPoolSize() located at TaskQueue offer function

2020-04-27 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64155

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEEDINFO|RESOLVED

--- Comment #7 from Mark Thomas  ---
Two months have passed with no further information being provided. Absent a
text case that demonstrates the issue, I am resolving this as WORKSFORME. If
the issue persists, feel free to re-open this provided the request test case is
supplied.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 64155] Tomcat 7 Performance: acceptor thread bottleneck at getPoolSize() located at TaskQueue offer function

2020-02-25 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64155

Mark Thomas  changed:

   What|Removed |Added

 Status|REOPENED|NEEDINFO

--- Comment #6 from Mark Thomas  ---
I've built various test cases, some load testing Tomcat, some testing
ThreadPoolExecutor directly and I am unable to reproduce any results that show
contention on getPoolSize().

Please provide the simplest possible test case (i.e. one that tests
ThreadPoolExecutor directly) that demonstrates decreasing performance with
increasing concurrency.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 64155] Tomcat 7 Performance: acceptor thread bottleneck at getPoolSize() located at TaskQueue offer function

2020-02-21 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64155

--- Comment #5 from Torres Yang  ---
For our test setup, our gateway have 2000 tomcat threads waiting in the pool.
At the same time, we simulate more than 100 virtual users try to hit the
service on gateway.

You can image that under heavy load, we are expect to see slowness because of
this getPoolSize() lock.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 64155] Tomcat 7 Performance: acceptor thread bottleneck at getPoolSize() located at TaskQueue offer function

2020-02-21 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64155

Mark Thomas  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #4 from Mark Thomas  ---
Ah. I see appears to have been added at some point in Java 7.

Under what test conditions does this bottleneck appear?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 64155] Tomcat 7 Performance: acceptor thread bottleneck at getPoolSize() located at TaskQueue offer function

2020-02-21 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64155

--- Comment #3 from Torres Yang  ---
Hi Mark,


Thanks for your prompt reply, o.a.t.u.threads.ThreadPoolExecutor indeed extends
the j.u.c.ThreadPoolExecutor, and it inherits the getPoolSize() from
j.u.c.ThreadPoolExecutor as well.

However, the j.u.c.ThreadPoolExecutor's getPoolSize() implementation has
ReentrantLock in-placed.


Here is the code from Java 8:

/**
 * Returns the current number of threads in the pool.
 *
 * @return the number of threads
 */
public int getPoolSize() {
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
// Remove rare and surprising possibility of
// isTerminated() && getPoolSize() > 0
return runStateAtLeast(ctl.get(), TIDYING) ? 0
: workers.size();
} finally {
mainLock.unlock();
}
}


It's very obvious that whenever go into this function, it must first obtain the
lock before anything.


Hope this explain your question or concern.



Bests,


Torres

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 64155] Tomcat 7 Performance: acceptor thread bottleneck at getPoolSize() located at TaskQueue offer function

2020-02-21 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64155

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 OS||All
 Resolution|--- |INVALID

--- Comment #2 from Mark Thomas  ---
parent is an instance of o.a.t.u.threads.ThreadPoolExecutor

It inherits getPoolSize() from j.u.c.ThreadPoolExecutor

That method returns an int with no synchronization.

There is no use of AbstractQueuedSynchronizer in that call path.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 64155] Tomcat 7 Performance: acceptor thread bottleneck at getPoolSize() located at TaskQueue offer function

2020-02-21 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64155

--- Comment #1 from Mark Thomas  ---
*** Bug 64156 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org