-
1. Re: j2ee version
tom.baeyens Mar 28, 2008 4:23 AM (in response to aguizar)Well spotted !
This is unintentional. We target only J2EE 1.4 and higher. -
2. Re: j2ee version
mvaldes Mar 28, 2008 1:38 PM (in response to aguizar)Definitely agree, 1.3 is out of scope !
BTW, are there any difference concerning the timer service between 1.4 and latest 1.5 ?
Would be great to know the jboss position on 1.5 support ? seems like your first target is 1.4 ?
thanks,
Miguel Valdes -
3. Re: j2ee version
tom.baeyens Mar 28, 2008 3:39 PM (in response to aguizar)first target is ejb 2.1 and related j2ee 1.4 versions.
cause all ejb3 containers also support ejb2.
so developing those session implementations in terms of ejb2 will make sure we can run on the most possible platforms. -
4. Re: j2ee version
koen.aers Mar 29, 2008 2:00 PM (in response to aguizar)Last week while I was at a customer for some consulting they mentioned problems with the 'unclusterability' of the ejb timers on some appservers. Is that issue being addressed in the PVM?
Regards,
Koen -
5. Re: j2ee version
tom.baeyens Mar 30, 2008 6:41 AM (in response to aguizar)i'm not aware of this issue.
can you elaborate or let the customer elaborate. -
6. Re: j2ee version
koen.aers Mar 31, 2008 4:28 AM (in response to aguizar)Apparently EJB timers are not necessarily clusterable according to the specification. On some appservers (e.g. JBoss AS, Weblogic) the timer would be specific to the node where it is created. If this node goes down, the timer will not execute. On other appservers (e.g. Websphere) the timer is replicated to the other nodes of the cluster so that when one of the nodes goes down the timer still is triggered.
This is the description of the problem by the customer but maybe it is a simple user problem. I didn't know enough about the specification and I certainly don't know enough about the particular appservers to be sure of this statement. Maybe someone else in this forum does.
Regards,
Koen -
7. Re: j2ee version
tom.baeyens Mar 31, 2008 5:28 AM (in response to aguizar)... that means that our own timer impl is better then the jboss one ?!
cool! :-) -
8. Re: j2ee version
koen.aers Mar 31, 2008 5:40 AM (in response to aguizar)Don't cheer too quickly. They mentioned problems with that one as well (but again, I didn't verify).
The problem was that the name of the timer includes somehow the name and/or IP address of the node on which it is created. So it didn't work in a clustered way neither. But they didn't show me a hard proof on this.
Regards,
Koen -
9. Re: j2ee version
aguizar Mar 31, 2008 7:16 PM (in response to aguizar)Clustering/failover is an aspect left to the EJB container. No component in the EJB spec is required to be clusterable. That is an area where vendors are expected to compete.
The spec does require the container to recover timers upon restart. From EJB 2.1 section 22.4.2:Timers are persistent objects. In the event of a container crash, any single-event timers that have expired during the intervening time before container restart must cause the ejbTimeout method to be invoked upon restart.
Knowing that support for timer clustering is not uniform across app servers is great input. I wonder what would be a better investment: to work around it in the product or contribute to the EJB timer implementation in JBoss AS. In any case, both can wait until there is enough demand for the feature. -
10. Re: j2ee version
koen.aers Apr 1, 2008 4:32 AM (in response to aguizar)"alex.guizar@jboss.com" wrote:
Knowing that support for timer clustering is not uniform across app servers is great input. I wonder what would be a better investment: to work around it in the product or contribute to the EJB timer implementation in JBoss AS.
I think for this particular customer the first way would probably be a better solution because they are deploying on multiple appservers. But for the JBoss AS integration, the second solution is of course better.
Regards,
Koen