On Wed, 2010-10-06 at 23:25 +0200, Emmanuel Lécharny wrote: > On 10/6/10 10:51 PM, Oleg Kalnichevski wrote: > > On Wed, 2010-10-06 at 22:21 +0200, Emmanuel Lécharny wrote: > >> On 10/6/10 9:18 PM, Oleg Kalnichevski wrote: > >>>>> Take it as a food for thought. Nothing more. > >>>> I'm going to give HttpComponents a shoot, to see how those two guys can > >>>> fit. > >>>> > >>>> One solution would be to define a common base, with all the Filter > >>>> intricacy separated from the NIO part. That might fit your need then. > >>>> > >>> Yeeeep. This is precisely what I was trying to hint at. > >> Took me a while to figure this out :) > >>> Here is my private fork of HttpCore NIO code with all HTTP specific > >>> stuff ripped out. It might be easier for you to get a feel of the > >>> framework by looking at the protocol independent code. > >> I have downloaded the original code (httpcore-nio). > >> > >> A few remarks : > >> - mvn eclipse:eclipse fails, due to some strange errors with the > >> 'filtering' tags. I removed them, and get the projects available in eclipse > >> - in the select() loop, you will experiment from time to time some 100% > >> CPU usage. This is a known bug in Sun code base. What happens is that > >> select() return something> 0 but no selectionKey are available, because > >> some client simply connect and disconnect immediately, triggering the > >> select() but weren(t present anymore when the selector tried to add a > >> selectionKey in its internal table (a kind of race condition). As a > >> consequence, there is nothing to do, so you immediately return to the > >> select() which returns immeditely with a value> 0 and so on => 100% > >> CPU. Seehttps://issues.apache.org/jira/browse/DIRMINA-678 > >> > >> A fix for the second point consist on detecting that we exit from the > >> select() fast and that we don't have any SelectionKey to process. You > >> have to get the time before entering the select(), the time when you get > >> out, and compare them. If it's almost 0, and if the returned value is> > >> 0, and if there is no selectionKey available, then you have been hit by > >> the epoll bug. Now, you have to create a new selector, register all the > >> existing selectionKey on the new selector, and substitute the old > >> selector with the new one. Yukkkk. But it works. > >> > > I am aware of the issue. > > > > We have gone through the same painful experience a while ago, but > > ultimately decided against committing the patch with a work-around to > > the main codeline, as the epoll spin problem had been fixed in the > > latest Sun's JRE releases. One of the upstream users that makes > > extensive use of HttpCore NIO in their product conducted a series > > thorough load tests with and without the patch and confirmed the problem > > could be resolved by upgrading to JRE 1.6.0.21. > Seems to have been fixed in > http://www.oracle.com/technetwork/java/javase/6u18-142093.html, right. > > Has it been fixed in java 5 ? >
I am not sure whether or not Java 1.5 was affected in the first place. I do not think it uses epoll based selector per default to start with. In our case the problem was reported when running Java 1.6. Oleg
