Thanks for filing the issues. GF always assumed that if the timeout
fails repeatedly, it's a bad timeout and the timer should be removed.
May be it wasn't very practical ;).
It would be the best for the EJB spec to define the correct behavior.
thanks,
-marina
On 8/7/13 2:35 PM, Oliver B. Fischer wrote:
> I created an JIRA issue for that:
> https://java.net/jira/browse/GLASSFISH-20749
>
> Both, Geronimo and JBoss, do no expunge the timer. I think this is the
> only way how the container should behave. Otherwise it is not possible
> to write stable services. Otherwise I have to restart the app server
> and this is not what I want.
>
> What do you think?
>
> Best,
>
> Oliver
>
> Am 06.08.13 20:26, schrieb Marina Vatkina:
>> GF retries once (you can change the setting to retry more times), but
>> after all retries failed, the timer is expunged. What does JBoss do? Try
>> again or just wait until the next timeout?
>>
>> -marina
>>
>> On 8/6/13 7:25 AM, Oliver B. Fischer wrote:
>>> I tried the same code with JBoss. JBoss does not expunge the timer.
>>>
>>> Am 06.08.13 16:15, schrieb Oliver B. Fischer:
>>>> 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?
>>>>
>>>>
>>