Starting a callback server requires unnecessary step

[ovidiu.feodorov]

I want my client to receive asynchronous callbacks so I start a colocated callback server for it:

 ...

 // start the callback server
 InvokerLocator callbackServerLocator = new InvokerLocator("whatever");
 Connector connector = new Connector();
 connector.setInvokerLocator(callbackServerLocator.getLocatorURI());
 connector.start();

 // this is unnecessary
 connector.addInvocationHandler("irelevant", new WhateverServerInvocationHandler());
 // end of unnecessary

 // add the push callback
 client.addListener(new MyInvokerCallbackHandler(), callbackServerLocator);

 .....

Intuitively, if I start the callback server for the only purpose of receiving callbacks, I don't need to specify any custom behavior, hence no need to register any ServerInvocationHandler with my callback server.

However, if I don't add a ServerInvocationHandler, when trying to client.addListener(), I get

Exception in thread "main" java.lang.RuntimeException: Can not find a subsystem handler to take invocation request.
 at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:309)
....

The callback server shouldn't care, it should allow registering callback listeners and actually handle callbacks without requiring a ServerInvocationHandler. Does it sound right?

[mazz]

No, I'm pretty sure you need a handler. That's the thing that actually handles the incoming request (or in this case, the incoming callback). Its in your handler that you will process the callback data. If you don't don't add a handler - who is going to get your callback data? Who actually will handle processing it?

[ovidiu.feodorov]

The ServerInvoker doesn't use the ServerInvocationHandler instance to process callbacks. It uses CallbackContainer instances. It also doesn't use the ServerInvocationHandler instance to register callback listeners, either.

Look at ServerInvoker.handlerInternalInvocation(). For ADDCLIENTLISTENER, the "handler" reference is never used, the implementation doesn't care whether is null or not.

It is an artificial requirement that the client code must add an unnecessary handler, which has no connection with the handler that actually does the job. I would refine a little bit more ServerInvoker.invoke(InvocationRequest invocation) method instead.

[tom.elrod]

Remoting is just a mechanism for making remote invocations (including callbacks). It has no concept of contextual processing. There has to be a ServerInvocationHandler on the server side to process invocation requests, including adding and removing of callback listeners. The ServerInvocationHandler is also responsible for generating the callbacks (remoting itself has not idea of when a callback should be generated or what it contains, it only knows how to get the callback sent to the original listener).

The concept is similar to jmx notifications. The listener asks the MBeanServer to add itself as a listener to a particular MBean. That MBean generates a notification and emits it (which goes back through the MBeanServer, in the case that the listener is an MBean). Just substitue remoting for MBeanServer and ServerInvocationHandler for the target MBean.

In the actual implementation, the client callback listener does not go across the wire. Instead, the ServerInvoker will create a proxy back to that client callback listener and register this proxy as the callback listener with the ServerInvocationHandler on the server side. When the ServerInvocationHandler generates a callback message and calls on its local list of callback listeners to handle the callback, it is calling on the proxy. The proxy will either store the callback (in the case of pull callbacks until the client calls to get them) or will calll back on the callback server directly with the new callback.

org.jboss.samples.callback.CallbackClient and org.jboss.samples.callback.CallbackServer show an example of both the pull and push callbacks.

This is all by design. If we need to add additional/different behavior, will need to be viewed as a new feature. I'm fine with this, just need the requirements.

[tom.elrod]

I posted a document that describes how callbacks work (in detal) on the wiki. Go to http://www.jboss.org/wiki/Wiki.jsp?page=Remoting and look for the "How callbacks work." link.

[ovidiu.feodorov]

Remoting is just a mechanism for making remote invocations (including callbacks). It has no concept of contextual processing. There has to be a ServerInvocationHandler on the server side to process invocation requests, including adding and removing of callback listeners. The ServerInvocationHandler is also responsible for generating the callbacks (remoting itself has not idea of when a callback should be generated or what it contains, it only knows how to get the callback sent to the original listener).

I agree. You definitely need a ServerInvocationHandler on the target server, otherwise the target server is useless.

However, you don't need a ServerInvocationHandler on the callback server, assuming that you created the callback server to only handle callbacks. This paragraph from the wiki document you've posted seems to confirm that:

It is important to note that sub-system associated with the callback server is not directly involved in the dispatching of callbacks to the client callback handler; this is all handled within the JBoss Remoting layer.

... and this is a logical inference based on the above paragraph:

(I create a callback server to only handle callbacks) + (the subsystems associated with the callback server are not involved in the dispatching of callbacks) => (I don't need server invocation handlers on my callback server)

Do we agree up this point?

[tom.elrod]

Ahh. Ok. I misunderstood what you were saying originally. For the callback server, if it is not handling any direct invocations, only callbacks, the I agree that there is no need for a handler to be registered (conceptually).

However, I don't make a distinction, in the implementation, between a normal remoting server that receives direct invocations and one that only receives callbacks. I think that the best way to accomidate for this it to add a new callback server specific implementation that does not require a invocation handler. Have added it as a task in jira ( JBREM-94).

Thanks for following up. Sorry I missed the original point. :)

[ovidiu.feodorov]

I don't think it's necessary to add a new callback server specific implementation. You have all the wiring in there, I would just tweak a little bit ServerInvoker.handleInternalInvocation() so it won't get upset when someone tries to register callbacks when no handlers are present. Other than than, the API for creating a server is just fine, I don't think it needs to be modified.