directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject RE: Serverside NIO: Not ready for Prime Time
Date Fri, 28 Nov 2003 14:35:58 GMT
> > 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?
> >
> Other than what I already mentioned.  The ASN.1 stuff accepts an
> InputStream,
> which is by nature blocking.  We do not have access to the SNACC code to
> change this.

Oh contrare, I've been looking at Robb snickers rip of the SNACC code.  I 
think we should eventually rewrite the encoder and decoder.  I think we 
could make it really efficient with NIO constructs and later use it for
other types of ASN.1 based servers.

Question is do it now or later.  I'm thinking later.  Right now we can 
probably just get the needed input stream from the channel.  I want to 
get involved with this too.  Also lots of Peter's comments are making
sense as I re-discover the problems.

> So to fix this, I basically had to catch the READ event and read the
> transaction in the InputManager, then pass a new ByteBufferInputStream off
> to
> the decoder.  Now the trick is that if the READ only processed a partial
> transaction, then the rest of the transaction is going to come into the
> InputManager thread while the Decoder thread is decoding the transaction.
> So
> the InputManager thread has to look up the ByteBufferInputStream and
> append
> the new ByteBuffer while Decoder is decoding.  This is a hack in the
> classic
> sense of the word.
> If the InputManager could determine that it had read a complete
> transaction,
> then pass it off to the decoder, I would gladly admit that that solution
> is
> as elegant as processing the READ event in one thread and reading and
> processing in another.
> The good news is that for now, the hack works and will satisfy our needs
> until
> either the bug is addressed, or we are able to come up with a more elegant
> solution.  The hack is probably even worthy of a production environment.
> I'll upload the new code to the sandbox and we'll just take it from there.

Ok if this will hold us for now then let's just get there and then we can
rethink the overall strategy.  


View raw message