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>
From: Peter Donald <peter@realityforge.org>
To: "Apache Directory Developers List" <directory-dev@incubator.apache.org>
Subject: Re: Serverside NIO:  Not ready for Prime Time
Date: Wed, 26 Nov 2003 20:15:11 +1100
User-Agent: KMail/1.5
References: 
 <20031126051741.LIMY1942.imf23aec.mail.bellsouth.net@mail.bellsouth.net>
In-Reply-To: 
 <20031126051741.LIMY1942.imf23aec.mail.bellsouth.net@mail.bellsouth.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200311262015.11284.peter@realityforge.org>

On Wed, 26 Nov 2003 04:17 pm, Alex Karasulu wrote:
> > > Ye gads.  Why can't you multithread the reads?  What possible reason
> > > could one come up with that the reads have to happen on the same thread
> > > as the select?
> >
> > Because it doesn't work ;)
> >
> > I could offer a reasonable explanation of why that is so but ultimately
> > it
>
> Could you give the longer explanation to me.

The long answer is still basically that it does not work because it was never 
written well enough (I suspect thats the reason for the NPE trace before). If 
you have a look at frameworks that build on nb io - such as SEDA - they 
generally follow this pattern.

>  I just thought that if one
> thread in a stage detects the input PDU (Protocol Data Unit) another worker
> thread in a stage down stream could handle reading the PDU into a buffer
> for decoding.

To get it to work how you want it to work you have to cancel() the key during 
other threads processing and then re-register the key. It looks like the code 
did this at one stage but doesn't seem to anymore ...

> > As long as you dont do memory allocation in selector thread then all that
> > thread does is select() and memcpy() which can scale relatively well even
> > if you batch it and randomize events when you pass them o0nto next stage.
>
> Sounds like you think we're doing more than we are in the selector thread. 

The opposite. I think you should be doing more in the selector thread. I think 
you should read all the available data into a buffer in the selector thread. 
This should not cause any significant performance impact as the data is 
already available in kernel buffers (usually with a maximum size of 8kb). So 
it ends up being a single memcpy if you use direct buffers or a double memcpy 
if you use non direct buffers. The second stage simply reads the buffer to 
decode packets.

> However it
> does sound like you read a very interesting artical on the disparity across
> operating systems with resspect to nio, so give us a link ;-).

Nah - just been banging head against it for about a month or so and agains 
regular sockets before that.

-- 
Cheers,

Peter Donald
It's hard to read through a book on the principles of magic without
glancing at the cover periodically to make sure it isn't a book on software
design.

-- Bruce Tognazzini