0 Replies Latest reply on Jun 23, 2007 12:18 AM by Ron Sigal

    New blocking mode for pul callbacks

    Ron Sigal Master

      Remoting has a new callback polling mode, in response to the forum thread http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990104#3990104.

      In the original mode, now known as "nonblocking" mode, org.jboss.remoting.Client.getCallbacks() makes an invocation on the server and returns all waiting callbacks. If there are no callbacks to be retrieved, it returns an empty list. This call may be made directly from the application, in the manner of pull callbacks, or it can be made from an instance of org.jboss.remoting.callback.CallbackPoller, which simulates push callbacks by pulling callbacks from the server and then pushing them to an org.jboss.remoting.callback.InvokerCallbackHandler. See Section 5.6 "Callbacks" in the Remoting Guide (http://labs.jboss.com/jbossremoting/docs/guide/ch05.html#section-callbacks) for more information.

      The problem with nonblocking mode is latency. For example, if CallbackPoller is used, the default behavior is to poll for callbacks every five seconds. In the new "blocking" mode, on the other hand, Client.getCallbacks() will either

      1. return all waiting callbacks, if there are any, or

      2. if there are no waiting callbacks, block on the server side and wait until a callback is created or until the timeout period elapses.

      In other words, in blocking mode, a callback will be returned soon after it is created

      The default behavior is to use nonblocking mode, to avoid behavioral changes without explicit action. To switch to blocking mode, the key org.jboss.remoting.ServerInvoker.BLOCKING_MODE (actual value "blockingMode") needs to be added to the appropriate configuration map, as explained below, with the value ServerInvoker.BLOCKING (actual value "blocking").

      To accomodate pull callbacks, a new method

       public List getCallbacks(InvokerCallbackHandler callbackHandler, Map metadata) throws Throwable;
      


      has been added to the Client class, and the configuration information can be passed in the metadata map. If CallbackPoller is used, then one of the methods from the Client class

       public void addListener(InvokerCallbackHandler callbackhandler, Map metadata) throws Throwable;
      
       public void addListener(InvokerCallbackHandler callbackhandler, Map metadata,
       Object callbackHandlerObject) throws Throwable;
      
       public void addListener(InvokerCallbackHandler callbackhandler, Map metadata,
       Object callbackHandlerObject, boolean serverToClient) throws Throwable;
      


      may be used, with the configuration information passed in the metadata map.

      A couple of additional configuration parameters are available, which are passed the same way as the blocking mode.

      1. ServerInvoker.BLOCKING_TIMEOUT (actual value "blockingTimeout") determines how long the Client.getCallbacks() will block on the server side, waiting for a callback to be created, before timing out and returning an empty list. The default value is 5000 ms.

      2. CallbackPoller.MAX_ERROR_COUNT (actual value "maxErrorCount") determines how many errors CallbackPoller will sustain before it stops polling and shuts itself down. This parameter applies to both blocking and nonblocking polling. The default value is 5