portals-pluto-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: releasing factory objects
Date Fri, 09 Jan 2004 01:49:00 GMT

On Thursday, January 8, 2004, at 01:50  AM, Stefan Hepper wrote:

> Hi David,
> thanks for adding all the javadocs.
>
np

> I'm not quite sure what you want to achieve with the pooling. Pooling 
> of Java objs is in principle a bad thing to do IMHO. This is the job 
> of the Java VM. True that the 1.3 VM does not the best job in its 
> efficiency to create and GC objects, but the 1.4 VM is much better 
> (another thing is pooling of resources, like DB connections). When 
> re-implementing GC and pooling on a higher level you loose all the 
> benefits that will come with new VM implementations. In addition to 
> that it makes the code much more complex, as you now need to manage 
> the obj lifecycles.
>
> As the releasePortletInvoker method is empty in your implementation 
> I'm not sure why we would need it.
>
Jetspeed implements its own invokers, where the object is returned to 
the pool

> Are there any other reasons besides pooling for having these 
> get/release pairs?

For me its strictly for managing objects that are created at a very 
high rate.
But there may be other uses too

> If they are only there to introduce java object pooling I'm against 
> it, because efficient object creation and GC is the job of the VM.
>
 From my experience object pooling or recycling is not only more 
performant, it can also help keep the GC overhead to a minimum.
I've done metrics on this in other projects, and pooling has been very 
helpful in keeping memory usage and garbage collection to a minimal.

In Jetspeed we are using Commons Pooling:

http://jakarta.apache.org/commons/pool/

While working on another server project, we did metrics based on 
Bulka's 'Java Performance and Scalability' book, chapter 6
The results were positive and led to us using Commons pooling

I'd like to hear from other committers
There is the second possibility to clean up during the 
PortletContainerService.release (pushes more logic back onto the portal)

David

> Stefan
>
>
> David Sean Taylor wrote:
>
>> I added a releasePortletInvoker method to the PortletInvokerFactory 
>> (and static accesor)
>> The Pluto container now calls a matching release for every get on 
>> portlet invoker
>> This pattern will allow portals to better manage (and possibly pool) 
>> all factory objects in Pluto
>> Such as invokers, action request, action response, render request, 
>> render response.
>> If no one objects, or if there isn't a better solution, then I will 
>> do the same for the other factory objects.
>> I have seen where the container calls 
>> PortletContainerServices.release.
>> We could also tie in here, but I'd need to keep a stack of managed 
>> factory objects in my portal.
>> That can work too, but I thought this would be clearer, having a 
>> matching get and release method for ex
>> getRenderResponse, releaseRenderResponse
>> As Mete as pointed out on the Pluto User list, pooling can greatly 
>> help with memory management on large portals
>> In Jetspeed we have started using Commons pooling. I have added no 
>> pooling to the Pluto container itself, just the release,
>> and only on the invokers thus far
>> Also, I've started documenting the required factories and their 
>> factory objects in the Pluto javadocs and in Jetspeed.
>> This should help portal developers understand the required factory 
>> interfaces and possibly lead towards standardization
>
>




Mime
View raw message