directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [ApacheDS] Configuration of protocols
Date Wed, 10 Oct 2007 19:29:42 GMT

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:

- create different classes for the tcp and udp IoAcceptor instances  
so you can't hook up the wrong one


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

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

> XxxServer
>     Takes IoAcceptors.  Some servers need one for each transport  
> some may only need one.
>     Some may take both but optionally.  These protocol servers then  
> manage binding to the
>     appropriate port for the transports.  If somewhere down the  
> line configurations differ
>     dramatically for one transport verses another this model still  
> works.  You can still have a
>     UdpXxxServer and TcpXxxServer subtyping the base XxxServer or  
> directly extending the
>     AbstractServer base class.  In these transport specific  
> subtypes they may only expose
>     getter/setter pairs for IoAcceptors for their respective  
> transport.  So this model is most
>     flexible for whatever comes down the pike.
> AbstractNtpServer, TcpNtpServer, and UdpNtpServer illustrate the  
> approach of a component per protocol version.  server.xml  
> configuration of this looks like:
>   <udpNtpConfiguration ipPort="81123">
>     <apacheDs>#apacheDS</apacheDs>
>   </udpNtpConfiguration>
>   <tcpNtpConfiguration ipPort="81123">
>     <apacheDs>#apacheDS</apacheDs>
>   </tcpNtpConfiguration>
> This might not at all be necessary if we attack this problem like  
> the way suggested above.
> I don't have a strong preference between these two approaches and  
> think they both are equally good components.  I think the first,  
> single component managing both servers, will be easier for our  
> users to understand and configure, although it might be  
> conceptually slightly less pure.
> I think we can do it right and be pure.  We just need to think  
> about it more but at some point we must stop and
> implement it so we're not stuck thinking forever.  This is why your  
> commit was a great move it helps look at an
> example we can take to the next step of the discussion.  Thanks for  
> it.
> Whatever the outcome of this discussion I think the next step,  
> other than conforming the protocol servers to whatever we decide,  
> is to move the mina setup code in ApacheDS into a separate  
> component: this would replace the ApacheDS reference in all these  
> servers.
> Yes this would be good.  I noticed you made these servers dependent  
> on the server-jndi module just to
> pass in the ApacheDS reference.  I'd like to see this dependency go  
> away where the dependency is really
> on the core and MINA components.
> More below ...
> <OT>
>> There's an extreme danger here of making a mountain out of a
>> molehill :-)
> These comments are counter productive and whether deliberate or not  
> are threatening to bypass
> further reasoning about this matter by trivializing the discussion  
> as being excessive.  You are entitled
> to this opinion but not to shorting this discussion and just doing  
> it some way.
> I'm not trying to force anything and am listening to your  
> suggestions since I value them.  I pushed to
> champion your effort to remove these configuration beans and  
> brought about the bigbang effort even
> though others were worried about it's impact.  This move has pushed  
> out my personal objectives as
> well but we believed in your ideas.  This is why I am following  
> through with them and trying to do it
> to the best of my ability by completely removing these  
> configuration beans.
> This is a two way street.  As I extend the benefit of the doubt and  
> patience you're way you owe me
> some patience as well.  Not saying you're not giving it.  But the  
> comment above is a subtle indicator
> that your patience is wearing thin.  When this happens stop and  
> think about the big step we all took
> to meet your wishes.
> Also consider that you are new to this project and may not have  
> complete information to foresee
> problems down the line.  On the flip side, you're in a unique  
> position to really show us how wrong
> some of our design decisions are because of your fresh new  
> perspective.  Plus you're not a newbie
> and a solid engineer as witnessed by your past contributions.  We  
> know how incredible you are.
> So bear with me because something in the back of my head is telling  
> me to do this right with
> a little more discussion.  We'll get to the bottom of this but  
> let's consider all our options.

I agree saying "extreme" was extreme and uncalled for.  However to my  
mind both proposals accomplish 95% of the possible improvements,  
making all the protocol servers into components under their own  
lifecycle control, rather than data used by an external controller.   
I'm happy to keep talking more or less indefinitely but I think that  
if we write the code we will start finding better ways than if we  
just talk about stuff abstractly.

> </OT>

david jencks

> Alex

View raw message