directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: [mina] Introducing the New API for 0.9.1.
Date Thu, 26 Jan 2006 12:33:39 GMT
 

 

________________________________

From: Trustin Lee [mailto:trustin@gmail.com] 



2006/1/25, Jose Alberto Fernandez <jalberto@cellectivity.com>:

	I think we need to define better how is it that we want MINA to
be
	configured and used. When people use the Spring approach, they
	definitely want to be in control of the objects they create and
of the
	scope of those objects in the system. Singletons are a no-no on
that 
	regard. It should be up to the Spring configuration to decide
whether an
	object should be a singleton or not.


We already discussed on singleton issues and we'll provide a
non-singleton way.

	 

	On the same vein, when we compose a system out of different
components,
	we also want to maintain unknown interactions of the components
to a 
	minimum.


What is the 'unknown interaction' here?  I don't think we cause any
unknown interaction.  Besides adding a thread pool by default, what
IoService does is almost the same with the code that configures your
acceptors and connectors manually. 

 

For example:

   Component A does: IOService.connect(.....); (Maybe more than once)

 

   Component B independently does: IOService.connect(....); (maybe more
than once)

 

Now component A decides to go away and shut itself down:
IOService.unbindAll();

Ups, Component B just lost all its connections and does not know about
it.

 

These are unknown interactions due to the usage of a singleton.

 

	 

	I did not fully like SimpleServiceRegistry in particular because
it had
	endless amounts of methods depending on the kind of service one
wanted, 
	but at least when one called unbindAll() I knew the scope of
what was
	been unbound. I would like IOService to work the same way in
that
	regard. The only thing I would be willing to have statically is
some
	registry of all the IOServices currently available, to be able
to do 
	global management. Something like:

	  /**
	   * Creates if necessary and returns the IOService instance of
that 
	name
	  */
	  public static IOservice getInstance(String name);
	
	  /**
	   * List all the current active IOService instances
	   */
	  public static IOService[] listInstances();


It would be nice if we have this kind of feature, but do we really need
these registry methods?  Is the 'name' an ID of IoService instance? 

 

As I said, maybe they belong on some factory. The reason for having
something like this is management. You have a system build by several
components that can independently be using MINA. But you still want a
way to tell everyone to shutdown when you want the system to go down. As
the server will stay alive until all the IOServices finish, you need a
way to tell them to shut down gracefully. 

 

These are just loose ideas, not an API. Maybe what is needed is a
notification mechanism. Something like:

 

public static IOService getInstance(UnbindListener listener);

 

public static void shutdownIOServices();

 

public interface UnbindListener {

 

    void unbind(IOConnector);

    void unbind(IOAcceptor);

}

 

In this model, when you obtain an IOService you provide a listener where
the component will receive notifications of connections being terminated
and hence has a chance to update its state accordingly. Each component
can do as it see fits, and will only be notified about things created by
his own IOService instance.

 

 

	 

	Here I am a little ambivalent. I am all for type safety. But I
like the
	simplicity of addressing using a URI and being able to pass
parameters 
	at the same time. On the other hand, the objects returned by the
methods
	should be manageable using set/getters, which means for each
type of URI
	one should define a proper interface that define all its
properties. The 
	URL parameters can be simply introspected on the setters.


I didn't get what you're saying.  Could you give me an example?

 

I do not have your code in front of me so this is just from what I
understood from reading the messages on this thread.

 

So you have different types of URLs:

 

String  url =
"nio:socket:*:8080?reuseAddress=true&threadModel=normal&threadPoolSize=2
0&receiveBufferSize=4096",

 

You get from your IOService instance a URL-like object, x (or y),
already introspected to set the parameters passed in the URL.

 

   IOAcceptor x = ioService.getAcceptor(url);

 

   IOConnector y = ioService.getConnector(url);

 

After that, you could set more properties programmatically by
downcasting to the correct type (interface) specific to the URL you
requested.

 

   ((IOSocketAcceptor) x).setXYZ(....);

 

Now you can call on the object to actually perform the connection or
binding, passing the handlers and filters.

 

  x.bind(filterBuilder, handler);

 

  y.connect(filterBuilder, handler);

 

Jose Alberto

 


Mime
View raw message