directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Re: Serverside NIO: Not ready for Prime Time
Date Wed, 26 Nov 2003 23:49:36 GMT
Peter, Wes,

Looks like Peter had a good point.  I was thinking about Peters
comment on reading the data in the same thread which besides 
solving these problems might save a context switch.  I would prefer 
reading in a separate thread because of the separation but I don't 
know just how much it buys us - and it does cost us in terms of
event creation and synchronization.  However I would leave these
aspects to be delt with later at an optimization phase.  Code for
clarity and good form now.
 
However if we read in the same thread and use direct memory buffers
in a small amounts ~8k then there may be a real performance reason for
consolidating the two stages: input detection and socket reads.  Would
you think the performance gain is significant?

I would continue to work with SUN to solve the reading in a separate
thread thing.  It should be fixed.  However down the road in a beta 
release stage we can optimize the server and determine if consolidation
certain stages is worth while.  You need statistics and a population of
clients to determine the net effect in a SEDA based design whether 
stage consolidation really pays off.  Thoughts?

Alex


> 
> From: Wes McKean <wmckean@logictrends.com>
> Date: 2003/11/26 Wed PM 06:01:34 EST
> To: "Apache Directory Developers List" <directory-dev@incubator.apache.org>
> Subject: Re: Serverside NIO:  Not ready for Prime Time
> 
> Reading the data in single thread seems to solve the problem, and works 
> equally well on Windows and Linux.  I will post a bug to the Bug Database at 
> Sun on Friday.
> 
> Wes
> 
> On Wednesday 26 November 2003 09:48 am, Wes McKean wrote:
> > Well, what really aggrevates me about all of this is that the
> > implementation I am using is relatively simple.  One thread handles the
> > catching of the events, and a separate thread handles the processing.  It
> > is all realatively clean, and straight forward.  It works like a champ
> > under Linux, and works about 70% under Windows.
> >
> > What I would like to see happen is somebody at Sun address this issue. 
> > Does anyone have any experience with this?
> >
> > Your suggestion for reading the byte buffer in the same thread is less
> > elegant than the current solution and could cause issues ( I'm thinking
> > about them as I write this :-)  In our case, we are passing the bytes from
> > the
> > SocketChannel off to the Decoder for processing.  What happens if an entire
> > ASN.1 packet does not come over in the first read event?  This is what will
> > have to happen:
> >
> > 1.  The read event comes in.
> > 2.  The *selector* thread reads 2/3rds of the ASN.1 packet ( it has no way
> > of knowing when the complete packet has arrived)
> > 3.  It passes the buffer off to the decoder.
> > 4.  The decoder reads  the buffer, and then blocks cause it only has 2/3rds
> > of the packet.
> > 5.  The second READ event comes in with the rest of the packet.
> > 6.  The selector thread reads the bytes and appends them to the end of the
> > first read.
> > 7.  The decoder thread unblocks and continues reading bytes to the end of
> > the ASN.1 packet.
> >
> > That's gross... but I've got some bandwith this week, so I'm willing to
> > give it a try to see if it works.  I'll report back by Friday.
> >
> > Wes
> 
> 


Mime
View raw message