From dev-return-9000-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Sun Nov 06 12:05:36 2005 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 28434 invoked from network); 6 Nov 2005 12:05:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Nov 2005 12:05:35 -0000 Received: (qmail 53555 invoked by uid 500); 6 Nov 2005 12:05:34 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 53511 invoked by uid 500); 6 Nov 2005 12:05:34 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 53500 invoked by uid 99); 6 Nov 2005 12:05:34 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Nov 2005 04:05:33 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of trustin@gmail.com designates 64.233.184.207 as permitted sender) Received: from [64.233.184.207] (HELO wproxy.gmail.com) (64.233.184.207) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Nov 2005 04:05:27 -0800 Received: by wproxy.gmail.com with SMTP id 57so156621wri for ; Sun, 06 Nov 2005 04:05:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Dr+kng+urtQh2JoCr8eQJdLYe7kal64ikRwkp3fXI8Pa8EBEPWOfkzEp6aApW2v2xNnYZJJApb0n4xveKlhID77KejaqQ2CQpT7ZBpmaRWtqAS3vg/yourDGWTvFHyFwpWViYs0HqRtrurtVjNZ/nNnC/Ogebv0/cwQ08knvw/8= Received: by 10.54.141.20 with SMTP id o20mr3295710wrd; Sun, 06 Nov 2005 04:05:12 -0800 (PST) Received: by 10.54.71.11 with HTTP; Sun, 6 Nov 2005 04:05:12 -0800 (PST) Message-ID: <768dcb2e0511060405s3f2b9145k@mail.gmail.com> Date: Sun, 6 Nov 2005 21:05:12 +0900 From: Trustin Lee To: Apache Directory Developers List Subject: Re: [mina] 0.8 vs 0.9 In-Reply-To: <75CFC296F70A08409390004F30EF9B85069683C9@uk-ex001.groupinfra.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3888_29342906.1131278712278" References: <75CFC296F70A08409390004F30EF9B85069683C9@uk-ex001.groupinfra.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_3888_29342906.1131278712278 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Dave, Sorry for this late reply. I almost forgot to reply to your message. 2005/11/3, Irving, Dave : > > Im trying to performance test my NIO Http server at the moment, and > naturally I've written some clients which sit on Mina. > With persistent connection testing out of the way, its time to see how > fast we can go when connections are short-lived. > I've noticed in Mina 0.8 that there doesn't seem to be a non-blocking way > to make a connection to a server: something my client applications will > definately need to do. Have I missed something? > You're right. MINA 0.9 supports the non-blocking way. However, I got hold of the latest code from svn, and it seems this solves m= y > problem: SocketConnector#connect no longer blocks the caller. > Unfortunately, Im now faced with another problem: It seems we can no > longer provide a marker object when writing to an IoSession (instead we n= ow > get returned a WriteFuture). > I was using this to mark a response as the "last for a connection". E.g, > if I received a connection-close HTTP header, then when I get round to > writing the response for that request I send a token object which signals > the last response. When Im called back to be told that the data has been > written, I can close the connection. > I can see two ways of preserving this behaviour with the latest version, > but both appear to be slightly problematic: > 1) I use the ByteBuffer as the token. However, Im not sure if this is > strictly safe (multiple threads scheduling the writes, buffer pooling etc= ) > You can use the ByteBuffer as a key until it is returned back to the pool. It will be returned when your messageSent() (or messageReceived()) method returns. So we can say it is safe. If you want to prevent it from being returned, you can call setPooled(false) on it. 2) Block on the WriteFuture to wait for the op to complete. However, I dont > want to block the thread which provides the response (an application > thread), so Id need to add complexity (such as having another thread who'= s > only job is to block on the WriteFuture and close the connection when the > last write is complete). > You can simply choose the first one. :) HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ ------=_Part_3888_29342906.1131278712278 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Dave,

Sorry for this late reply.  I almost forgot to reply t= o your message.

2005/11/3, Irving, = Dave <dave.irving@logicacmg= .com >:
Im trying to performance test my NIO Http server at the=20 moment, and naturally I've written some clients which sit on=20 Mina.
With persistent connection testing out of the way, its=20 time to see how fast we can go when connections are=20 short-lived.
I've noticed in Mina 0.8 that there doesn't seem to be=20 a non-blocking way to make a connection to a server: something my client=20 applications will definately need to do. Have I missed=20 something?

You're right.  MIN= A 0.9 supports the non-blocking way.

However, I got hold of the latest code from svn, and it=20 seems this solves my problem: SocketConnector#connect no longer blocks the= =20 caller.
Unfortunately, Im now faced with another problem: It=20 seems we can no longer provide a marker object when writing to an IoSession= =20 (instead we now get returned a WriteFuture).
 
I was using this to mark a response as the "last for a=20 connection". E.g, if I received a connection-close HTTP header, then w= hen I get=20 round to writing the response for that request I send a token object which= =20 signals the last response. When Im called back to be told that the data has= been=20 written, I can close the connection.
I can see two ways of preserving this behaviour with=20 the latest version, but both appear to be slightly=20 problematic:
 
1) I use the ByteBuffer as the token. However, Im not=20 sure if this is strictly safe (multiple threads scheduling the writes, buff= er=20 pooling etc)

You can use the ByteB= uffer as a key until it is returned back to the pool.  It will be retu= rned when your messageSent() (or messageReceived()) method returns.  S= o we can say it is safe.  If you want to prevent it from being returne= d, you can call setPooled(false) on it.

2) Block on the WriteFuture to wait for the op to=20 complete. However, I dont want to block the thread which provides the respo= nse=20 (an application thread), so Id need to add complexity (such as having anoth= er=20 thread who's only job is to block on the WriteFuture and close the connecti= on=20 when the last write is complete).

= You can simply choose the first one. :)

HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/ ------=_Part_3888_29342906.1131278712278--