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: > > > > > > > > > > > > > I think I have found the problem spot using my wife's dual-core Mac. I > > > > > suspect I have never been seeing those problems because my primary > > > > > Linux > > > > > system is single-core. > > > > > > > > > > > > > Ah - my laptop is also dual-core. > > > > > > > > > Thanks for all you help > > > > > > > > No problem. > > > > > > Sebastian, Anthony, et al > > > > > > The problem appears to have been solved. At least I am no longer able to > > > reproduce it on my dual-core Mac. Could you please get the latest > > > snapshot off the SVN trunk and test whether you can still reproduce the > > > problem locally? > > > > > > > I'm still getting an error: > > > > ------------------------------------------------------------------------------- > > Test set: org.apache.http.nio.TestAll > > ------------------------------------------------------------------------------- > > Tests run: 97, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: > > 11.391 sec <<< FAILURE! > > testEndpointUpAndDown(org.apache.http.impl.nio.reactor.TestDefaultListeningIOReactor) > > Time elapsed: 0.094 sec <<< FAILURE! > > junit.framework.AssertionFailedError: expected:<1> but was:<0> > > at junit.framework.Assert.fail(Assert.java:47) > > at junit.framework.Assert.failNotEquals(Assert.java:282) > > at junit.framework.Assert.assertEquals(Assert.java:64) > > at junit.framework.Assert.assertEquals(Assert.java:201) > > at junit.framework.Assert.assertEquals(Assert.java:207) > > at > > org.apache.http.impl.nio.reactor.TestDefaultListeningIOReactor.testEndpointUpAndDown(TestDefaultListeningIOReactor.java:140) > > > > Sebastian > > I must confess I have run out of ideas. I cannot fully understand why > this is happening and am unable to reproduce the problem locally > (neither on Mac OS nor Linux). Seems Windows specific. Shall I just > disable the test case for now? >
No, I suggest it is left as is. I'll see if I can run it on a multi-CPU Unix OS. BTW, how does one check the number of CPUs on Unix? > > > 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]
