hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd take)
Date Fri, 18 Jan 2008 00:01:50 GMT

On Thu, 2008-01-17 at 21:02 +0000, sebb wrote:
> On 17/01/2008, Oleg Kalnichevski <olegk@apache.org> 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: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message