Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: domain of trustin@gmail.com designates
 64.233.184.205 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=dm4a4IaGjxxuYpxAaRrWIXzl0Ph7tE8Yw8+z5Tf0VDJa3ChKGujIU2DSIRITOxw2kNNIkfmBLdurswOrobRsdmdUx6FzFBMhlI4F7A7MPHKco257jmQb75ouu4v+F97cfzzs8Qrn7ZAQYgMa7bwl6dsNbn4Y+TmTiuD+T2zwM2o=
Message-ID: <768dcb2e041217004648aafb7@mail.gmail.com>
Date: Fri, 17 Dec 2004 17:46:11 +0900
From: Trustin Lee <trustin@gmail.com>
Reply-To: Trustin Lee <trustin@gmail.com>
To: Apache Directory Developers List <directory-dev@incubator.apache.org>
Subject: Re: [mina] ProtocolHandler interface
In-Reply-To: <768dcb2e04121700222569871d@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <768dcb2e04121700222569871d@mail.gmail.com>

Ah, I forgot to say some important point.

MINA does all operation asynchronously.  So the response message is
not actually written to socket even if you called Session.write()
method.  ProtocolHandler.messageSent(...) is invoked by MINA when it
is actually written.

I know SEDA also does work in the similar way although it doesn't fire
any messageSent events.  There is an important point in fact.  Some
protocols are
stateless and closes the connection after the first response is
written.  Others are stateful or keep-alive-style and doesn't close
the connection if user doesn't close it.

The latter case is very easy to implement because client decides when
to close the channel. But the former case is tough to implement if we
don't get notified the message is actually written to socket.  We
can't avoid to close the socket even before the message is flushed out
actually.

The easiest solution to resolve this issue would be to make session
close request queued and delayed until all messages are flushed out. 
But this won't work if a client behaves abnormally like not reading
socket buffer even if server's write buffer is full and outgoing
message queue is not being flushed.

The better solution would be providing some timeout settings like
readTimeout and writeTimeout.  MINA will throw ReadTimeoutException or
WriteTimeoutException which extends IOException.  Socket close command
will be executed because MINA closes the connection automatically if
IOException is caught.

Please consider this point and suggest me the ways to improvement
ProtocolHandlers in MINA. :)

Cheers,
Trustin