Hi,
I've found the same problem as the one listed below - every time a
malformed request is given to Synapse, an infinite loop will be
triggered making the Synapse server sluggish, and consuming the entire
log file (in case the output is redirected). I've noticed that the
problem might get fixed. Could you please let me know if the problem was
fixes, and if yes in which release.
Thanks,
Daniel
Hi All
I guess this boils down to how we deal with broken,
partial, and even
possibly malicious requests in the NIO transport.. I
will fix the issue
pointed to by Andreas and Murali ASAP as I consider this
critical.
Murali - I believe you should plan on updating to
Synapse 1.3 in the
near future. There are a few issues we have fixed over
the past year
that should be very important for any production
deployment. As I
believe your environment / configuration is
straightforward, so the
migration should be quite trivial too - Could you also
raise an issue on
the JIRA?
This runtime exception is caught in
BaseIOReactor#writable and delegated to the
registered exception handler (in our case an anonymous
inner class of
HttpCoreNIOListener with the following implementation:
ioReactor.setExceptionHandler(new
IOReactorExceptionHandler() {
public boolean handle(IOException
ioException) {
log.warn("System may be unstable:
IOReactor encountered a
checked exception : "
+ ioException.getMessage(),
ioException);
return true;
}
public boolean handle(RuntimeException
runtimeException) {
log.warn("System may be unstable:
IOReactor encountered a
runtime exception : "
+
runtimeException.getMessage(), runtimeException);
return true;
}
});
I wondering a bit about the return value. Taken from the
JavaDoc of the
interface IOReactorExceptionHandler#handle
True if it is safe to ignore the exception and continue
execution of the I/O
reactor; if the I/O reactor must throw {...@link
RuntimeException} and terminate
Hmm, is it really safe to proceed here? We do not test
any detail of the
RuntimeException. To me this looks wrong.
Yes, we return true since the later versions of HttpCore
dump some
information and try to continue in the face of RT
exceptions. What I
feel is that we need to enhance the NIO transport to be
stable in the
face of broken, partial and malicious requests so that
RT exceptions
will not be thrown in such cases, and we will drop the
connection with a
WARN
cheers
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail:
[email protected]
