directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ApacheDS] Configuration of protocols
Date Thu, 11 Oct 2007 18:15:04 GMT
Should we go ahead and rename XxxConfiguration to XxxServer then?  I'm still
trying to get
back in the groove on this stuff - looking at the code now.  I'll comment
more on the issues
you mentioned later regarding creating filters.  I have a feeling those
wrappers you created
may come in handy for setting up the chain giving us another degree of
freedom.

Alex

On 10/11/07, David Jencks <david_jencks@yahoo.com> wrote:
>
> After a lot of discussion on IRC with Alex we think we have an approach we
> like for providing the acceptors to the servers, so i coded most of it up
> and committed it (rev 583683).  Lets see if I can describe it:
> - the acceptors get to be components, and they each get a reference to a
> thread pool (Executor).
> - there's a DatagramAcceptor and a SocketAcceptor, so the server can be
> sure to get the kind it expects.
> - these wrap the Mina acceptor classes to
> -- install a final filter
> -- assure that some parts of the IoAcceptorConfiguration are configured
> correctly (right now, that ThreadModel.MANUAL is set which appears to mean
> we are using an external thread pool)
>
> Each server has 2 (will be one for non-udp protocols such as ldap)
> Acceptor references.  On start it binds stuff at its port to the acceptor
> and on stop it unbinds.  It supplies a (partially configured)
> IoAcceptorConfiguration to the bind method along with the actual protocol
> handler and the address to bind to.
>
> We were thinking of allowing configuration of a non-default
> AcceptorConfiguration through spring which code-wise would be pretty easy
> but would be much easier with xbean-ization of mina.  Alex added the xbean
> tags and pushed snapshots of mina and I added an experimental
> mina-xbean-spring module to apacheds to build the xbean fluff.  NOTE THAT
> this new module uses mina 1.1.4-SNAPSHOT whereas everything else uses mina
> 1.1.2, so to use xbeanized mina components we need to adjust the mina
> version.  We're hoping the mina guys will pick this up and move it to the
> mina project.
>
> Among other side effects the ApacheDS module isn't needed in the servers
> I've worked on (everything except ldap and ldaps AFAICT).
>
> Alex thought that the filters in one of these acceptors ought to be
> configurable by spring but looking into it more I don't quite see how.... it
> looks like we'd need a filter factory rather than a list of filters.  We
> could presumably take a list of filters and add them to the factory one by
> one as we do with the final filter now.  I might be missing something here
> since I haven't looked at the mina code at all.
>
> One bit left to do is renaming the XXXConfiguration to XXXServer or
> something more appropriate and checking to see if anything can be pruned.
>
> Of course comments are more than welcome...
>
> thanks
> david jencks
>
> On Oct 10, 2007, at 1:00 PM, Alex Karasulu wrote:
>
> Hi David,
>
> On 10/10/07, David Jencks <david_jencks@yahoo.com> wrote:
> >
> >
> > On Oct 10, 2007, at 11:35 AM, Alex Karasulu wrote:
> >
> > Ok I had some sleep and low and behold the ideas came to me :).  I think
> > I have a clear picture of
> > what we need to do to handle this properly.  Let me describe that here
> > then try to figure out how
> > that fits with what you have done and described below.
> >
> > First if Emmanuel is right about NTP needing both protocol end points on
> > the same port for both
> > transport protocols (UDP/TCP) then there is no need to have twice the
> > configuration. Then
> > something like these combinations would suffice:
> >
> > <ntpServer port=123>
> >    <#directoryService/>
> >    <#udpAcceptor/>
> >    <#tcpAcceptor/>
> > </ntpServer>
> >
> > Configures both UDP and TCP transports on port 123.
> >
> > <ntpServer port=123>
> >    <#directoryService/>
> >    <#tcpAcceptor/>
> > </ntpServer>
> >
> > Configures only TCP on port 123.
> >
> > <ntpServer port=123>
> >    <#directoryService/>
> >    <#udpAcceptor/>
> > </ntpServer>
> >
> > Configures only UDP on port 123.
> >
> > Note that I did not pass in <#apacheDS/> which is not needed since this
> > service will depend on the
> > core directory service plus the MINA components.  Depending on which
> > IoAcceptor is set the respective
> > transport protocol is used.  If both are set then both transports are to
> > be used.
> >
> > So instead of having the NtpServer class just deal with setting up a
> > single endpoint for one transport
> > protocol it will handle all endpoints for all transport protocols and no
> > more configuration bean.  The
> > component is wired directly but how it's wired determines what is
> > enabled.
> >
> >
> > In order to make this work and still be typesafe we either have to:
> >
>
> I like the idea of making it type safe.  This can be achieved by making
> getter/setter pairs for specific
> transport types on the XxxServer use more specific interfaces that are
> already present in MINA:
>
> DatagramAcceptor or
> SocketAcceptor
>
> This would best settle the type safety issue IMO.
>
> - create different classes for the tcp and udp IoAcceptor instances so you
> > can't hook up the wrong one
> >
>
> They already exist as stated above so this option is best I think.  WDYT?
>
> or
> >
> > - wrap the IoAcceptor get the appropriate BaseIoAcceptorConfig from the
> > wrapper.  This would work if all uses of udp use the same acceptor config
> > and all uses of tcp use the same tcp config.  I'm not qualified to guess if
> > this is the case now and in the forseeable future.  In this case the
> > XXXServer class (currently typically XXXConfiguration) could get a list of
> > IoAcceptorwrapper objects instead of just one or two.
> >
> > Another aspect I don't know about here is exactly how MINA distributes
> > threads between udp and tcp.  My guess is that MINA has a thread pool that
> > it uses for all incoming requests, whether udp or tcp.
> >
>
> Yes this is the case.  We have two pools: one for the logical request
> handling and one for the protocol
> codec IO handling.  A thread from one pool hands off the req/resp object
> to the other.
>
> If we want to preserve a single thread pool for all requests this may take
> > some hoop-jumping-through with separate configuration of the tcp and udp
> > IoAcceptors.  On the other hand I've heard rumors that you can get spring to
> > call a method and use the result as the reference value, so we might be able
> > to do something with  that and preserve a single MinaBean.
> >
> >
> > Anyway if someone wants to explain the desired model here or point me to
> > docs that would be great.
> >
>
> I have some ideas but I'm not so confident.  You're right about more
> experimentation being needed.  Slowly as we
> chug along and get rid of these distracting issues of configuration we'll
> be able to best move the MINA component
> assembly out of the ApacheDS object.
>
> > If the other protocols obey the same requirements where both transport
> > endpoints are needed on the
> > same port then we can follow this same pattern.  We just have to watch
> > for the special cases if they
> > do exist.
> >
> > Now what impact does this have on OSGi and on configuration in DIT for
> > the future.  I don't know that
> > yet and it's something to think about.
> >
> > Ok now inline for discussing your changes ...
> >
> > On 10/10/07, David Jencks <david_jencks@yahoo.com > wrote:
> > >
> > > In rev 583375  I moved all the non-ldap protocol servers into
> > > independent components and provided 2 NTP implementations as a basis for
> > > further discussion.
> > >
> >
> > Ok so you broke it out to have a UdpNtpServer and a TcpNtpServer which
> > are in them selves what you
> > deem one implementation approach I guess right?
> >
> > Then there is this NtpConfiguration which starts both together as a
> > configuration bean + manager for the
> > other two services?
> >
> > NtpConfiguration illustrates the approach of a single component to
> > > configure both udp and tcp versions of the same protocol.  This could
> > > trivially be enhanced with flags to enable/disable the tcp or udp choices.
> > > If we decide on this approach I would rename the class NtpServer.
> > >
> > > server.xml configuration of this looks like:
> > >
> > >   <ntpConfiguration ipPort="80123">
> > >     <apacheDs>#apacheDS</apacheDs>
> > >   </ntpConfiguration>
> > >
> >
> > Ok then this would be close to what I was pointing out above but it uses
> > this ApacheDS reference
> > instead of feeding in the MINA components.  I would like to see these
> > configuration objects go away
> > all together without even the ServiceConfiguration base class.  Instead
> > an AbstractServer object can
> > be defined and used for server implementations like NtpServer with the
> > base configuration details in
> > it.
> >
> > This way we don't have a configuration bean + additional code to start
> > and stop subordinate services.
> > So let me list it out:
> >
> > AbstractServer (or AbstractService )
> >
> >     Replaces ServiceConfiguration as base class for protocol servers.
> > This is the common
> >     denominator for all servers running in ApacheDS.  It may need some
> > properties moved
> >     into some subtypes since the present ServiceConfiguration has more
> > than the common
> >     denominator.
> >
> >
> > Is this any different from renaming ServiceConfiguration to
> > AbstractService?  I tried to avoid extra renamings since I thought it would
> > make the actual changes into components harder to see.
> >
>
> Well there might be more to it like removing some properties that are not
> common across the board but
> yes this is what it looks like is going to happen.  However note that now
> the semantics are clear that what
> is being wired is the actual component and not just a bean used to hold
> configuration information.  Subtypes
> of that server/service will now hold the logic and structures to manage
> the runtime state of the component.
> I think that's the main goal with this whole get rid of configuration
> beans effort.
>
> SNIP ...
>
> Alex
>
>
>

Mime
View raw message