On Fri, Nov 20, 2009 at 1:29 PM, Marc wrote:
> Thank's Donk, when I wrote my last message I wasn't really aware of the
> extent of my problem, now I think I have a better idea and solution!!
> hopefully.
>
> My problem is that I'm using a non-blocking connection like in the discotest
> example, so the main program cicle is driven by this connection which is
> pretty handy as I can set all kinds of handlers and forget about it, the bad
> part is that when I lose network connection, the program doesn't realize its
> not connected to the server since any of the handlers has not received any
> warning (obviously).
>
> If I use a blocking connection, as soon as I get the connection, the program
> has control again which is good and bad since I have to change everything
> and ask for incomming messages every once in a while.
>
> What I've done in the meanwhile is keep the initial non-blocking connection
> and an extra function which tries a new connection with the same JID.
> So I have one big non-blocking connection keeping it all toghether and a
> quick blocking connection with the same JID to check that everything is
> fine, if it fails to connect I don't send the message and since I already
> had a thread sending whitespace pings every minute, I use this to know when
> the connection is back and send stored messages.
>
> This is working for me right now, if anybody has a better idea...
>
I think I understand what you're getting at but I need some clarification.
By "discotest" do you mean ./gloox-0.9.9.12/src/examples/disco_example.cpp?
In disco_example.cpp line 35 I see the following:
j->connect();
Looking at ./gloox-0.9.9.12/src/clientbase.h line 106 I see the
following definition:
bool connect( bool block = true );
It appears that ClientBase::connect() defaults to blocking behavior -
at least as defined by the Gloox API Documentation. Are you calling
connect(), connect(true) or connect(false)?
If you are blocking (using connect() or connect(true)), which handler
are you calling send() from?
Do you have any loops in the handlers which cause the program to get
'stuck' and not return from the handler?
Jakob Schroeter is the person to answer this definitely but I would
guess that not returning from a handler might interfere with gloox's
ability to poll the network state and update its own state internally.
That would be consistent with the behavior you're reporting from calls
to ClientBase::state() and Client::status().
Good Luck,
"Donk"