I think the problem is that runFullUpdate() calls another EJB which
throws an exception. GF wraps this exception in an
javax.ejb.EJBTransactionRolledbackException. Because of this exception
GF expunges the timer.
I think this is against the EJB specification. The specification states
only in section "18.2.5.3 Timeout Callback Method Requirements":
"Timeout callback methods must not throw application exceptions."
In my personal opinion the timeout callback method must be independend
of exceptions thrown during the method call if no exception is thrown by
the method itself.
How should I write a stable service if an exception somethere else
thrown and catched causes my timer to be expunged?
Should I open an issue with an example for this problem?
Best,
Oliver
Am 06.08.13 13:55, schrieb Oliver B. Fischer:
> No, not at all. I simply log the message. That's all. Strange...
>
> Am 06.08.13 13:52, schrieb Lachezar Dobrev:
>> Did the 'catch' code crash?
>>
>> 2013/8/6 Oliver B. Fischer <mailsink_at_swe-blog.net>:
>>> Hi,
>>>
>>> I have a timeout callback method in a singleton which starts every
>>> minute:
>>>
>>> @Schedule(hour = "*", minute = "*", timezone = "UTC",
>>> persistent = false, info = "InitialESSyncTimer")
>>> protected void triggerFullUpdateAfterApplicationStart()
>>> {
>>> try {
>>> runFullUpdate();
>>> }
>>> catch (RuntimeException e) {
>>> ...
>>> }
>>> }
>>>
>>> This method is always expunged by GlassFish on every occurence of
>>> RuntimeException? But why? I catch every exception. Actually the
>>> container
>>> is only allowed to expunge a timer if the callback method throws an
>>> exception.
>>>
>>> What did I miss?
>>>
>>> Best,
>>>
>>> Oliver