james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: AbstractJamesHandler error handling
Date Wed, 04 Jul 2007 20:43:04 GMT
robert burrell donkin ha scritto:
>> >> 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).
> IMAP is an unusual protocol. the server is required to hold the
> connection open for at least 30 minutes after the last client
> communication. IMHO the protocol is suitable only for reliable
> connections and clients don't expect disconnections.

I don't use IMAP too much, but I used it sometime in past on my GSM
connection and galleries made the connection very instable: no big
problems with the IMAP client (Outlook 2000, IIRC). I've been bound to
M$ for many years and now I fortunately choose my MUA and is
Thunderbird, but I only use POP3.

> the protocol states that the server MUST write an untagged BYE before
> closing the connection. i'm an unfan of IMAP but i'd prefer to
> implement the protocol as written (even when wrong).

So if I power off the server then the software is not compliant ?? ;-)
Of course this is interpretation: the MUST is about the software
operations in standard conditions. I bet no server will send the BYE if
I hot-remove the RAM :-P
I just keep in mind that the Error class has a javadoc saying it should
not the cough, and in my real-life experience I had problems with
software trying to catch too much errors: in old JVM catching too much
OOM would result in other more critical virtual machine errors.

>> [...]
>> 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
> IMAP is unusual. both client and server are encouraged to talk
> concurrently. client must listen whilst they are transferring a
> message. at the risk of repeating myself, IMHO this isn't good but
> it's what the protocol specifies.
>> or during an SSL handshake or anything similar.
> IMAP has to be tunneled so AIUI the handshake must have completed

Well, I don't know the IMAP protocol. Take it as an hint: take a
conversation a place a BYE between the text and see if somewhere it
could alter what the Client can think about the server message.

>> 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.
> for IMAP, BYE is appropriate in all states. the rule is simple: write
> untagged BYE before closing the connection. the only grey area would
> be literal data (eg message transfer from the server to the client).

But IMAP is line based, isn't it? What about a BYE in the middle of
another "line" ? Can you ensure this does not happen without wasting

>> 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.
> probably the best approach would be to add extra exception (and maybe
> error) handling code within the IMAP handling code where it's aware of
> what's happening.
> i'd like to add a system.out log to AbstractJamesHandler followed by a
> rethrow in the event of an error but i'm willing to reconsider if
> people think that this is generally a bad idea.
> - robert

My rule of thumb is:

You are the most active developer right now, so what you prefer has more
value than what I prefer (prefer = think is better). I just tell my
preference, if other developers tell they agree with me then you should
stop, otherwise just take or discard any hint at your preference.

In fact, I like to feel free to spread my ideas without pushing my
rules. As Bernd wrote a +1 to your message if I were you I'd simply
proceed with no need to convince me :-)


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message