You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/10/16 21:43:14 UTC
[merlin] auto-decommissioning
Recent updates to the Merlin platform in CVS include support for
auto-decomissioning of components that are no longer referenced.
The following log is a very simple demonstration testcase that
creates a bunch of non-referenced components, invokes the garbage
collector, and logs the resulting component decommissioning by
Merlin.
[junit] Running playground.StandardTestCase
INFO ] (testcase): Creating a bunch of hello instance
INFO ] (template.hello): initialization as: 6829042
INFO ] (template.hello): initialization as: 26030331
INFO ] (template.hello): initialization as: 9089167
INFO ] (template.hello): initialization as: 21860890
INFO ] (template.hello): initialization as: 28517927
INFO ] (testcase): running gc
INFO ] (template.hello): disposal: 6829042
INFO ] (template.hello): disposal: 26030331
INFO ] (template.hello): disposal: 9089167
INFO ] (template.hello): disposal: 21860890
INFO ] (template.hello): disposal: 28517927
INFO ] (testcase): gc done
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.109 sec
Note that this is achieved *without* invoking release( object ).
Am now looking into achiving the same thing with pooled objectes.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Stephen McConnell <mc...@apache.org>.
hammett wrote:
>----- Original Message -----
>From: "Stephen McConnell" <mc...@apache.org>
>
>
>
>>The potential issue here (that we discussed way back) concerns the fact
>>that a component lifestyle is not assured.
>>
>>
>
>Rulez! I searched for something like this in .Net but didn't find. I'm aware
>that Merlin transient lifestyle handler keeps created objects in a list. Is
>it the best? If someone forget to call release the instance will be there
>for the entire container lifetime... I tried to solve that to not depends on
>releasing. :-\
>
>
It depends on which snapshot you were looked at - it was either the old
"TODO: add weak references" or the current version where the weak
references are in place. In the current version the transient lifestyle
handler maintains a queue of weak references that have been garbage
collected. It also maintains a list of soft references to instances
created. The list is required so that the handler can decommission the
compoent it has established during its own disposal cycle. The queue of
garbage collected objects provides the information I need to be able to
compact the list of weak references.
With this change there are only two know memory problem - logkit
categories and container removal from the meta model. If I'm running
Merlin for months on end without restart, and if there are continual
creation of log catagories, and the components are destroyed, I'm still
left with logkit logging channels in memory. Basically I need to dig
into logkit and change the Logger hard references to WeakReferences.
For the meta-model I need to to do some thingking about possibilities
for auto removal of containers that are no longer referenced.
Stephen.
>hammett
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Stephen McConnell" <mc...@apache.org>
> The potential issue here (that we discussed way back) concerns the fact
> that a component lifestyle is not assured.
Rulez! I searched for something like this in .Net but didn't find. I'm aware
that Merlin transient lifestyle handler keeps created objects in a list. Is
it the best? If someone forget to call release the instance will be there
for the entire container lifetime... I tried to solve that to not depends on
releasing. :-\
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [merlin] auto-decommissioning
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> The potential issue here (that we discussed way back)
> concerns the fact that a component lifestyle is not assured.
> So basically the consuming component does not know if service
> implementation is pooled or not - and as such, non-release
> of a component could lead to a breakdown because the pool
> capacity reaches a maximum.
>
> There are two aspects which I think change this conclusion ...
>
> (a) the notion of active versus passive release
> (b) the ability of a pool implementation to partitipate in
> passive decommissioning when required
But how does this change the conclusion that active release is
always safe, and passive release is potentially unsafe, and that
the guideline therefore is "always active release"?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>Additionally, since GC isn't predictable, you may run out of pooled
>objects real fast.
>
>Consider a DB app with a connection pool of 24 connections, and 1GB
>of free heap.
>
>It processes ten requests per second and each request uses up
>10MB of memory. This means that it will take 100 requests to
>use up the memory, but only 24 to use up the connections, by
>which time the JVM won't GC since you have 760MB of heap left
>to much through.
>
>Sure, you can run GC like a nutter in the background, but this
>seems a bit severe.
>
And unnecessary. What I'm looking into is how a pool can interact with
a memory management service taking into account pool expansion,
collection policies and so forth.
>
>
>I think we came up with the following last time:
>
>Two choices:
>
> 1. manager.release() - as it is now.
>
> 2. Require that each service interface that can have a pooled
> implementation (SAXTransformer, Connection, etc.) has one
> method (endDocument(), close(), etc.) that, after it is called
> the component can return to the pool safely.
>
What I'm currently testing provides full support for the
ServiceManager.release() - i.e. active consumer driven release. Behind
the scenes I'm providing the possibility for passive release (i.e.
decomissioning handled by the container in the event that a component
has not been actively released but is no longer referenced). A
component author can employ an active release when appropriate - and
that makes things simpler for developers who are dealing with
applications invoking lots of singleton type components.
The potential issue here (that we discussed way back) concerns the fact
that a component lifestyle is not assured. So basically the consuming
component does not know if service implementation is pooled or not - and
as such, non-release of a component could lead to a breakdown because
the pool capacity reaches a maximum.
There are two aspects which I think change this conclusion ...
(a) the notion of active versus passive release
(b) the ability of a pool implementation to partitipate in
passive decommissioning when required
And one factor that is driving my attention here - with Merlin 3 we can
really easly manipulate the deployment info, add and remove compoents
and containers, deploy, undeploy, redeploy etc. All of this in the
context of a single long running JVM. That introduces a bunch of
concerns related to long-term memory management. In turn that raises
the issue of the relationship between component management and memory
management.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [merlin] auto-decommissioning
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Additionally, since GC isn't predictable, you may run out of pooled
objects real fast.
Consider a DB app with a connection pool of 24 connections, and 1GB
of free heap.
It processes ten requests per second and each request uses up
10MB of memory. This means that it will take 100 requests to
use up the memory, but only 24 to use up the connections, by
which time the JVM won't GC since you have 760MB of heap left
to much through.
Sure, you can run GC like a nutter in the background, but this
seems a bit severe.
I think we came up with the following last time:
Two choices:
1. manager.release() - as it is now.
2. Require that each service interface that can have a pooled
implementation (SAXTransformer, Connection, etc.) has one
method (endDocument(), close(), etc.) that, after it is called
the component can return to the pool safely.
My own thought is that we shouldn't rely on GC to do anything
except give us the illusion of an infinite heap. It is too
unpredictable.
/LS
> From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Leo Simons <le...@apache.org>.
Alexis Agahi wrote:
> On Friday 17 October 2003 12:35, Leo Simons wrote:
>>what about 'active' components that are not referenced? Like a socket
>>server?
>
> as long as there is a reference on the component object, I suppose that GC
> wont call finalize method (that would probably call component dispose)
>
> lots of supposition here ;))
that's the scary thing about it... :D
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Alexis Agahi <al...@users.sf.net>.
On Friday 17 October 2003 12:35, Leo Simons wrote:
> Stephen McConnell wrote:
> > Recent updates to the Merlin platform in CVS include support for
> > auto-decomissioning of components that are no longer referenced.
> > The following log is a very simple demonstration testcase that
> > creates a bunch of non-referenced components, invokes the garbage
> > collector, and logs the resulting component decommissioning by
> > Merlin.
>
> what about 'active' components that are not referenced? Like a socket
> server?
as long as there is a reference on the component object, I suppose that GC
wont call finalize method (that would probably call component dispose)
lots of supposition here ;))
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 22 October 2003 00:29, Leo Simons wrote:
> - LSD, who wonders where he descended to the level of the mere mortal
> single threaded programmer >:)
Maybe when he started with LSD ;o)
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Niclas Hedhman wrote:
>
>>> Yes, the thread management references the thread, but I think that's
>>> (allowed to be) a weak reference.
>>
>>
>> Guys, I thought you were better at Java than this. ;o)
>
>
> me too :D
>
> well, that's settled then!
>
> - LSD, who wonders where he descended to the level of the mere mortal
> single threaded programmer >:)
ROTFLAICGU
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Leo Simons <le...@apache.org>.
Niclas Hedhman wrote:
>>Yes, the thread management references the thread, but I think that's
>>(allowed to be) a weak reference.
>
> Guys, I thought you were better at Java than this. ;o)
me too :D
well, that's settled then!
- LSD, who wonders where he descended to the level of the mere mortal
single threaded programmer >:)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [merlin] auto-decommissioning
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
>
> Guys, I thought you were better at Java than this. ;o)
Ok, well, it is settled then: I 5uXx0rZ && I 4m 0wNz0r3d.
> ThreadGroup
Yep, that would keep threads from getting GC'd.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 18 October 2003 21:07, Leo Simons wrote:
> Niclas Hedhman wrote:
> > I'm not into politics, but please explain why a "Socket Server" should
> > hang around in memory if it is not referenced?
> >
> > IIUIC, a socket server will be listening on a socket, i.e. the thread is
> > blocked, and the thread management will maintain the reference to its
> > Runnable entry and GC will not mark it as "garbage". No?
>
> I doubt that's guaranteed....
>
> class MyServer
> {
> initialize()
> {
> new Thread( new Runnable { /*...*/ } ).start();
> }
> }
>
> nothing references the thread, only the thread references the runnable,
> only the runnable references the socket, nothing references myserver.
>
> Yes, the thread management references the thread, but I think that's
> (allowed to be) a weak reference.
Guys, I thought you were better at Java than this. ;o)
Not only does ThreadGroup keeps track of which threads exists, but look up the
setDaemon method to see the difference...
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Thread.html#setDaemon(boolean)
<quote>
Marks this thread as either a daemon thread or a user thread. The Java Virtual
Machine exits when the only threads running are all daemon threads.
</quote>
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>On Saturday 18 October 2003 00:37, Stephen McConnell wrote:
>
>
>>An active component such as a socket server would declare a CONSERVATIVE
>>policy.
>>
>>
>
>I'm not into politics, but please explain why a "Socket Server" should hang
>around in memory if it is not referenced?
>
>
I was about to say that it may not be referenced internally, but its
deployment enabled external reference on sockets.
>IIUIC, a socket server will be listening on a socket, i.e. the thread is
>blocked, and the thread management will maintain the reference to its
>Runnable entry and GC will not mark it as "garbage". No?
>
I agree.
As long as the thread is executing it isn't a candidate for collection.
Stephen.
>
>Niclas
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Niclas Hedhman wrote:
>
>> I'm not into politics, but please explain why a "Socket Server"
>> should hang around in memory if it is not referenced?
>>
>> IIUIC, a socket server will be listening on a socket, i.e. the thread
>> is blocked, and the thread management will maintain the reference to
>> its Runnable entry and GC will not mark it as "garbage". No?
>
>
> I doubt that's guaranteed....
>
> class MyServer
> {
> initialize()
> {
> new Thread( new Runnable { /*...*/ } ).start();
> }
> }
I just tested this and the results I'm getting are that the instance is
not GC'ed if a thread is runing.
>
>
> nothing references the thread, only the thread references the
> runnable, only the runnable references the socket, nothing references
> myserver.
>
> Yes, the thread management references the thread, but I think that's
> (allowed to be) a weak reference.
According to:
http://developer.java.sun.com/developer/Books/performance/performance2/appendixa.pdf
-------------
It’s important to note that not just any strong reference will hold an
object in
memory. These must be references that chain from a garbage collection
root. GC
roots are a special class of variable that includes
• Temporary variables on the stack (of any thread)
• Static variables (from any class)
• Special references from JNI native code
-------------
>
> Potentially unsafe. Icky. Depends on some JVM characterstic. It seems
> to me the "principle of too much magic" applies. Better to be
> conservative.
Another point of view .... If a component anywhere in a system
(including all components it aggregates) is subject to garbage
collection *and* a no collection handling is provided - then all of
these component will *not* be subject to the formal Avalon
decommissioining sequence. I.e. disposal will never be invoked. That's
potentially unsafe and icky.
>
>
> Now, I think its vital to have a setup that reclaims resources in
> long-running appservers, and I think this is a cool feature Steve's
> putting into place, but I'm weary of changing default policies. An
> assembler had better known darn well a component can be reclaimed and
> make a conscious choice to enable that (the lifecycle tags seem
> feasible for that).
I'm also concerned about default policies - don't want to screw up the
servers I'm running! What I have done is a bunch of tests the confirms
to me that objects with active threads don't become candidates for GC
(specifically - test results show that a component that creates a thread
without any internal variable will only become a candidate when the
thread ceases to execute and the component itself is not referenced).
I think the important questions are the default behaviours:
* when is a component deployed (subject to a lifestyle policy)
- on startup if a startup activation policy is defined
- on demand (the default)
* when is a component decommissioned (subject to lifestyle policy)
- on release (under developer control), or
- in accordance with a collection policy, or
- on jvm exit
As far as I can see - the primary issue concerns pooled objects. In this
scenario, there are two important factors. Firstly, a developer knows
when they are invoking frequent component aquisitions - and as such a
developer should actively release the aquired objects. But what if the
developer does not? In this scenario the responsibility falls on the
container to to declare to the lifestyle handler that the object is no
longer available (irrespective of any resettable marker). The pool can
then handle re-population by deploying a new instance as and when
required. Keeping in mind that this is only of concern within the
context of Merlin internals and given the more predictable behaviour of
assured decommissioning - I'm in favour of the approach. However - I
want to run some long term tests on some complex applications in order
to get a better feeling for the implications and emergent patterns that
fall out of this.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Leo Simons <le...@apache.org>.
Niclas Hedhman wrote:
> I'm not into politics, but please explain why a "Socket Server" should hang
> around in memory if it is not referenced?
>
> IIUIC, a socket server will be listening on a socket, i.e. the thread is
> blocked, and the thread management will maintain the reference to its
> Runnable entry and GC will not mark it as "garbage". No?
I doubt that's guaranteed....
class MyServer
{
initialize()
{
new Thread( new Runnable { /*...*/ } ).start();
}
}
nothing references the thread, only the thread references the runnable,
only the runnable references the socket, nothing references myserver.
Yes, the thread management references the thread, but I think that's
(allowed to be) a weak reference.
Potentially unsafe. Icky. Depends on some JVM characterstic. It seems to
me the "principle of too much magic" applies. Better to be conservative.
Now, I think its vital to have a setup that reclaims resources in
long-running appservers, and I think this is a cool feature Steve's
putting into place, but I'm weary of changing default policies. An
assembler had better known darn well a component can be reclaimed and
make a conscious choice to enable that (the lifecycle tags seem feasible
for that).
cheers!
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [merlin] auto-decommissioning
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
>
> On Saturday 18 October 2003 00:37, Stephen McConnell wrote:
> > An active component such as a socket server would declare a
> > CONSERVATIVE policy.
>
> I'm not into politics, but please explain why a "Socket
> Server" should hang
> around in memory if it is not referenced?
>
> IIUIC, a socket server will be listening on a socket, i.e.
> the thread is
> blocked, and the thread management will maintain the reference to its
> Runnable entry and GC will not mark it as "garbage". No?
>
> Niclas
If the worker thread is only referenced by the server, the thread
itself is garbage and may end up reclaimed. Hilarity ensues in the
uncontrolled shutdown.
However, this assumes that the container only uses soft or weak
references to its component instances - otherwise the server will
not be GC'd until the container is GC'd.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 18 October 2003 00:37, Stephen McConnell wrote:
> An active component such as a socket server would declare a CONSERVATIVE
> policy.
I'm not into politics, but please explain why a "Socket Server" should hang
around in memory if it is not referenced?
IIUIC, a socket server will be listening on a socket, i.e. the thread is
blocked, and the thread management will maintain the reference to its
Runnable entry and GC will not mark it as "garbage". No?
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [merlin] auto-decommissioning
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Thank God we ditched the name Übercontainer.
/LS
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Stephen McConnell wrote:
> > Three policies are defined LIBERAL, DEMOCRAT, and CONSERVATIVE.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> Three policies are defined LIBERAL, DEMOCRAT, and CONSERVATIVE.
Hmm. Politics in OSS design? In reality then, DEMOCRAT == LIBERAL.
We could go farther and say REPUBLICAN == CONSERVATIVE. Then we can
add one more to confuse matters worse and say that
COMMUNIST == LIBERAL CONSERVATIVE.
;P
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
>> Recent updates to the Merlin platform in CVS include support for
>> auto-decomissioning of components that are no longer referenced.
>> The following log is a very simple demonstration testcase that
>> creates a bunch of non-referenced components, invokes the garbage
>> collector, and logs the resulting component decommissioning by
>> Merlin.
>
>
> what about 'active' components that are not referenced? Like a socket
> server?
Three policies are defined LIBERAL, DEMOCRAT, and CONSERVATIVE.
* A LIBERAL component will be decommissioned when there are no
references to the component
* A DEMOCRAT component will stick around even if there are no
references, except if there is memory contentention in which
case it will be decommission in order to avoid an OutOfMemory
condition
* A CONSERVATIVE component is just plain stubborn - it will
stay around even if that means memory contention and probably
failure of the system.
An active component such as a socket server would declare a CONSERVATIVE
policy.
Cheers, Steve.
>
>
> - LSD
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> Recent updates to the Merlin platform in CVS include support for
> auto-decomissioning of components that are no longer referenced.
> The following log is a very simple demonstration testcase that
> creates a bunch of non-referenced components, invokes the garbage
> collector, and logs the resulting component decommissioning by
> Merlin.
what about 'active' components that are not referenced? Like a socket
server?
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Stephen McConnell <mc...@apache.org>.
Alexis Agahi wrote:
>On Thursday 16 October 2003 21:43, Stephen McConnell wrote:
>
>
>>Recent updates to the Merlin platform in CVS include support for
>>auto-decomissioning of components that are no longer referenced.
>>The following log is a very simple demonstration testcase that
>>creates a bunch of non-referenced components, invokes the garbage
>>collector, and logs the resulting component decommissioning by
>>Merlin.
>>
>> [junit] Running playground.StandardTestCase
>> INFO ] (testcase): Creating a bunch of hello instance
>> INFO ] (template.hello): initialization as: 6829042
>> INFO ] (template.hello): initialization as: 26030331
>> INFO ] (template.hello): initialization as: 9089167
>> INFO ] (template.hello): initialization as: 21860890
>> INFO ] (template.hello): initialization as: 28517927
>> INFO ] (testcase): running gc
>> INFO ] (template.hello): disposal: 6829042
>> INFO ] (template.hello): disposal: 26030331
>> INFO ] (template.hello): disposal: 9089167
>> INFO ] (template.hello): disposal: 21860890
>> INFO ] (template.hello): disposal: 28517927
>> INFO ] (testcase): gc done
>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.109 sec
>>
>>Note that this is achieved *without* invoking release( object ).
>>
>>Am now looking into achiving the same thing with pooled objectes.
>>
>>
>
>this is a *really* cool feature! I would qualify it as a quatum leap in merlin
>component manager history :))
>
LOL - I thought you would like it!
>thx a lot steve.
>For some applications, it was really hard to invoke the release using the
>appropriate service manager. Having such feature will simplify a lot.
>
>
Yep.
>Does this means that you should set as deprecated the "release" method of
>service manager, since explicite release is not required any more?
>
Theoretically - yes - providing I sort out an equivalent strategy with
respect to pooled objects. The only thing I really need to do is to
check if a component is reclaimable in which case it gets recommissioned
and posted back to the pool, otherwise it gets decommissioned. The
immediate issue concerns a pool implementation the leveragers the meta
model. I'm going over the excalibur mpool stuff at the moment and
trying to figure out if I should be reusing this or not. Current
thinking is that I would need to take the concepts and reimpliment under
the composition and activation packages in a way that leverages the meta
model and activation context.
Stephen.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] auto-decommissioning
Posted by Alexis Agahi <al...@users.sf.net>.
On Thursday 16 October 2003 21:43, Stephen McConnell wrote:
> Recent updates to the Merlin platform in CVS include support for
> auto-decomissioning of components that are no longer referenced.
> The following log is a very simple demonstration testcase that
> creates a bunch of non-referenced components, invokes the garbage
> collector, and logs the resulting component decommissioning by
> Merlin.
>
> [junit] Running playground.StandardTestCase
> INFO ] (testcase): Creating a bunch of hello instance
> INFO ] (template.hello): initialization as: 6829042
> INFO ] (template.hello): initialization as: 26030331
> INFO ] (template.hello): initialization as: 9089167
> INFO ] (template.hello): initialization as: 21860890
> INFO ] (template.hello): initialization as: 28517927
> INFO ] (testcase): running gc
> INFO ] (template.hello): disposal: 6829042
> INFO ] (template.hello): disposal: 26030331
> INFO ] (template.hello): disposal: 9089167
> INFO ] (template.hello): disposal: 21860890
> INFO ] (template.hello): disposal: 28517927
> INFO ] (testcase): gc done
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.109 sec
>
> Note that this is achieved *without* invoking release( object ).
>
> Am now looking into achiving the same thing with pooled objectes.
this is a *really* cool feature! I would qualify it as a quatum leap in merlin
component manager history :))
thx a lot steve.
For some applications, it was really hard to invoke the release using the
appropriate service manager. Having such feature will simplify a lot.
Does this means that you should set as deprecated the "release" method of
service manager, since explicite release is not required any more?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org