librelist archives

« back to archive

auto_reconnect loop

auto_reconnect loop

From:
Justin Stefani
Date:
2014-10-01 @ 17:48
I've enabled auto_reconnect, prebind, and have included jid, sid, rid, 
bosh url in initialization. I've forcing a disconnect of a user session 
from the xmpp server to test the auto reconnection. Stepping through the 
onConnect function, I get to the converse DISCONNECT state, then to the 
reconnect function. The reconnect function emits a 'reconnect' event 
which, in my scenario, eventually calls the exact same reconnect function 
where the emit took place, and an infinite loop follows. Anyone else 
experiencing this in v0.8.1?

Also, in the same reconnect function there is an if statement checking if 
prebind is false before continuing with a connection. Why is it checking 
for false? Isn't prebind required for auto reconnect?

Thanks

Re: [conversejs] auto_reconnect loop

From:
Jc Brand
Date:
2014-10-02 @ 06:30

On 1. Oktober 2014 19:48:20 GMT+02:00, Justin Stefani 
<jstefani@thinkingphones.com> wrote:
>I've enabled auto_reconnect, prebind, and have included jid, sid, rid,
>bosh url in initialization. I've forcing a disconnect of a user session
>from the xmpp server to test the auto reconnection. Stepping through
>the onConnect function, I get to the converse DISCONNECT state, then to
>the reconnect function. The reconnect function emits a 'reconnect'
>event which, in my scenario, eventually calls the exact same reconnect
>function where the emit took place, and an infinite loop follows.
>Anyone else experiencing this in v0.8.1?

Yes, I'm aware that auto-reconnect is not working properly. I haven't had 
time to debug it.

>Also, in the same reconnect function there is an if statement checking
>if prebind is false before continuing with a connection. Why is it
>checking for false? Isn't prebind required for auto reconnect?

Reconnect needs the username and password, which is not available during prebind.

In the prebind case, best is probably to emit and then listen for an event
on disconnect and then call the prebind procedure again (e.g. via ajax) 
together with converse.initialize.



-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: [conversejs] auto_reconnect loop

From:
Justin Stefani
Date:
2014-10-02 @ 17:17
As an alternate solution I am handling the disconnect events myself. I am 
watching the connect_callback state, and when the state is 
Strophe.Status.DISCONNECTED, then I create a new connection and 
re-initialize converse (with prebind). The problem I am seeing now is that
when I initialize the second time - with new jid/sid/rid - it seems 
converse is maintaining the old connection values and therefore the 
connection ultimately fails. However, if I nullify converse.connection in 
my DISCONNECTED function, then all seems to work fine - I assume because 
the connection object is not recycled.

So why would the new initialization values not be applied to the 
connection up initialization? And if I must keep my current solution, is 
there a more graceful way to 'remove' the converse.connection in my 
disconnected function?

Thank you

-----Original Message-----
From: conversejs@librelist.com [mailto:conversejs@librelist.com] On Behalf
Of JC Brand
Sent: Thursday, October 02, 2014 2:30 AM
To: conversejs@librelist.com
Subject: Re: [conversejs] auto_reconnect loop



On 1. Oktober 2014 19:48:20 GMT+02:00, Justin Stefani 
<jstefani@thinkingphones.com> wrote:
>I've enabled auto_reconnect, prebind, and have included jid, sid, rid, 
>bosh url in initialization. I've forcing a disconnect of a user session 
>from the xmpp server to test the auto reconnection. Stepping through 
>the onConnect function, I get to the converse DISCONNECT state, then to 
>the reconnect function. The reconnect function emits a 'reconnect'
>event which, in my scenario, eventually calls the exact same reconnect 
>function where the emit took place, and an infinite loop follows.
>Anyone else experiencing this in v0.8.1?

Yes, I'm aware that auto-reconnect is not working properly. I haven't had 
time to debug it.

>Also, in the same reconnect function there is an if statement checking 
>if prebind is false before continuing with a connection. Why is it 
>checking for false? Isn't prebind required for auto reconnect?

Reconnect needs the username and password, which is not available during prebind.

In the prebind case, best is probably to emit and then listen for an event
on disconnect and then call the prebind procedure again (e.g. via ajax) 
together with converse.initialize.



--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: [conversejs] auto_reconnect loop

From:
Jc Brand
Date:
2014-10-03 @ 08:00

On 2. Oktober 2014 19:17:52 GMT+02:00, Justin Stefani 
<jstefani@thinkingphones.com> wrote:
>As an alternate solution I am handling the disconnect events myself. I
>am watching the connect_callback state, and when the state is
>Strophe.Status.DISCONNECTED, then I create a new connection and
>re-initialize converse (with prebind). The problem I am seeing now is
>that when I initialize the second time - with new jid/sid/rid - it
>seems converse is maintaining the old connection values and therefore
>the connection ultimately fails. However, if I nullify
>converse.connection in my DISCONNECTED function, then all seems to work
>fine - I assume because the connection object is not recycled.
>
>So why would the new initialization values not be applied to the
>connection up initialization? And if I must keep my current solution,
>is there a more graceful way to 'remove' the converse.connection in my
>disconnected function?

What you're trying to do is non-trivial and there are a few snags. I did 
some work on this for 0.8.3.
Take a look at the teardown and initialize methods I added for that release.

I assume you're backporting stuff to 0.8.1 because you've modified it so 
heavily that you can't easily upgrade to 0.8.3?

Maintainability of code is one of the main reasons why it's in people's 
best interests to merge their modifications back upstream. If you don't, 
then you create much more effort for yourself in having to merge new 
releases with your existing private features. 

I therefore implore everyone to write code in such a way that it can be 
merged back upstream with converse.js (and then to make a pull request).

Besides that, the Mozilla Public License under which converse.js is 
released requires any distributed modifications to be made publically 
available.


>-----Original Message-----
>From: conversejs@librelist.com [mailto:conversejs@librelist.com] On
>Behalf Of JC Brand
>Sent: Thursday, October 02, 2014 2:30 AM
>To: conversejs@librelist.com
>Subject: Re: [conversejs] auto_reconnect loop
>
>
>
>On 1. Oktober 2014 19:48:20 GMT+02:00, Justin Stefani
><jstefani@thinkingphones.com> wrote:
>>I've enabled auto_reconnect, prebind, and have included jid, sid, rid,
>
>>bosh url in initialization. I've forcing a disconnect of a user
>session 
>>from the xmpp server to test the auto reconnection. Stepping through 
>>the onConnect function, I get to the converse DISCONNECT state, then
>to 
>>the reconnect function. The reconnect function emits a 'reconnect'
>>event which, in my scenario, eventually calls the exact same reconnect
>
>>function where the emit took place, and an infinite loop follows.
>>Anyone else experiencing this in v0.8.1?
>
>Yes, I'm aware that auto-reconnect is not working properly. I haven't
>had time to debug it.
>
>>Also, in the same reconnect function there is an if statement checking
>
>>if prebind is false before continuing with a connection. Why is it 
>>checking for false? Isn't prebind required for auto reconnect?
>
>Reconnect needs the username and password, which is not available
>during prebind.
>
>In the prebind case, best is probably to emit and then listen for an
>event on disconnect and then call the prebind procedure again (e.g. via
>ajax) together with converse.initialize.
>--
>Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>gesendet.

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.