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? > 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]
