Thanks for asking; we resolved this on our support portal and I forgot to post the result here. The issue is the RMI stub for the HA-JNDI service. Clients that connect to HA-JNDI use RMI as the transport, so each server running HA-JNDI creates an RMI stub for use in communicating with that server. When a client contacts the HA-JNDI service and downloads a proxy for that service, the proxy includes the RMI stubs for *all* the servers in the cluster. The presence of these stubs is what allows the proxy to fail over from one server to another if needed. So, say you have a 3 server cluster, A, B and C. A client contacts C (e.g. at port 1100) and downloads an HA-JNDI proxy. The proxy includes separate RMI stubs for A, B and C. How does C have a stub for A and B? When C joins the cluster, it fetches A and B's stubs, and sends its stub to A and B. The traffic Anne was seeing was the normal traffic of an RMI stub communicating back to its origin server for the purpose of maintaining a "lease" on the RMI server object. This "lease" is used by RMI's distributed garbage collection; without it the RMI server object could be gc'd. By default, this communication happens when the stub is first deserialized, and every 5 minutes thereafter. This communication is part of standard RMI stub behavior; it's not something JBoss wrote. The communication occurred on 1098 because that's the RMI port they had configured for HA-JNDI. By default in current versions of the AS, this port is 1101. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3966721#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...