[ https://issues.jboss.org/browse/AS7-3492?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-3492: --------------------------------------- The behavior you describe has always been the behavior. EJB2 provided a mechanism where users could replace the relevant interceptors with their own interceptors that would bypass the local routing logic. EJB3 never supported such a mechanism. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3492?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-3492: --------------------------------------- The intent was to route locally, as the performance of that is much better in the large majority of use cases. Some people did want to load balance the EJB calls. It was a pretty frequent issue on the forums where EJB2 users would ask about how to configure the EJB2 thing I mentioned. My impression is most of the time the discussion led the users to realize they didn't really want to do that. But, not all the time. So, being able to configure things such that calls are load balanced is a legit feature request. The main thing IMO is it needs to be easy for users to end up with the most performant behavior. They should have to go out of their way to end up with calls going remote. This may be something of a non-issue if the concern I have can be solved just by saying "inject a local view if you want to stay in-vm". Which perhaps is what you're plan is anyway! Note that EJB3 HA != load balanced EJB3/Remoting calls. SFSB replication needs to work even if all access to the bean is in-vm via servlets. That's because the HTTP session is replicated and calls are load balanced at the HTTP level. If the HTTP session fails over, the SFSB state needs to be there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3492?page=com.atlassian.jira.plugin.s... ] jaikiran pai updated AS7-3492: ------------------------------ Fix Version/s: 7.1.1.Final (was: 7.1.0.Final) Just discussed with Jason, we'll come back to this post 7.1.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3492?page=com.atlassian.jira.plugin.s... ] jaikiran pai commented on AS7-3492: ----------------------------------- I'm looking at this JIRA now (and going to reword the title more appropriately) and I realize that one usecase where this JIRA is relevant is failover of clustered beans between servers where one of the servers acts as a client. Consider the following usecase: 1) Server A and server B are part of a cluster and both have deployment D containing a stateful @Clustered bean. 2) Server A also has another deployment C which acts as a client to the @Clustered SFSB in D 3) Now when the deployment C invokes on the @Clustered bean in deployment D, server A will route the call to the local EJB receiver (which is the right behaviour). The call(s) go on successfully. 4) Let's assume that at a later point, due to whatever reasons, deployment D is undeployed from server A. 5) Now subsequent calls from deployment C (on server A) should be routed to server B. Currently this won't happen because the local EJB receiver doesn't have relevant implementation to make use of the cluster topology information. I've an implementation for this ready (testing in progress) which does the necessary changes to make sure that the failover happens. Note that this implementation will *not* change the fact that the invocations on the clustered SFSB are pinned to the local node as long as the deployment is present locally, because of the way the affinities work in the SFSB EJBLocator. A SFSB locator is associated with a hard affinity and weak affinity and they make sure that the invocation gets pinned locally unless a failover is necessary. Does anyone see any issues with this? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3492?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-3492: --------------------------------------- The use case you describe is valid and what you describe sounds correct. The intended behavior in AS < 7 was not to disable failover, it was to route the call locally if possible. I would consider disabling failover altogether to be a regression. I mentioned before that perhaps "the concern (about the cost of going remote) can be solved just by saying "inject a local view if you want to stay in-vm"." So if getting the affinities to work properly for this case is a problem, keep that in mind. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3492?page=com.atlassian.jira.plugin.s... ] jaikiran pai commented on AS7-3492: ----------------------------------- This is now fixed in upstream. Here's how we deal with this: 1) A LocalEJBReceiverPreferringDeploymentNodeSelector https://github.com/jbossas/jboss-as/blob/master/ejb3/src/main/java/org/jb... is in place on server side which selects a local receiver if there are multiple receivers (including remote ones) which can handle an invocation on a bean in a deployment. 2) Once the cluster topology is returned to the local receiver, by the remote server instances, the local receiver sets up necessary connection configuration within the EJB client context so that it can be used for connection creation to remote nodes whenever necessary. 3) As long as the local node has the target application deployed, the calls will be routed to the local receiver. 4) Once the target application on the local node gets undeployed, any subsequent invocations for that bean will be routed (i.e. failover) to the remote nodes to which connection will be established using the information available from step#2. All this is tested in https://github.com/jbossas/jboss-as/blob/master/testsuite/integration/clu... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3492?page=com.atlassian.jira.plugin.s... ] jaikiran pai commented on AS7-3492: ----------------------------------- I forgot to add - users can (optionally) override the LocalEJBReceiverPreferringDeploymentNodeSelector, via the jboss-ejb-client.xml, by specifying the deployment-node-selector attribute on the client-context element. Here's an example https://github.com/jbossas/jboss-as/blob/master/testsuite/integration/man... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira