Hi,
I was wondering about how expensive the Thread.setPriority method is,
and to which extent it does what it advetises.
The point would be to assign the minimum priority to background
reloading threads, as well as set the priority of the thread accepting
on the server socket to the maximum while is it accepting, and then
switch back to normal priority once the accept is done.
That would prevent the only thread accepting on the server socket from
being starved by the OS scheduler.
Here's a patch for the PoolTcpEndpoint:
diff -r1.8 PoolTcpEndpoint.java
496a497
> Thread.currentThread().setPriority(Thread.MAX_PRIORITY);
500c501,503
< }
---
> } finally {
> Thread.currentThread().setPriority(Thread.NORM_PRIORITY);
> }
I have no idea if this produces useful results. This adds no additional
overhead on Windows according to OptimizeIt (which might hint that it
doesn't do anything on that platform). Maybe it would be a good ideato
test this on different platforms (and hammer the server to see how it
compares to an unpatched server).
According to Doug Lea's book, this may heuristically do something
intelligent depending on the VM implementation. (great :) )
Comments ?
Remy
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
- Re: Thread priority Remy Maucherat
- Re: Thread priority Michael
- Re: Thread priority Michael Smith
- mod_jk and load balancer - bug? Filip Hanik
- RE: mod_jk and load balancer - bug? Filip Hanik
- Re: mod_jk and load balancer - bug? Punky Tse
- RE: mod_jk and load balancer - bug? Filip Hanik
- Re: Thread priority Michael
- Re: Thread priority Glenn Nielsen
- Re: Thread priority Remy Maucherat
- Re: Thread priority Peter Lin