directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes McKean <wmck...@logictrends.com>
Subject Re: Server Side NIO: Completed
Date Mon, 17 Nov 2003 21:54:39 GMT
OK.  I got the stuff checked in.  I'm gonna go visit the design pattern for 
connections again now.  Let me know if you have something else interesting to 
do....

Wes

On Monday 17 November 2003 04:11 pm, Wes McKean wrote:
> Well, I can't get the stupid CVS to let me do a commit through eclipse.  It
> insists on doing an add, but the resource is already there, so naturally it
> fails.  How do I get around this??
>
> I can just email you the source if worse comes to worse, but that would
> suck.
>
> Wes
>
> On Monday 17 November 2003 03:49 pm, aok123@bellsouth.net wrote:
> > Another thing I forgot to mention.  Eve will now user JNDI as the backend
> > interface - the front end use the server side LDAP JNDI provider to do
> > the work on the backend.  I don't know how much of this I already added
> > but I'm sure there a holes to be filled.
> >
> > Now there are also some subtle integration aspects between the front end
> > and backend JNDI interaction which need to be sorted out.  Namely the
> > front end could provide additional JNDI Context information that could be
> > used by interceptors in the backend.  We will need to resolve these
> > together.
> >
> > Ok back to my 300 emails.
> >
> > Alex
> >
> > > Great! You checked it in right? I'll try to take a look soon.
> > >
> > > > When an input operation is completed, the decoder must make a call
> > > > into the InputManager to reRegister the socket channel for READ
> > > > operations. This establishishes a dependancy between the InputManager
> > > > and the Decoder.  In the case of a close on the SocketChannel, while
> > > > it is waiting on a READ, the decoder gets a READ event, which results
> > > > in an IOException, wrapped in an ASN1Exception, which causes the
> > > > decoder to make a call into the ClientManager to remove the client
> > > > key and socket channel from the lists it is managing. This
> > > > establishes a dependancy between the decoder and the ClientManager. 
> > > > I *think* I can move the code that handles the closing of the
> > > > connection into the InputManager, since it can intercept the
> > > > DecoderException thrown from the code handling the ASN1Exception.  If
> > > > anyone knows or can think of a better way to handle this, then please
> > > > comment.
> > >
> > > Give me a chance to look at the code later this evening to be able to
> > > give you a more informed opinion.
> > >
> > > > The question is:
> > > >
> > > > What to do with the code now that it is finished and tested?  Do we
> > > > want to wait until the software is uploaded into the incubator, or do
> > > > you want me to go ahead and upload the completed changes to Source
> > > > Forge?
> > >
> > > This answers my question above.  For the time being until I get the
> > > structure of the sandbox1 clearly established lets continue to use the
> > > sf.net sandboxes.  What I will try to do is look at reorganizing the
> > > sandbox1 subprojects and import them into the incubator on the agreed
> > > upon structure for the overall project.  Now your stuff is all for
> > > phoenix.  Now your job (and a good one at that) is to migrate it over
> > > to merlin (just for the front end).  We can start bringing eve
> > > together. You work it from the front end and I the backend.  We'll meet
> > > in the middle.  So as you migrate to merlin start moving the code to
> > > the incubator.  Now this my opion really what do u think about the
> > > path?
> > >
> > > Alex


Mime
View raw message