On Fri, 2008-01-18 at 02:28 +0000, sebb wrote: > On 18/01/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > On Fri, Jan 18, 2008 at 01:04:54AM +0000, sebb wrote: > > > On 18/01/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > > > > > > > On Thu, 2008-01-17 at 21:02 +0000, sebb wrote: > > > > > On 17/01/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > > > > >
> BTW, further testing on Windows seems to show that the exception stack > traces that were commented out are often associated with the failure, > so it might be sensible to add a one line trace back in. > > Also, the assertion relates to the number of items in the endPoints list. > I put in some debug to show when getEndPoints() finds a selector that > is not open or a key that is not valid. It seems that invalid keys are > always associated with the error. Selector not open is associated with > the error if it occurs more than once; this seems to happen when one > of the ignored Exceptions occurs. > Sebastian The only theory I can think of it that you still had a runaway Java process running still bound to the port 9999. This did happen to me and took me a while to figure out what was wrong. Anyways, I made changes to the end point management code. The problem appears to have been solved. Could you please get the latest snapshot off the SVN trunk and re-run the tests? Oleg > Might be worth testing with Java 1.6 as well - errors seem to happen a > bit more frequently for me with that. > > > > BTW, how does one check the number of CPUs on Unix? > > > > > > > I am pretty sure it is kernel specific > > > > Oleg > > > > > > > > > > > > > > By the way, Findbugs says that the field: > > > > > > > > > > address in ListenerEndpointImpl (nio) > > > > > > > > > > is partially synchronised. > > > > > This seems to be due the constructor not synching the field. > > > > > Perhaps make it volatile and remove the existing synch blocks? > > > > > > > > > > > > > I declared the variable volatile. This should make Findbugs happy. The > > > > synch blocks are still needed because they synchronize on this > > > > (ListenerEndpointImpl instance), not address. This is needed to notify > > > > threads blocked awaiting the completion of ListenerEndpoint requests. > > > > > > > > > Also SSLIOSession$InternalByteChannel#close() appears to be an > > > > > infinite recursive call of itself. > > > > > > > > > > > > > Good catch. Fixed. > > > > > > > > Thank you once again. > > > > > > > > Oleg > > > > > > > > > > > > > > Oleg > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
