In the discussion thread for this issue (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73652), I'd said that for 4.0.4 I would:
1) Adapt RetryInterceptor so it can make use of o.jboss.naming.NamingContextFactory's ability to cache the naming env properties in a ThreadLocal. 2) Create a SingleRetryInterceptor that would make only a single attempt to re-lookup the invoker. This would be useful in the JBAS-1476 situation where an out-of-date EJB proxy invalidates the FamilyClusterInfo, or in any situation where a cached EJB proxy is held throughout a cluster restart and then reused. It wouldn't help if the cached proxy is used before the cluster has restarted; the regular RetryInterceptor would be needed for this. 3) Add the new SingleRetryInterceptor to the default clustered bean configs in standardjboss.xml. Items 1 and 2 were done for 4.0.4.RC1. #3 should have been, but wasn't, which is my fault. It will be in the GA. I'll be adding a wiki entry for the above late this week after JBossCache 1.3.0.Alpha1 is out. RetryInterceptor can now also easily be subclassed to add an arbitrary number of retries that is appropriate for the client application (e.g. retry once a second for 30 seconds, then fail.) - Brian [EMAIL PROTECTED] wrote: > On Sat, 2006-02-18 at 04:58, Adrian Brock wrote: >> On Fri, 2006-02-17 at 15:34, Scott M Stark wrote: >>> These two issues currently assigned to Tim: >>> http://jira.jboss.com/jira/browse/JBAS-1434 >>> http://jira.jboss.com/jira/browse/JBMESSAGING-170 >> >> I hope so. The purpose of giving them to someone else was that I >> didn't have time to do it, and they are something that could be done >> by anybody. >> >> They have been progressively pushed back since 4.0.0 > > I'd prefer to find the time to write these tests myself then > we can move the JMSContainerInvoker with its practically > unoverridable implementation to legacy. > > This would also be one less thing to worry about for EJB3 integration. > Which I see you also moved to 4.0.5. > > In my opionion this is a mistake. If you keep pushing these > things back, people just learn to ignore it knowing that if > they leave it long it enough it will be keep getting deferred > to the next release. > > e.g. The "critical" clustering issue that has been hanging around for > months: http://jira.jboss.com/jira/browse/JBAS-1476 > I hope this isn't going to get pushed back as well. > > These critical issues should really be done in the next > availble release candidate, not done at the last minute for > the GA release. [EMAIL PROTECTED] wrote: > Regarding to JBAS-1476, it is critical althoguh it is a > corner case, IMHO. You are right, we can't push it back > forever. I am meeting with Bela this week. We will discuss it then. > > Thanks, > > -Ben ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
