commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: [HiveMind] DeferredService performance
Date Mon, 22 Sep 2003 20:11:27 GMT
I did some refactoring and implemented the new deferred service model; seems to work just fine.
Don't have before and after performance numbers, but its pretty obvious that after the first
invocation, it has to be faster, since its a) avoiding a method call and b) avoiding a synchronized
block.  Good stuff, thanks for the idea.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: Christian Essl [mailto:christianessl@yahoo.de] 
> Sent: Sunday, September 21, 2003 6:39 PM
> To: Jakarta Commons Developers List
> Subject: Re: [HiveMind] DeferredService performance
> 
> 
> > Javassist doesn't do inner classes, so there's still going 
> to be some
> > kind of _setService() kind of
> > method used by the proxy when it replaces itself.
> 
> Thank you that's right, and as you see I don't realy know Javassist.
> 
> >
> > I'm using "_" to indicate "infrastructure" methods, in the believe 
> > that
> > this will not cause a
> > conflict. Between that, and method overloading (by 
> parameter type) I 
> > would not be too worried about
> > method name conflicts.  We should document that service 
> methods should 
> > not contain method names with
> > a leading underscore (perhaps enforce that as well).
> 
> I agree and would say if there is a conflict it is enforced 
> any way (maybe 
> a meaningfull exception).
> 
> ????? LifeCycle ???????
> 
> Just a few things I thought about:
> 
> > I see it as an added service model,
> > by leveraging ThreadEventNotifier and a ThreadLocal, much like the
> > "threaded" service model. Also,
> > there should be another lifecycle interface, like 
> Initializable, for 
> > service implementations ...
> > "Passivatable"? Ugh.
> 
> Yes an additional interface would be needed (It is hard for 
> me to find a 
> good name - English is not my first language).
> 
> Actually I thought initially of two other cases: First a 
> balance to the 
> startup phase where the Registry (and all the Services) are 
> terminated. In 
> this case the user has to take care that no thread uses anymore any 
> services and than he calles Registry.terminate(). All 
> ServiceModels should 
> and can be stopped in this case. I think that's currently the most 
> important case for ConnectionPools etc. The second case is about 
> termination of certain Services during the Runntime of the Registry.
> 
> > I'm concerned about degenerate cases; what if a service, when it
> > passivates, invokes methods on
> > other services, activating them? We might need a system of locks or 
> > checks to handle those cases.
> 
> I would say both (of my) cases will need a dependency-registry, which 
> controls the termination and checks for circularities. If a 
> service is 
> about to be stopped all the dependend services will be 
> stopped first.  
> While I think the definition of the dependencies 
> conceptionally belongs in 
> the initializeService method I would still keep it in the 
> hivemodule.xml 
> (It is just easier to implement, because Services neither 
> know their id nor 
> the id of the services they depend on or of their Factory).
> 
> Do you think this is a possible way? Is it enough?
> 
> 
> > Actually, much like EJBs, a service which can be pooled may be 
> > interested
> > in when it is brought out
> > of the pool and brought into active service for a thread, 
> and when it is 
> > passivated and stored back
> > into the pool. One interface ("ServiceLifecycle"?), two methods.
> >
> 
> Therefore (and because pooling is for my cases not the same 
> as destorying) 
> I would suggest a shutdown process like this:
> 
> 1) ServiceExtensionPointImpl.destroyService() -> 
> ServiceImplementationConstructor.destroyCoreService(Object 
> coreService)
> 
> 2a) CreateClassServiceConstructor() -> ((Destroyable) coreService) 
> .destroy()
> 
> 2b) InvokeFactoryServiceConstructor() -> 
> ServiceImplementationFactory.destroyCoreService(Object 
> coreService) -> 
> ((Destroyable) coreService).destroy();
> 
> ad 1) The ServiceExtensionPointImpl checks if the Service can 
> be destroyed 
> now (normally only if the registry is shut down). The SEPI 
> also remembers 
> the CoreServiceImpl. The Threaded takes it from the 
> threadlocal. If the 
> threaded wants to destroy (or pool) one of its CoreImpl it calls the 
> ServiceImplementationConstructor with the CoreService from 
> the threadlocal.
> 
> ad 2a) the CreateClassServiceConstructor just checks if the 
> CoreService 
> wants to be notified of destroy and notifies it.
> 
> ad 2b) the InvokeFactoryServiceConstructor gives the 
> coreService further to 
> the Factory which created it. The Factory can now do pooling etc (the 
> Pooling interface depends on the factory). The factory (if it 
> does not 
> pool) must than check if the coreService wants to be informed 
> that it is 
> destroyed (alternatively it could return a boolean indicating 
> wheter this 
> check should be done by the InvokeFactoryServiceConstructor).
> 
>     Regarding the second case (unloading a Single threaded 
> Service during 
> Registry runntime) I would say we need an extra ServiceModel. 
> It would be 
> quite similar to the deferred-model but it could also change 
> back to the 
> deferred state. It also keeps a count of threads acessing the current 
> Service. When asked to shutdown it first changes to the 
> deffered state. 
> Than waits until the last thread has left the (old) 
> CoreService and than 
> does the shutdown process as described above. If the service is newly 
> needed it starts it like the deffered proxy.
> 
> It would be nice if you could comment on that and I would 
> realy like to try 
> implement such a thing.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


Mime
View raw message