You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2008/01/17 11:57:13 UTC
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd
take)
On Wed, 2008-01-16 at 23:06 +0000, sebb wrote:
> Repeating "mvn test" shows the same Failure.
>
> Odd.
>
> The failures look rather similar - why should the first one be ignored?
> Perhaps a bug in Maven or Surefire.
>
Probably because they are not thrown in the test case itself but in the
#tearDown method. It is just a theory. It can well be the code simply
fails to propagate the exception correctly. I'll investigate.
Writing synchronous test cases for asynchronous I/O is not an easy
thing. Test cases are very ugly and flaky because most of the processing
logic needs to be run in worker threads. You never know whether the
event does not trigger because the I/O reactor still needs time or
something got screwy. So, lots of things can potentially go wrong.
> If I then run "mvn clean", then "mvn test" the stacktrace appears, but
> it is not treated as a failure, even if I run "mvn test" several times
> without an intervening clean.
>
> Very odd.
>
> Tried running "mvn test" in a fresh source tree:
> - first time, no stack trace at all
> - second and 3rd time, stack trace and failure recorded.
> - mvn clean, then mvn test: stack trace and failure recorded.
>
> The stacktrace seems to be repeatable now ... anything I can do to
> debug it further?
>
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.
Thanks for all you help
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd
take)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2008-01-17 at 23:32 +0000, sebb wrote:
> On 17/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
> >
> > On Wed, 2008-01-16 at 23:06 +0000, sebb wrote:
> >
> > > Repeating "mvn test" shows the same Failure.
> > >
> > > Odd.
> > >
> > > The failures look rather similar - why should the first one be ignored?
> > > Perhaps a bug in Maven or Surefire.
> > >
> >
> > Probably because they are not thrown in the test case itself but in the
> > #tearDown method. It is just a theory. It can well be the code simply
> > fails to propagate the exception correctly. I'll investigate.
> >
>
> Found the problem - it's just an ex.printStackTrace() call at
> TestDefaultListeningIOReactor.java:114
>
> Perhaps that should be removed or reworded - depends on what effect it
> has on the tests.
>
Not really needed. Removed.
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
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd take)
Posted by sebb <se...@gmail.com>.
On 17/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> On Wed, 2008-01-16 at 23:06 +0000, sebb wrote:
>
> > Repeating "mvn test" shows the same Failure.
> >
> > Odd.
> >
> > The failures look rather similar - why should the first one be ignored?
> > Perhaps a bug in Maven or Surefire.
> >
>
> Probably because they are not thrown in the test case itself but in the
> #tearDown method. It is just a theory. It can well be the code simply
> fails to propagate the exception correctly. I'll investigate.
>
Found the problem - it's just an ex.printStackTrace() call at
TestDefaultListeningIOReactor.java:114
Perhaps that should be removed or reworded - depends on what effect it
has on the tests.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd take)
Posted by sebb <se...@gmail.com>.
On 18/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> > Seems OK with Java 1.5.0_13 - tried 6 or so tests, and no failures.
> >
> > However, when I test with Java 1.6.0_03, I get the error:
> >
> > -------------------------------------------------------------------------------
> > Test set: org.apache.http.nio.TestAll
> > -------------------------------------------------------------------------------
> > Tests run: 97, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> > 11.703 sec <<< FAILURE!
> > testEndpointUpAndDown(org.apache.http.impl.nio.reactor.TestDefaultListeningIOReactor)
> > Time elapsed: 0.016 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)
> >
> > 4 out of 5 times.
> >
> > This was after doing a "mvn clean", so the code was compiled with Java 1.6
> >
>
> Weird. Cannot reproduce on my Linux (single-core) box. Anyways, I do not
> think this issue is a release blocker now, is it?
>
No, it's not a blocker for this release.
It might be a blocker for a non-Beta release, but hopefully it can be
resolved by then.
> 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
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd
take)
Posted by Oleg Kalnichevski <ol...@apache.org>.
> Seems OK with Java 1.5.0_13 - tried 6 or so tests, and no failures.
>
> However, when I test with Java 1.6.0_03, I get the error:
>
> -------------------------------------------------------------------------------
> Test set: org.apache.http.nio.TestAll
> -------------------------------------------------------------------------------
> Tests run: 97, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 11.703 sec <<< FAILURE!
> testEndpointUpAndDown(org.apache.http.impl.nio.reactor.TestDefaultListeningIOReactor)
> Time elapsed: 0.016 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)
>
> 4 out of 5 times.
>
> This was after doing a "mvn clean", so the code was compiled with Java 1.6
>
Weird. Cannot reproduce on my Linux (single-core) box. Anyways, I do not
think this issue is a release blocker now, is it?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd take)
Posted by sebb <se...@gmail.com>.
On 18/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> On Fri, 2008-01-18 at 02:28 +0000, sebb wrote:
> > On 18/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > On Fri, Jan 18, 2008 at 01:04:54AM +0000, sebb wrote:
> > > > On 18/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > > >
> > > > > On Thu, 2008-01-17 at 21:02 +0000, sebb wrote:
> > > > > > On 17/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > > > > >
>
> > 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.
> >
>
> Sebastian
>
> The only theory I can think of it that you still had a runaway Java
> process running still bound to the port 9999. This did happen to me and
> took me a while to figure out what was wrong.
>
> Anyways, I made changes to the end point management code. The problem
> appears to have been solved. Could you please get the latest snapshot
> off the SVN trunk and re-run the tests?
>
Seems OK with Java 1.5.0_13 - tried 6 or so tests, and no failures.
However, when I test with Java 1.6.0_03, I get the error:
-------------------------------------------------------------------------------
Test set: org.apache.http.nio.TestAll
-------------------------------------------------------------------------------
Tests run: 97, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
11.703 sec <<< FAILURE!
testEndpointUpAndDown(org.apache.http.impl.nio.reactor.TestDefaultListeningIOReactor)
Time elapsed: 0.016 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)
4 out of 5 times.
This was after doing a "mvn clean", so the code was compiled with Java 1.6
> Oleg
>
> > 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
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd
take)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2008-01-18 at 02:28 +0000, sebb wrote:
> On 18/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Fri, Jan 18, 2008 at 01:04:54AM +0000, sebb wrote:
> > > On 18/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > >
> > > > On Thu, 2008-01-17 at 21:02 +0000, sebb wrote:
> > > > > On 17/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > > > >
> 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.
>
Sebastian
The only theory I can think of it that you still had a runaway Java
process running still bound to the port 9999. This did happen to me and
took me a while to figure out what was wrong.
Anyways, I made changes to the end point management code. The problem
appears to have been solved. Could you please get the latest snapshot
off the SVN trunk and re-run the tests?
Oleg
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd take)
Posted by sebb <se...@gmail.com>.
On 18/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, Jan 18, 2008 at 01:04:54AM +0000, sebb wrote:
> > On 18/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
> > >
> > > On Thu, 2008-01-17 at 21:02 +0000, sebb wrote:
> > > > On 17/01/2008, Oleg Kalnichevski <ol...@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
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd take)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, Jan 18, 2008 at 01:04:54AM +0000, sebb wrote:
> On 18/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
> >
> > On Thu, 2008-01-17 at 21:02 +0000, sebb wrote:
> > > On 17/01/2008, Oleg Kalnichevski <ol...@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, 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
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd take)
Posted by sebb <se...@gmail.com>.
On 18/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> On Thu, 2008-01-17 at 21:02 +0000, sebb wrote:
> > On 17/01/2008, Oleg Kalnichevski <ol...@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
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd
take)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2008-01-17 at 21:02 +0000, sebb wrote:
> On 17/01/2008, Oleg Kalnichevski <ol...@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
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd take)
Posted by sebb <se...@gmail.com>.
On 17/01/2008, Oleg Kalnichevski <ol...@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)
This was for SVN:
URL: https://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 612952
Node Kind: directory
Schedule: normal
Last Changed Author: olegk
Last Changed Rev: 612862
Last Changed Date: 2008-01-17 16:46:03 +0000 (Thu, 17 Jan 2008)
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05)
Java HotSpot(TM) Client VM (build 1.5.0_13-b05, mixed mode)
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?
Also SSLIOSession$InternalByteChannel#close() appears to be an
infinite recursive call of itself.
> 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
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd
take)
Posted by Oleg Kalnichevski <ol...@apache.org>.
> >
> > 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?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd take)
Posted by sebb <se...@gmail.com>.
On 17/01/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> On Wed, 2008-01-16 at 23:06 +0000, sebb wrote:
>
> > Repeating "mvn test" shows the same Failure.
> >
> > Odd.
> >
> > The failures look rather similar - why should the first one be ignored?
> > Perhaps a bug in Maven or Surefire.
> >
>
> Probably because they are not thrown in the test case itself but in the
> #tearDown method. It is just a theory. It can well be the code simply
> fails to propagate the exception correctly. I'll investigate.
>
> Writing synchronous test cases for asynchronous I/O is not an easy
> thing. Test cases are very ugly and flaky because most of the processing
> logic needs to be run in worker threads. You never know whether the
> event does not trigger because the I/O reactor still needs time or
> something got screwy. So, lots of things can potentially go wrong.
>
>
> > If I then run "mvn clean", then "mvn test" the stacktrace appears, but
> > it is not treated as a failure, even if I run "mvn test" several times
> > without an intervening clean.
> >
> > Very odd.
> >
> > Tried running "mvn test" in a fresh source tree:
> > - first time, no stack trace at all
> > - second and 3rd time, stack trace and failure recorded.
> > - mvn clean, then mvn test: stack trace and failure recorded.
> >
> > The stacktrace seems to be repeatable now ... anything I can do to
> > debug it further?
> >
>
> 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.
> 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
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd
take)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2008-01-17 at 16:29 +0100, Stojce Dimski wrote:
> Hi Oleg,
>
> > Writing synchronous test cases for asynchronous I/O is not an easy
> > thing. Test cases are very ugly and flaky because most of the
>
> Maybe this thing can help:
>
> http://www.cs.umd.edu/projects/PL/multithreadedtc/overview.html
>
> Cheers,
> Stojce
>
>
Thanks Stojce, looks useful.
Oleg
>
> ___________________________________
> L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
>
> ---------------------------------------------------------------------
> 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
Re: [HttpCore] HttpCore 4.0-beta1 release packages preview (2nd take)
Posted by Stojce Dimski <sd...@yahoo.it>.
Hi Oleg,
> Writing synchronous test cases for asynchronous I/O is not an easy
> thing. Test cases are very ugly and flaky because most of the
Maybe this thing can help:
http://www.cs.umd.edu/projects/PL/multithreadedtc/overview.html
Cheers,
Stojce
___________________________________
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org