[clarich]

Well, duh, of course I am. ;-)

(And thanks for the hint with lower and upper case writing, as I am not a native speaker, I live and learn)

[ron_sigal]

Well, I never would have guessed that English is not your native language. You write very well. Where do you live, anyway?

My reference to upper and lower case, by the way, was just to distinguish between the generic notion of a client and the specific class org.jboss.remoting.Client, not to point out any mistake in your grammar.

I think the best way for me to try to figure this out would be to play with the code. Could you either post the code or e-mail it to me?

[clarich]

I wrote you an email with the source code attached.

[ron_sigal]

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?

[clarich]

Hi Ron,
actually the source code I'm working at is not yet in production. It is still in experimental stage. I found that issue by chance, when I wanted to run my tests with different protocols. So I guess it will not happen very often that the protocol changes on one port.

I'm pleased to hear that you made the multiplex server invoker more robust. Actually, this was another issue I had. I already posted it here
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=104757&start=0. So maybe your changes could be the solution for this problem, too.

I'm going to try it out. Are the changes already available in the CVS?

[clarich]

These changes are committed to the CVS repository and will be part of the next release.

Sorry, I overlooked this line.

[ron_sigal]

Hi Claudia,

I'm pleased to hear that you made the multiplex server invoker more robust

If you're interested in the multiplex transport for its ability to support callbacks with clients behind firewalls, you ought to take a look at the new bisocket transport. The original motivation for multiplex was to satisfy the need of the JBoss Messaging group for a transport that could work in the presence of firewalls, but they didn't get around to using it in their 1.0 release. By the time they got around to the issue for their 1.2 release, there was some feeling that multiplex wasn't really suitable, so I wrote bisocket as a replacement. It's conceptually simpler, easier to configure, and should perform nearly as well as the socket transport, from which it derives most of its functionality. There's a description in the Remoting documentation.

[clarich]

Hi Ron,
I guess I'll have a look to the bisocket protocol. But first, there is still a problem with my example. I wanted to exchange on the client side this method:

 public void setupConnection(int port, String host) throws Exception {
 log.info("setting up connection to JNDI Server");
 MBeanServer mbeanServer = MBeanServerFactory.createMBeanServer();
 NetworkRegistry registry = NetworkRegistry.getInstance();
 log.info("register NetworkRegistry with MBean Server");
 mbeanServer.registerMBean(registry, new ObjectName(
 "remoting:type=NetworkRegistry"));

 detector = new JNDIDetector();
 detector.setPort(port);
 detector.setHost(host);
 detector.setCleanDetectionNumber(1);
 mbeanServer.registerMBean(detector, new ObjectName(
 "remoting:type=JNDIDetector"));
 detector.start();
 while (detector.forceDetection() == null) {
 // retry
 }

with this one:

public void setupConnection(int port, String host) throws Exception {

 MBeanServer server = MBeanServerFactory.createMBeanServer();
 NetworkRegistry registry = NetworkRegistry.getInstance();
 log.info("register NetworkRegistry with MBean Server");
 server.registerMBean(registry, new ObjectName(
 "remoting:type=NetworkRegistry"));

 detector = new JNDIDetector();
 detector.setPort(port);
 detector.setHost(host);
 ObjectName name = new ObjectName("remoting:type=JNDIDetector");

 server.registerMBean(detector, name);
 detector.start();
 }

What I got was this:

reqistering with JNDI server
2007-03-29 19:13:41,971 WARN [main] org.jboss.remoting.detection.jndi.JNDIDetector: Detector: org.jboss.remoting.detection.jndi.JNDIDetector could not be loaded because the NetworkRegistry is not registered
2007-03-29 19:13:41,971 WARN [main] org.jboss.remoting.detection.jndi.JNDIDetector: This means that only the broadcasting of detection messages will be functional and will not be able to discover other servers.
susseccfully reqistered with JNDI Server
2007-03-29 19:13:42,783 INFO [input:15824] org.jboss.remoting.transport.multiplex.InputMultiplexor: unknown socket id: 3
2007-03-29 19:13:42,799 INFO [MultiplexServerInvoker#0v-VirtualServerSocket[Socket[addr=/127.0.0.1,port=3231,localport=1101]]] org.jboss.remoting.transport.multiplex.MultiplexServerInvoker: socket is closed: stopping thread
2007-03-29 19:13:42,799 INFO [Remoting Detector - Heartbeat Thread: 0] org.jboss.remoting.detection.jndi.JNDIDetector: Added 3087152660c52e45x-3af92cc0x110ba7efe6bx-7ffb56 to registry.
2007-03-29 19:13:48,127 INFO [MultiplexServerInvoker#0v-VirtualServerSocket[Socket[addr=/127.0.0.1,port=3241,localport=1101]]] org.jboss.remoting.transport.multiplex.MultiplexServerInvoker: socket is closed: stopping thread
2007-03-29 19:13:48,346 INFO [input:15824] org.jboss.remoting.transport.multiplex.InputMultiplexor: java.io.IOException: An existing connection was forcibly closed by the remote host
2007-03-29 19:13:48,627 INFO [output:15824] org.jboss.remoting.transport.multiplex.OutputMultiplexor$OutputThread: java.nio.channels.ClosedChannelException
2007-03-29 19:13:48,971 INFO [Remoting Detector - Heartbeat Thread: 7] org.jboss.remoting.detection.jndi.JNDIDetector: Added 3087152660c52e45x-3af92cc0x110ba7efe6bx-7ffb56 to registry.
2007-03-29 19:13:52,564 INFO [input:15824] org.jboss.remoting.transport.multiplex.InputMultiplexor: Selector is closed: shutting down input thread

This is the whole dump of my server. When using the first method everything works fine.

[clarich]

Hi Ron,

I found out, that sslsocket does not work on that example anymore after exchanging the remoting version 2.2.0 with the CVS sources. When using version 2.2.0 again it works fine. Are you working on that? Or is this another issue?

[ron_sigal]

Hi Claudia,

Thanks for pointing that out. I'll look into it.

-Ron