Using the Timer Service (in Geronimo)

["Jay D. McHugh" <ja...@gmail.com>]

Hello all,

I have a chain of stateless session beans that are being triggered by
the timer service in Geronimo.

But, even though they are being created with single expirations - they
do not seem to be getting destroyed until the entire chain finishes.

For clarity here is what I mean by chain:

Timer1 creates a timer object for Timer2 with a single expiration.
Timer2 creates a timer object for Timer3 with a single expiration.
.
.
.
TimerX creates a timer object for TimerY with a single expiration.

Each successive timer is created as the '@Timeout' method of its
'parent' is finishing with an expiration date/time one minute in the future.

Each of the timers is performing some pretty intense data cleansing
work.  So, there is a lot of memory getting allocated at each step.  So
much so that even with no other activity going on, the server often
crashes (runs out of memory or becomes unable to make new database
connections) before it is able to get to the end of the chain.

I added a 'finalize' method and a '@PreDestroy' method for each of the
timers and none of them have been called yet even though fourteen timers
have run and printed out a message to the console indicating that the
'timeout' method has gotten to the end.

Actually, I just got a heap space error and finally one of the classes
got finalized (two now) but it looks like that is probably all that will
finish 'cleanly'.

Is there a way to nudge those classes so that they finalize?

I suspect that the only reason that these to did is because of the heap
space errors.

Any hints?

Thanks,

Jay

Re: Using the Timer Service (in Geronimo)

[Dain Sundstrom <da...@iq80.com>]

On Aug 29, 2008, at 4:43 PM, Jay D. McHugh wrote:

> Dain,
>
> Looks like getting rid of all of my global level variable and nulling
> them out once I was done with them allowed enough objects to be  
> garbage
> collected.
>
> As an extra (and perhaps unneccessary) step, I removed all of the
> injected EJBs and switched to looking them up myself in JNDI.  I did
> that because I wasn't sure whether I would be able to null out  
> injected
> beans (and still have them re-injected later).

You don't need to do that.  An EJB reference effectively only contains  
the unique name of the EJB (its id) and specifically doesn't have a  
reference to any EJB instances.

> Should they be re-injected automatically later?

No, injection only happens once.

> If they are supposed to be, then I will go ahead and switch back to
> using injection.  If they are not, then I will just leave them alone.

Switch back; you will be much happier.

-dain

Re: Using the Timer Service (in Geronimo)

["Jay D. McHugh" <ja...@jnwd.net>]

Dain,

Looks like getting rid of all of my global level variable and nulling
them out once I was done with them allowed enough objects to be garbage
collected.

As an extra (and perhaps unneccessary) step, I removed all of the
injected EJBs and switched to looking them up myself in JNDI.  I did
that because I wasn't sure whether I would be able to null out injected
beans (and still have them re-injected later).

Should they be re-injected automatically later?

If they are supposed to be, then I will go ahead and switch back to
using injection.  If they are not, then I will just leave them alone.

Thanks,


Jay

Jay D. McHugh wrote:
> Thanks Dain,
> 
> I'll try that.
> 
> Jay
> 
> Dain Sundstrom wrote:
>> On Aug 28, 2008, at 10:13 PM, Jay D. McHugh wrote:
>>
>>> Hello all,
>>>
>>> I have a chain of stateless session beans that are being triggered by
>>> the timer service in Geronimo.
>>>
>>> But, even though they are being created with single expirations - they
>>> do not seem to be getting destroyed until the entire chain finishes.
>>>
>>> For clarity here is what I mean by chain:
>>>
>>> Timer1 creates a timer object for Timer2 with a single expiration.
>>> Timer2 creates a timer object for Timer3 with a single expiration.
>>> .
>>> .
>>> .
>>> TimerX creates a timer object for TimerY with a single expiration.
>>>
>>> Each successive timer is created as the '@Timeout' method of its
>>> 'parent' is finishing with an expiration date/time one minute in the
>>> future.
>>>
>>> Each of the timers is performing some pretty intense data cleansing
>>> work.  So, there is a lot of memory getting allocated at each step.  So
>>> much so that even with no other activity going on, the server often
>>> crashes (runs out of memory or becomes unable to make new database
>>> connections) before it is able to get to the end of the chain.
>>>
>>> I added a 'finalize' method and a '@PreDestroy' method for each of the
>>> timers and none of them have been called yet even though fourteen timers
>>> have run and printed out a message to the console indicating that the
>>> 'timeout' method has gotten to the end.
>>>
>>> Actually, I just got a heap space error and finally one of the classes
>>> got finalized (two now) but it looks like that is probably all that will
>>> finish 'cleanly'.
>>>
>>> Is there a way to nudge those classes so that they finalize?
>> Which instance do you want to be destroyed?  If you mean the stateless
>> bean, they are pooled and typically only destroyed when VM shutdown. 
>> You can disable the pool by setting PoolSize to 0 in which case a new
>> instance will be created and destroyed for each method invocation. 
>> Stateless EJB creation and destruction is not a particularly expensive
>> process unless your bean is doing a lot of work in the create/destroy
>> callbacks.
>>
>> Alternatively, you could null out all of your fields before the timer
>> method exits (or even better as soon as you are done with the data). 
>> This is the most portable way to handle this.
>>
>> -dain
>>
>>
> 
> 
> 

Re: Using the Timer Service (in Geronimo)

["Jay D. McHugh" <ja...@jnwd.net>]

Thanks Dain,

I'll try that.

Jay

Dain Sundstrom wrote:
> On Aug 28, 2008, at 10:13 PM, Jay D. McHugh wrote:
> 
>> Hello all,
>>
>> I have a chain of stateless session beans that are being triggered by
>> the timer service in Geronimo.
>>
>> But, even though they are being created with single expirations - they
>> do not seem to be getting destroyed until the entire chain finishes.
>>
>> For clarity here is what I mean by chain:
>>
>> Timer1 creates a timer object for Timer2 with a single expiration.
>> Timer2 creates a timer object for Timer3 with a single expiration.
>> .
>> .
>> .
>> TimerX creates a timer object for TimerY with a single expiration.
>>
>> Each successive timer is created as the '@Timeout' method of its
>> 'parent' is finishing with an expiration date/time one minute in the
>> future.
>>
>> Each of the timers is performing some pretty intense data cleansing
>> work.  So, there is a lot of memory getting allocated at each step.  So
>> much so that even with no other activity going on, the server often
>> crashes (runs out of memory or becomes unable to make new database
>> connections) before it is able to get to the end of the chain.
>>
>> I added a 'finalize' method and a '@PreDestroy' method for each of the
>> timers and none of them have been called yet even though fourteen timers
>> have run and printed out a message to the console indicating that the
>> 'timeout' method has gotten to the end.
>>
>> Actually, I just got a heap space error and finally one of the classes
>> got finalized (two now) but it looks like that is probably all that will
>> finish 'cleanly'.
>>
>> Is there a way to nudge those classes so that they finalize?
> 
> Which instance do you want to be destroyed?  If you mean the stateless
> bean, they are pooled and typically only destroyed when VM shutdown. 
> You can disable the pool by setting PoolSize to 0 in which case a new
> instance will be created and destroyed for each method invocation. 
> Stateless EJB creation and destruction is not a particularly expensive
> process unless your bean is doing a lot of work in the create/destroy
> callbacks.
> 
> Alternatively, you could null out all of your fields before the timer
> method exits (or even better as soon as you are done with the data). 
> This is the most portable way to handle this.
> 
> -dain
> 
> 

Re: Using the Timer Service (in Geronimo)

[Dain Sundstrom <da...@iq80.com>]

On Aug 28, 2008, at 10:13 PM, Jay D. McHugh wrote:

> Hello all,
>
> I have a chain of stateless session beans that are being triggered by
> the timer service in Geronimo.
>
> But, even though they are being created with single expirations - they
> do not seem to be getting destroyed until the entire chain finishes.
>
> For clarity here is what I mean by chain:
>
> Timer1 creates a timer object for Timer2 with a single expiration.
> Timer2 creates a timer object for Timer3 with a single expiration.
> .
> .
> .
> TimerX creates a timer object for TimerY with a single expiration.
>
> Each successive timer is created as the '@Timeout' method of its
> 'parent' is finishing with an expiration date/time one minute in the  
> future.
>
> Each of the timers is performing some pretty intense data cleansing
> work.  So, there is a lot of memory getting allocated at each step.   
> So
> much so that even with no other activity going on, the server often
> crashes (runs out of memory or becomes unable to make new database
> connections) before it is able to get to the end of the chain.
>
> I added a 'finalize' method and a '@PreDestroy' method for each of the
> timers and none of them have been called yet even though fourteen  
> timers
> have run and printed out a message to the console indicating that the
> 'timeout' method has gotten to the end.
>
> Actually, I just got a heap space error and finally one of the classes
> got finalized (two now) but it looks like that is probably all that  
> will
> finish 'cleanly'.
>
> Is there a way to nudge those classes so that they finalize?

Which instance do you want to be destroyed?  If you mean the stateless  
bean, they are pooled and typically only destroyed when VM shutdown.   
You can disable the pool by setting PoolSize to 0 in which case a new  
instance will be created and destroyed for each method invocation.   
Stateless EJB creation and destruction is not a particularly expensive  
process unless your bean is doing a lot of work in the create/destroy  
callbacks.

Alternatively, you could null out all of your fields before the timer  
method exits (or even better as soon as you are done with the data).   
This is the most portable way to handle this.

-dain