Is there a reported bug you are trying to address? I have not noticed any problems related to thread scheduling with the medium volume site I administer.
It is possible that this change could cause threads other than the socket accept thread to be starved. I would be -1 for making this change unless there is a significant reported bug that these changes would address. If it ain't broke, don't fix it. ;-) Regards, Glenn Remy Maucherat wrote:
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]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
