[jboss-jira] [JBoss JIRA] Commented: (JBAS-6346) Fallback Invoker Interceptor

[Galder Zamarreno (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBAS-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12444218#action_12444218 ] 

Galder Zamarreno commented on JBAS-6346:
----------------------------------------

It's been like that since day 1 of EJB3. IMO, it's a wise thing to do as it separates the load balancing work from the actual proxy implementation (Unified, JRMP, Pooled...etc). Problem is that the interceptor still lacks some of the stuff EJB2 had, such as failover denial under transaction: https://jira.jboss.org/jira/browse/EJBTHREE-1137. Whether that will get implemented or not depends on whether a fully distributed TM can be integrated for clustered invocation: https://jira.jboss.org/jira/browse/JBAS-5239.

> Fallback Invoker Interceptor
> ----------------------------
>
>                 Key: JBAS-6346
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6346
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Aspects, EJB3, Remoting
>    Affects Versions: JBossAS-4.2.3.GA, JBossAS-5.0.0.GA
>            Reporter: Andrew Oliver
>
> Presently to configure EJBs to be remotely accessible via a given set of protocols you must give them separate JNDI names.  In commercially distributed software where you have multiple configurations this is inconvenient.  Ideally there would be an interceptor  that takes the place of the InvokerRemoteInterceptor.java and retries the connection on a series of protocols.  The choice could then be saved in the proxy for "first use" next time.  This would be similar to the ClusterChooserInterceptor.java.   The server side configuration would show a InvokerLocator which is configured to a series of invoker Locator which is bound to a series of invokers.  The call would be retried once for each invoker dependent on failure type and then fail completely (in the worst case) or return the first successful invocation.
> This would allow "autoconfiguration" of the appserver for example using pure socket or HTTP invocation depending on the first success making the server easier to install in both IT and VAR/OEM environments.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira