> Hi,
>
> On Wednesday January 16 2008, Philippe Roger wrote:
> > What can be done in the onDisconnect() handler of a connection listener,
> > attached to a gloox client, except terminating the client and creating
> > another one? I don't see how one can reestablish the lost connection,
> as
> > ClientBase::connect() creates a parser, a connection, etc. and finally
> > opens the TCP connection. But since the m_connection data member is
> > protected, it is all but impossible to just call connect() again on the
> > m_connection object to continue. and in order to call
> ClientBase::connect()
> > again without leaking at least a parser object, the ClientBase
> destructor
> > must be called first. Am I missing something obvious?
>
> Hm, there are quite some conditionals in the code to prevent leaking.
> Also,
> there are tests in src/tests/client/client_test.cpp that test re-
> connection.
> So from what I can tell, it should work and it should not leak. Are you
> seeing any real problems related to re-establishing a connection?
>
> cheers,
> Jakob
Hi Jakob,
As I said, I must be missing something obvious...
In src/tests/client/client_test.cpp, the onDisconnect() handler does not
attempt to reestablish the connection. It simply logs the error. The main
code simply deletes and re-creates a Client-derived object after a
gloox-initiated disconnect, which is essentially my question. Is there a
way to re-establish the TCP connection without deleting the client object
first? In this test, the onConnect() handler does initiate a disconnection
though, but I am talking about a disconnection initiated by gloox (i.e.
network-side).
When I mention connection, I am talking about the TCP connection (port 5222
to the Jabber server), which could be broken with the network interface
going down, for example... The test uses its own simulation of a connection,
but it never breaks on its own, as far as I can tell.
My actual problem is that my application seems to be caught in a recursive
loop, which allocates more memory at every pass, when I am trying to
reconnect following a TCP connection failure, probably due to a faulty
implementation of my application...
Thanks,
Philippe