hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd take)
Date Fri, 18 Jan 2008 01:04:54 GMT
On 18/01/2008, Oleg Kalnichevski <olegk@apache.org> wrote:
>
> 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?
>

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: 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
>
>

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


Mime
View raw message