[esb-issues] [JBoss JIRA] (JBESB-3959) ServiceInvokerspans multiple nodes when gateway and esb queue are both defined as non clustered

[ https://issues.jboss.org/browse/JBESB-3959?page=com.atlassian.jira.plugin... ] Dave Siracusa updated JBESB-3959: --------------------------------- Description: Messages are crossing server boundaries in a multi-server cluster even though queues are defined as non-clustered. Enqueuing a message only to the first server node is accepted by the first server, and is routed in round robin fashion to each server in the cluster. The reason for this is that during ESB deployment RegistryUtil.register(_config, _epr) is called when it resolves the epr via jmsEprFromElement. The jndi url is resolved via Configuration.getJndiServerURL(). This returns the hostname, so the registered EPR in JUUDI includes host specific EPR entries. The ServiceInvoker appears to route in round robin fashion to each registered entry. Inspecting our older/existing SOA 5.2.0 yields a jnp address which happen to reflect the -b (bind address) we specify (in our case 0.0.0.0). The registration process between SOA 5.2.0 and SOA 5.3.1 differ, where the default behavior in SOA 5.3.1 registration is to register services for use and available to all other node regardless of queue isolation settings and bind address. A combination of clustered and non-clustered queues will likely have problems. was: Messages are crossing server boundaries in a multi-server cluster even though queues are defined as non-clustered. Enqueuing a message only to the first server node is accepted by the first server, and is routed in round robin fashion to each server in the cluster. The reason for this is that during ESB deployment RegistryUtil.register(_config, _epr) is called when it resolves the epr via jmsEprFromElement. The jndi url is resolved via Configuration.getJndiServerURL(). This returns the hostname, so the registered EPR in JUUDI includes host specific EPR entries. The ServiceInvoker appears to route in round robin fashion to each registered entry. Inspecting our existing SOA 5.2.0 yields a jnp address which happen to reflect the -b (bind address) we specify (in our case 0.0.0.0). The registration process between SOA 5.2.0 and SOA 5.3.1 differ, where the default behavior in SOA 5.3.1 registration is to register services for use and available to all other node regardless of queue isolation settings. A possible partial workaround exists for environments which don't define any clustered queues. If you define a JNDI bind address at launch time to 127.0.0.1 calls will not be asynchronously delivered to all nodes in your cluster as the JNP address will reflect 127.0.0.1. A combination of clustered and non-clustered queues will likely have problems. Workaround Description: Workarounds: 1. Environments which don't define any clustered queues. If you define a JNDI bind address at launch time to 127.0.0.1 calls will not be asynchronously delivered to all nodes in your cluster as the JNP address will reflect 127.0.0.1. 2. Specify an alternate loadbalancer (jbossesb-properties.xml), replacing: org.jboss.soa.esb.listeners.ha.RoundRobin. Perhaps the new load balancer can determine via JUDDI and the ESB JMS aware queue definition whether the queue is clustered or not. If so, it can filter out other services running on other nodes which are non-clustered. 3. Investigate using Registry Interceptor? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira