Oleg, thanks for your clarifications!
> If the reactor shutdown was requested in an orderly fashion there is a
> pretty good chance it will shut down cleanly and there will be nothing
> to look at the audit log. The audit log usually comes handy when the
> reactor shuts down due to an unexpected fatal error.
Hmmm, how can one know the difference?
> HttpCore does not do logging by itself.
Ah, I think this perfectly explains it.
> I do not know Synapse that well to answer this question.
Me neither, but from what I've seen, in HttpCoreNIOSender Synapse logs the
thrown IOReactorException including the cause information as early as it has a
chance to do so:
Thread t = new Thread(new Runnable() {
public void run() {
try {
ioReactor.execute(ioEventDispatch);
} catch (InterruptedIOException ex) {
log.fatal("Reactor Interrupted");
} catch (IOException e) {
log.fatal("Encountered an I/O error: " + e.getMessage(), e);
}
}
}, "HttpCoreNIOSender");
So before this pops up, AbstractMultiworkerIOReactor performs the IOReactor
shutdown in it's finally block, which obviously may take a while.
This should explain the behaviour I observed.
> > Was in this case the java.nio.channels.ClosedChannelException the cause
> of the IOReactor shutdown?
> Yes, it was.
Thanks for confirming this.
> > Was it correct to terminate the Reactor?
> No, it was not. ClosedChannelException should not be considered fatal.
This was also my understanding.
> It is a shame the exception is unchecked, though.
Agreed.
> > If some code within the core nio library decides to throw an
> IOReactorException could it make sense to log the cause immediately or are
> there cases where the code at higher levels may still consider it
> otherwise.
>
> IOReactorException is considered fatal and should be propagated to the
> I/O reactor thread unless discarded by the IOReactorExceptionHandler
Ok, I now much better understand the expected flow. I was simply not aware,
that http core nio is not logging at all and delegates this to the client using
the library. This has some consequences to the order in which one can expect
error messages. Good to know.
> > Anyway, if I'm not wrong and all of the above makes at least partially
> sense, than it looks to me that the fix in
> http://issues.apache.org/jira/browse/HTTPCORE-169
> > which went in beta-3 should have prevented the IOReactor restart.
> >
>
> Correct. This is basically the same bug.
Thanks, Oleg you helped me a lot with your explanations. This is also just
another proof that it is a good idea for us to update to 4.0.1.
Thanks,
Eric
