Re: [xmlblaster] proposed xmlrpc plugin

[Marcel Ruff <mr at marcelruff.info>]

Póka Balázs wrote:
> Hello,
>
> I'd like to have some advice on a small project I need to get done as 
> soon as possible.
> Until now we have been using the plain SOCKET protocol to communicate 
> with clients due to the fact that it's the only option if the server 
> is unable to connect to the client (NAT, firewall, etc.). I need to 
> use the update() method to receive messages. The problem with this is 
> that clients still need full internet capability. However, we are 
> gaining some customers who [will not/can not] change their firewall 
> configuration because of this, and only let HTTP traffic pass through 
> their proxies.
>
> I've already started rewriting the XMLRPC plugin to support the apache 
> xml-rpc library version 3, as the old one (v2) is quite outdated. The 
> normal (non-callback) calls would be done exactly like now.
>
> My idea about emulating callbacks _without the server needing to 
> connect to the client_ (but with a better response time and less 
> overhead) would be the following:
> 1) client issues XMLRPC request to server (can be considered something 
> like polling)
> 2) server does not return from call before:
>    a) at least one message is waiting to be sent to the client
>      or
>    b) some "timeout" seconds elapses (defaults in the order of 10-30, 
> could be adjusted)
Exactly this feature is implemented already on server side.
The java and C++ client libs support it via XmlBlasterAccess.receive() 
(see below).
All other clients can use it as well with the plain XML Qos markup, see
http://www.xmlblaster.org/xmlBlaster/doc/requirements/engine.qos.queryspec.QueueQuery.html

  /**
   * This method synchronously accesses maxEntries messages from any 
xmlBlaster server side queue.
   * <p>
   * This is a convenience method which uses get() with a specific Qos.
   * <p>Important note:<br />
   * Currently you shouldn't use unlimited timeout==-1 as this could
   * lead to a server side thread leak on client disconnect.
   * As a workaround please use a loop and a timeout of for example 60000
   * and just ignore returned arrays of length 0.
   * </p>
   *  at param oid The identifier like
   *            "topic/hello" to access a history queue,
   *            "client/joe" to access a subject queue or
   *            "client/joe/session/1"
   *            to access a callback queue.
   *            The string must follow the formatting rule of 
ContextNode.java
   *  at param maxEntries The maximum number of entries to retrieve
   *  at param timeout The time to wait until return.
   *                If you choose a negative value it will block until 
the maxEntries
   *                has been reached.
   *                If the value is '0' (i.e. zero) it will not wait 
and will correspond to a non-blocking get.
   *                If the value is positive it will block until the 
specified amount in milliseconds
   *                has elapsed or when the maxEntries has been reached 
(whichever comes first).
   *  at param consumable  Expressed with 'true' or 'false'.
   *                    If true the entries returned are deleted from 
the queue
   *  at return An array of messages, is never null but may be an array of 
length=0 if no message is delivered
   *  at see org.xmlBlaster.util.context.ContextNode
   *  at see <a 
href="http://www.xmlblaster.org/xmlBlaster/doc/requirements/engine.qos.queryspec.QueueQuery.html";>engine.qos.queryspec.QueueQuery 
requirement</a>
   *  at see javax.jms.MessageConsumer#receive
   */
  MsgUnit[] receive(String oid, int maxEntries, long timeout, boolean 
consumable) throws XmlBlasterException;


regards
Marcel
> This way, the client only needs to poll every "timeout" seconds if 
> there is no traffic. The average latency of messages is reduced as the 
> server can return the message(s) as the return value of the current 
> poll() call almost immediately when some message(s) are to be sent to 
> the client.
>
> My question is how I could implement this polling mechanism in the 
> plugin (so that I don't need to rewrite anything in the application), 
> meaning that I'd like to keep it working this way:
>
> ...
> xmlBlasterConnection.connect (qos, listener);
>
> and getting all messages as updates through "listener", just like with 
> SOCKET.
>
> thanks in advance,
> Balázs Póka


--
Marcel Ruff
http://www.xmlBlaster.org