robert burrell donkin ha scritto: > On 7/4/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >> robert burrell donkin ha scritto: >> > handleConnection catches RuntimeException but not all throwable >> > exceptions. whenever an error is thrown this results in a silent >> > failure. what's the reasoning behind this? >> > >> > - robert >> >> It also catches all of the checked exceptions declared by the called >> code, right? (SocketException, InterruptedIOException, IOException). >> >> What kind of "Error" do you think should be catched (and could be >> succesfully handled) here? > > successful handling is a different question. we've argued before about > specification compliance verses java best practice error handling.
Don't worry, I was just looking for this explanation ;-) > i prefer servers to comply with the specification whenever possible. > so, in the case of IMAP IMHO JAMES should try to send an untagged BYE > with a message even when faced with an error. Maybe we should use a custom method for Errors because, IMO, they have a completely different meaning. This method should be documented to avoid any allocation and limit any resource usage to the minimum. >> E.g: I don't think that catching an OOM in the connection handling is a >> good idea. > > in the event of an OOM exception being thrown, i would expect an > application to log this fact so that an administrator can do something > about it. silently dropping connections (which is what happens ATM) is > IMHO not the right behaviour. I don't see too many problems with dropping the connection: I'm not confident that in an Error condition you should keep managing a conversation (I see there many more possible problems than closing the connection unexpectedly, as clients are written to manage unexpected connections too, as network can fail by definition). The main problem, imho could be the logging, but this is also a delicate issue. About the logging the cornerstone service support ConnectionMonitors (and also provide a simple Avalon Logger implementation for this), but it only take care of Exceptions and not Errors: cornerstone authors probably thought something similar to me. > IMHO JAMES should comply with the specification and try to send an > untagged BYE with an error message before closing the connection. yes, > this may fail but IMHO at least an attempt should be made. > > - robert IMHO OOM should not be tried to recover this way, but I can live with the catch/log/bye-try. E.g: sometimes you will end up sending a BYE in the wrong place of the conversation, and this is not good. YOu don't want to send BYE during a message transfer or during an SSL handshake or anything similar. So you should track the state to decide whether the BYE is appropriate or not. Maybe some extra work will increase the probability to run also other connections out of memory at the same time. Furthermore you should investigate all the code above the "handler" to see what will happen in case of Error: maybe you'll end up sending a BYE that will never-ever be managed. An Error could also be thrown by a bad bug in the JVM and a wrong access to memory, and you could end up sending wrong data to the client, and so on. If this was a vote I'd write -0, so if no one else share my concern feel free to proceed with your changes. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
