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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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
