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 02:28:42 GMT
On 18/01/2008, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Fri, Jan 18, 2008 at 01:04:54AM +0000, sebb wrote:
> > 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.
> >
>
> Hi Sebastian
>
> Do not bother. After having added more sync blocks I am now getting
> occasional lockups. I guess I have take my time and carefully revise all
> endpoint management code.
>

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.

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