avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: Monitored Components
Date Thu, 09 Oct 2003 13:42:41 GMT
Leo Sutic wrote:
> IoC doesn't mean that there's no flow of information from the
> component to the container, just that *the container has the final
> word* regarding what is actually *done* with the information.

The way I was looking at it, the container controls when information 
flows, and the component is not allowed to initiate any communication on 
its own ("You shall speak only when spoken to"). Your definition is much 
more useful.

thinking...it seems like the "Will only speak when spoken to" is a 
natural property for passive components (ie that don't implement 
startable nor use seperate threads of execution), whereas you won't be 
able to hold it for active components.

> I have no problem with your use of lookup() to obtain a monitor.
> Perhaps even more in line would be to use the Context for this,
> though. (Or are we getting rid of that one in favor of the
> ServiceManager?)

here we go again :D

I believe the last time we talked about all this we resolved (after 
three weeks of debate or so) that the context is used for 
container-component communication and the servicemanager for 
inter-component communication. The tricky part is when you have a 
service which can either be provided by the container or by another 
component. Muddy, since your average container makes most things into 

So no clear answer here.

Me, I'm a type 3 convert, and in that world there is no distinction 
between container or component-provided services. Which works.

> Regarding the multitude of status messages - I don't think that will
> be any help.

It ties in with the no-logging idea I think. You want the container to 
notify an admin that a component died. It'd be useful for the admin to 
know why that happened. Hence the specific message. And since, in java, 
things die because of exceptions, that's a nice way of providing the 

> I don't really want to have one component notify every
> other component that they're broken, because there's usually nothing
> the other components can do about it.


> Just throwing more into the mess - multithreading:

actually...no problem at all!

The socket server IMV is not actually concerned with multithreading, nor 
does it need to be (unless you're running an infiniband-style 
200-processor server where a single processor cannot accept() 
connections as fast as the networking hardware). Just let the executor 
and handlers worry about that.

The single function of the socket server is to hand off connections to a 
handler. The handler is allowed to do multithreading if it wants to. It 
might again depend on an Executor, like this:

class AlternatingConnectionHandler implements ConnectionHandler
                                                      // code sketch
   /** in this example: a specialized pool that will call setSocket()
       on get() */
   WorkerPool m_workers = /* ... */

   handle( Socket socket )
     worker = m_workers.get( socket );
     m_executor.execute( worker );


   class Worker implements Runnable
     Worker() { /* ... */ }
     setSocket( Socket socket ) { /* ... */ }
         /* ... */
         if(!running) return; Thread.yield();
         /* ... */
         if(!running) return; Thread.yield();
         /* ... */
         m_workers.release( this );
     stop() { running = false; }

and you just happen to pass in a PooledExecutor here when you want 
multi-threading. Or you might just let connections queue up in your 
handler. Or...

 > m_executor.interruptAndStopAll(); // Does this method even exist?

nope, it doesn't. In fact, the executor interface specifies that it 
might even be single-threaded. But if you're using a PooledExecutor, for 
example, it does:


However, in general, it is not the responsibility of the server or 
handler components to shut down the threads in a pool, but of the pool 
itself (which, after all, is a component, too).



To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message