[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] proposed xmlrpc plugin
Póka Balázs wrote:
Exactly this feature is implemented already on server side.
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
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
2) server does not return from call before:
a) at least one message is waiting to be sent to the client
b) some "timeout" seconds elapses (defaults in the order of 10-30,
could be adjusted)
The java and C++ client libs support it via XmlBlasterAccess.receive()
All other clients can use it as well with the plain XML Qos markup, see
* This method synchronously accesses maxEntries messages from any
xmlBlaster server side queue.
* 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.
* at param oid The identifier like
* "topic/hello" to access a history queue,
* "client/joe" to access a subject queue or
* to access a callback queue.
* The string must follow the formatting rule of
* 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
* 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
* 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
* at see javax.jms.MessageConsumer#receive
MsgUnit receive(String oid, int maxEntries, long timeout, boolean
consumable) throws XmlBlasterException;
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
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
thanks in advance,