directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [ApacheDS] Configuration of protocols
Date Wed, 10 Oct 2007 20:00:21 GMT
Hi David,

On 10/10/07, David Jencks <> 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

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?

> - 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 <> 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

SNIP ...


View raw message