[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] reliability of publish

typhoon wrote:
> Hi
> I want to transport mission-critical messages over xmlBlaster, and the client side persistence
> is not supposed to be used. Unfortunately, I find no way (both in Java and C++) to make sure 
> whether the messages have been published successfully (I mean, persisted in the server side).
> It seems that the client side logic always put the messages in the client queue, and once 
> queued, the message is out of control. If the server side is not accessible, we may get an 
> exception or a Constant.INFO_QUEUED stateinfo on publish(); but in either case the message 
> still stays in the client queue. Now, if our client crashes, the message is lost; if the
> server becomes accessible, the message will be re-published automatically. 
> I tried following codes:
> 	ProtocolPluginManager mgr = glob.getProtocolPluginManager();
> 	I_XmlBlasterConnection driver = mgr.getPlugin("IOR", "1.0");
> 	driver.connectLowlevel(new Address(glob));
> It's OK to work around the problem, but noway elegant I think :), because the client side plugin 
> workflow is completely short-cutted. Any better solution please? 

you want to have the feature of reconnect polling but
your client thread shall get an exception (or block?) when trying to publish.
Probably you can achieve this by registering a I_ConnectionStateListener
(see HelloWorld6.java) and add some pieces of client code
which behaves as you desire.

Note that the client queue is in sync mode during ALIVE connection state,
there won't be anything inside the queue. Your client thread pierces
through the client queue directly into the DispatchManager and the
protocol layer over TCP/IP to the xmlBlaster server.

On reachedAlive() events you can clear() the client side queue to send
nothing left over from async mode.



>         typhoon
>         typhoon_fei at sina.com.cn
>           2004-06-24