Server-Shutdown and TimerService

[ahs1]

Hello,

i think that there might be an "undesired feature" in the ServerImpl class.

While testing the TimerService, inoticed, that on a shutdown, Timers are removed from the backup store.
The reason is the "undeployment" at shutdown, which correctly terminates the registerd Timer.
I tried the "exitOnShutdown"-setting which is ignored by the System, as the Server registers itself on startup in the Runtime as shutdownhook.

When a shutdown is requested it tries to skip the shutdown and just exits.

Unfortuantely the shutdownhook is now jumping in.

There was code in SeverImpl to avoid this but this has been removed by the "merging of 3.2" on file version 1.39.

So is this a bug or a feature?

[frintrop]

Can you elaborate on this native IO feature? what does it handle specifically? file access? network access?

thanks

[starksm64]

Its an issue with the ejb timer service, not the ServerImpl class. Its no different than an entity bean. There needs to be a configuration option that indicates whether undeployment of the ejb should remove the timer or leave it persisted.

Beyond that we would need another lifecycle event to differentiate a shutdown from an undeployment.

[starksm64]

Reviewing the ejb 2.1 spec, the only persistence guarentee for timers is that a server crash will not remove them. It does not say anything about timers needing to be persisted across normal shutdowns, even for entity beans. I think this could be a useful feature, but its not something that is defined by the spec.

[ahs1]

hmmmmm,

i don't agree!

As the TimerService is meant for i.e. "Workflow" the TimeOut events might be VERY important to the workflow.

If someone has to shutdown the app-server (say for some hardware maintainance) there would be no other way as to "crash" the app-server to shut down the server ???

And what is then the point of having the "exitOnShutdown" setting.

A "normal" shutdown of an app-server is realy NOT an undeployment.
Within JBoss this may have not caused problems before, but with the TimerService-handling is one now. (I have not (yet) tested this behaviour in a clustered environment)

So i think this is more a bug then a feature!

[starksm64]

Since we have never had a notion of a shutdown lifecycle event as opposed to an undeployment, I can't see how this can be classified as a bug in the existing shutdown behavior. The ability for timers to survive the shutdown of the server is a persistence characteristic that needs to be supported by the timer service independent of the service lifecyle or ejb deployment. You may well want existing timers to continue to exist when the application is undeployed and then redeployed for an upgrade.

[ahs1]

Sorry to "fight for my point of view" on this matter...

I agree that it might be usefull to have Timer persisted even across deployment/undeployment, but this is something the spec does not impose. If i recall it correctly it says "Timers should be undeplyed if the associated Bean is undeploeyed, or if the Entity is removed".

I agree that the way Jboss handles Startup and Shutdown as Deploy/Undeploy is an elegant way to do it, but here we now have a behaviour, that renders Timers (with this limitation) more or less useless for "important" events on the beans.

And again, what is the use of "exitOnShutdown" (which defaults to true) if not to prevent this kind of "sidefects" of an "Jboss-shutdown".

There is no problem with "redeploying" on startup as long as the "shutdown" leaves the persisted Timers alone.

And, thanks for the quick reply!

[starksm64]

And coupling not executing all shutdown handlers on server exit just to get ejb timers to to not be thrown away makes no sense to me. Again the problem is with control of the ejb timers persistence which needs to be handled at the ejb deployment level.

[pittala]

Hi,
How to use the timer service? As per the spec, the timers should be cancelled across undeployments and should be persisted across server shutdowns. This calls for server shutdown to be handled separately and should not be mixed with undeployment. This behavior is not seen in JBOSS, which requires us to persist the timers by ourselves, devoiding us the benefits of the EJBTimers...

Thanks,
Srini

[jraymond]

Scott, let me ask... do we remove all Entities from the database when we shutdown/undeploy? Then why would we remove all timers associated with an entity from the database when the timer is undeployed?

For other EJBs I can see where the could be ambiguity, but not when dealing with Entities.

-- Jayson

Jayson Raymond,
Chair, Seattle Java Users Group

[starksm64]

There is nothing in the spec that says timers associated with entity beans have different persistence characteristics than any other bean type with the exception that such timers must be removed when the entity is removed. Vote for the following feature request if you want truly persistent timers.

http://jira.jboss.com/jira/browse/JBAS-1091

[beffe]

Hello,

i haven't read the spec, but i read Sun's J2EE 1.4 Tutorial and it says:

Timers are persistent. If the server is shut down (or even crashes), timers are saved and will become active again when the server is restarted. If a timer expires while the server is down, the container will call ejbTimeout when the server is restarted.

My application has a stateless session bean with a business method for creating an interval timer. If once created, i would never expect the timer to die. But in my case (JBoss 4.0.2) the timer doesn't survive a normal shutdown.

When i kill jboss, the timer seems to survice, but on startup i get the following error:

10:04:39,297 ERROR [GeneralPurposeDatabasePersistencePlugin] Cannot deserialize
java.lang.ClassNotFoundException: No ClassLoaders found for: my.package.ejb.TimerInfo
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:198)
at .........

Jboss activates my timer but cannot find the class for the info object that i passed during creation of the timer.
The timer now runs, but calling getInfo() returns null. That's also really bad.

Another thing i noticed is that my timer does not perfom any "catch up" calls to my ejbTimeout()-Method, that should have happend during downtime.

In my opinion, the EJB Timer framework has one and only one major advantage over other frameworks like Quartz - that is persitence.

Best regards,
Beffe

[beffe]

I tried to come around the problem with my custom info class by using a String instead.
Now i don't get the error during startup and the timer resumes.

But here is another strange behaviour:
When i check for associated timers with TimerService.getTimers() from within the init method of a startup servlet (it is in the same ear as the timed bean), the collection is empty - i cannot get a reference to the associated timer at this point.
But the same check works from within a service method of the servlet.

Whats wrong here? (In my application.xml the ejb module is before the war module)

The problem is, i want to check at application startup if a timer exists and if there has changed something in its configuration for interval and timepoint, and if so install a new one.
With JBoss 4.0.2 this seems to be impossible :-(

Regards,
Beffe