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

Re: [xmlblaster] connecting

Hi Kai,
I think there is a missunderstanding:

When you try to connect in failsafe mode (failsafe: register a
I_ConnectionStateListener + retries=-1) you don't get an exception even
if the server is not available.

What happens is that the connection request is queued on the client side
and the XmlBlasterAccess object creates a fake return qos for you. So
under a client point of view you are connected (even if the physical low
level connection is not established).

So isConnected returns true because the connect message was (at least)
safely queued on the client side and you are allowed to publish
subscribe and so on (as you would be physically connected). The only
feature you are not able to do is GET (see the table in the failsafe

Once you connect you are connected. The Connection has several states:


so in your case isConnected() gives true, isPolling() gives also true
and isAlive() gives false.

So try the following:

make a connect (no need to loop in the catch)
=> you connection msg is queued
start the xmlBlaster
=> your method reachedAlive(..) is invoked
stop the xmlBlaster
=> your method reachedPolling() is invoked

So if you really need the server for your work (in many use cases you
don't need it) you would block in the thread making the connect and you
would release that thread in your reachedAlive() method.

Also see the second example in the requirement for more details.


Kai wrote:
> Michele Laghi schrieb:
>> The method reachedAlive of your own implementation of
>> I_ConnectionStateListener will be invoked (don't forget to register it)
>> see for example the first example in
>> http://www.xmlblaster.org/xmlBlaster/doc/requirements/client.failsafe.html
> Hey thanks for your answer. I registered a I_ConnectionStateListener but
> it has no effect. Then I tried the following:
> //-- code --
> _XmlBlasterAccess acces = glob.getXmlBlasterAccess
> try{
>   access.connect();
> }catch(XmlBlasterException e)
> {
>   while (acces.isPolling())
>   {
>     // wait for server.
>   }
> }
> ...
> //-------
> Strange is that the loop doesn't loop but the log output says the client
> changes from UNDEF to POLLING. Is this a feature or a bug? IMHO its a
> bug. Look at isPolling:
> //-- code --
> public boolean isPolling() {
>   if (!isConnected()) return false;
>   return this.dispatchManager.getDispatchConnectionsHandler().isPolling();
>    }
> //-------
> isConnected must return false because we got no connection, but the
> client is polling for a server and tries to get a connection! IMHO
> isPolling() should only call the DispatchManagers
> ConnectionHandler.isPolling().