releasing factory objects

[David Sean Taylor <da...@bluesunrise.com>]

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

Re: releasing factory objects

[Endre Stølsvik <En...@Stolsvik.com>]

On Thu, 8 Jan 2004, Paul Spencer wrote:

| David Sean Taylor wrote:
| 
| > 
| > 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)
| > 
| 
| +1 for Commons Pooling.  Look at the SoftReference pool.
| 
| The pooling can be hidden in the factory.  In addition the object can be 
| "retuned" to the factory via a method like returnObject().  At the point 
| when pooling is not needed, then returnObject() can be an empty method.

The point is that -the pooling itself- is often very slow - it will 
usually have to be a synchronized map or list or whatever - and synching 
is way slow - at least when you have contented synchs, which will happen 
all the time for objects that are used very often.

Creating a new object is very fast, at least with 1.4. With Sun's JVM in
1.3 and later, pooling of "simple java objects" is not more efficient than
simply doing new() - and with 1.4 (and most likely, all after!) it is
slower. Thus, pooling should only be done with complex objects, or objects
"attached" to "outside resources", e.g. LDAP or SQL connections - pooling
the java objects itself will -degrade- performance.

Btw: have anoyone had a look at the logging in Pluto and "driver"? It uses 
"map-based lookup" - it seems REALLY slow, at least on first glance. An 
class/object that wants to log, should fetch -a Logger-, and then log 
directly onto that object. In pluto, it seems like the Logger object is 
fetched "afresh" for each log-invocation - or I might be a bit cross-eyed.

Also, it could use a little more "trace" logging - nitty gritty details of 
what it's doing.

-- 
Mvh,
Endre Stølsvik               M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS         -  http://www.coretrek.com/
CoreTrek corporate portal / EIP -  http://www.corelets.com/

Re: releasing factory objects

[Paul Spencer <pa...@mindspring.com>]

David Sean Taylor wrote:

> 
> 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)
> 

+1 for Commons Pooling.  Look at the SoftReference pool.

The pooling can be hidden in the factory.  In addition the object can be 
"retuned" to the factory via a method like returnObject().  At the point 
when pooling is not needed, then returnObject() can be an empty method.



> David
> 
>> Stefan
 >>

Paul Spencer

Re: releasing factory objects

[David Sean Taylor <da...@bluesunrise.com>]

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
>
>

Re: releasing factory objects

[Stefan Hepper <st...@hursley.ibm.com>]

Hi David,
thanks for adding all the javadocs.

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.

Are there any other reasons besides pooling for having these get/release 
pairs?
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.

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
> 
>