Hi Claudia, I've been looking at your example, and it raises some interesting issues. First of all, I think that using two different transports on the same port is just asking for trouble, since each transport has its own expectations about what messages are coming in. So, unless you have a really good reason for using the same port, I would recommend against it. I expected that when I changed your code to use different ports for the socket and multiplex transports, everything would work fine. It didn't, so I thank you for using two transports on the same port (even though you shouldn't!), since it pointed out a couple of things to be fixed. What is happening, as I think you know, is that the JNDIDetector heartbeat is finding an old reference to a server that no longer exists, trying to ping it, and inadvertently connecting a socket (respectively, multiplex) client invoker to a multiplex (respectively, socket) server invoker. The socket server invoker sees some bytes it doesn't expect, but it shrugs them off. The multiplex server invoker is a little more brittle, so I've made a couple of changes to make it more robust. (Jira issue JBREM-729). I still found that the example wasn't working quite as I expected, and I made a couple of changes to JNDIDetector as well (Jira issue JBREM-730). In particular, JNDIDetector was slow in discovering its new environment because it was counting to 5 before doing a clean detect. I changed it so that it does a clean detect on the first heartbeat. Also, it had trouble registering its new information with the JNDI server because it was using Context.bind() instead of Context.rebind(). These changes are committed to the CVS repository and will be part of the next release. Claudia, I'm curious if you're using Remoting in production code, or are you experimenting? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031925#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...