Attempting to reconnect an XmppClient after disconnecting or failing to log in due to bad credentials fails

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Build an application that supports logging out of the XMPP server, or enter 
bad credentials into call
2. Ensure the logout occurs.
3. Attempt to re-login

What is the expected output? What do you see instead?
I would expect to be able to log in again.  Instead I am unable to because the 
XmppClient object is left in a destroyed state.

What version of the product are you using? On what operating system?
0.6.5, Windows 7 or Ubuntu 10.10/11.04/11.10 or Fedora 14/15

Please provide any additional information below.
It appears part of the problem is that the XmppEngineImpl doesn't signal back 
to the appropriate slots that it has been disconnected, so the owner of the 
XmppClient can't handle it appropriately.  If we use the attached patch, we can 
catch the event and re-initialize.

Original issue reported on code.google.com by dlewa...@connectify.me on 15 Dec 2011 at 3:21

Attachments:

• xmppclient.cc.patch

[GoogleCodeExporter]

I created the issue 133 because I also could not relogin. I will try your patch.

Original comment by diego.cd...@gmail.com on 15 Dec 2011 at 10:42

[GoogleCodeExporter]

diego.cd,

I had remembered a ticket from long ago but couldn't find it so I created a new 
one.  The key to making the relogin work is to recreate the XmppClient instance 
when you received the closed signal.  We do that outside the libjingle library 
so I didn't post that portion.

Original comment by dlewa...@connectify.me on 15 Dec 2011 at 2:16

[GoogleCodeExporter]

Ok, but if I just need to recreate XmppClient, What's your patch used for?

Original comment by diego.cd...@gmail.com on 15 Dec 2011 at 4:01

[GoogleCodeExporter]

The patch adds the sending of the signal to know when the previous client has 
been destroyed.  We found that without that it was unclear when it would go 
away and be ready to be replaced.

Original comment by dlewa...@connectify.me on 15 Dec 2011 at 4:04

[GoogleCodeExporter]

It should be noted that you can't delete the XmppClient instance yourself, you 
need to wait for it to be destroyed by its TaskRunner that owns it.  Once that 
is done, and you get the signal from the patch, you can go ahead and 
instantiate a new one.

Original comment by dlewa...@connectify.me on 15 Dec 2011 at 4:28

[GoogleCodeExporter]

I will try it later. Thanks.

Original comment by diego.cd...@gmail.com on 15 Dec 2011 at 4:38

[GoogleCodeExporter]

Hi diego.cd.
Reconnect problem is not yet solved.
Could you help me with your contribution for reconnection?
Thank you.

Original comment by adam1988...@gmail.com on 20 Jan 2012 at 9:12

[GoogleCodeExporter]

Adam, I've created issue 133 because I have the same problem. In this ticket, 
dlewa... shows an alternative to make relogin work but I haven't tried yet. 
Have you?

Original comment by diego.cd...@gmail.com on 20 Jan 2012 at 10:50

[GoogleCodeExporter]

dlewa..., I receive the signal that indicates connection closed. This happens 
when the app reaches the condition STATE_CLOSE, inside the function 
CallClient::OnStateChange. Another thing is that call example does not create a 
XmppClient directly. Instead, it creates a XmppPump. Finally, I could do the 
relgin creating a new XmppPump, so altought I didn't need your patch, thank you 
for pointing the problem with XmppClient. In the ticket I've create (issue 133) 
Jun said that you can do the relogin just calling the doLogin function again 
but I believe this is not true. I made this test on my app (that's a little bit 
different from call example). I will do some tests on the call example code, so 
I can share this here.

Original comment by diego.cd...@gmail.com on 23 Jan 2012 at 3:14

[GoogleCodeExporter]

diego.cd...we got around the problem by not using the XmppPump that libjingle 
provides in our application - we refactored the necessary parts into the object 
that owns the XmppClient directly.  The XmppPump appeared to be limited in its 
functionality compared with what we needed.

Original comment by dlewa...@connectify.me on 23 Jan 2012 at 3:26

[GoogleCodeExporter]

Ok, understood. But I didn't understand why you are not receiving the signal. I 
can receive the signal on STATE_CLOSE, inside the function 
CallClient::OnStateChange and then create a new XmppPump, make the variable 
CallClient::xmpp_client_ receive the return of pump.client(), connect to the 
signal SignalStateChange of XmppClient 
(xmpp_client_->SignalStateChange.connect(this, &CallClient::OnStateChange)) and 
finally call pump.doLogin(). Actually the code of my app is a little bit 
different but I believe this will work. I will test it later.

Original comment by diego.cd...@gmail.com on 23 Jan 2012 at 3:36