Skip to content
This repository has been archived by the owner on May 30, 2019. It is now read-only.

Reconnect loop with "Reconnect on error" #104

Open
haarp opened this issue Nov 8, 2015 · 8 comments
Open

Reconnect loop with "Reconnect on error" #104

haarp opened this issue Nov 8, 2015 · 8 comments

Comments

@haarp
Copy link

haarp commented Nov 8, 2015

I have just installed v2.1 from Fdroid. Atomic is shaping up quite nicely, but is not without some bugs.

After enabling Reconnect on error, Atomic connects to my ZNC bouncer successfully, but then reconnects after a couple of seconds, reconnects again, etc. Could it be that it is mistakenly flagging something as an error during a successful connect?

@indrora
Copy link
Owner

indrora commented Nov 9, 2015

How are you configuring Atomic to connect to your ZNC instance?

I'm not seeing this on znc 1.4 with Atomic 2.1-GIT (I dogfood on znc)

@haarp
Copy link
Author

haarp commented Nov 9, 2015

Atomic 2.1 from Fdroid, ZNC-1.4. Atomic is connecting via SSL. I think it might be related to the SSL certificate, which is self-signed and does not contain the correct domain in its CN (not something I am in a position to fix). It might also be related to the notes ZNC plugin and history, which can throw quite a lot of text at you on a connect.

The initial connection works fine. However, when the connectivity changes, the reconnect loop starts.

I enabled the debug log, but there's nothing of relevance here. A few seconds after connecting, it proclaims D/IRCService(31689): In reconnect thread! and starts over.

@indrora
Copy link
Owner

indrora commented Nov 10, 2015

I think it might be related to the SSL certificate, which is self-signed and does not contain the correct domain in its CN (not something I am in a position to fix).

Not even - That would be hanging in a prompt if MemorizingTrustManager wasn't sure.

I can reproduce this however. It eventually works after I inflict a network fluctuation, but something is weird at a lower level.

@jcjordyn130
Copy link

jcjordyn130 commented Dec 16, 2016

I'm really stumped on what this could be...
@indrora Also I am the developer of Simple IRC a fork of Atomic. :P

@s5bug
Copy link

s5bug commented Mar 4, 2017

I just searched the issues for "reconnect" and found this, gonna make my case here.

Atomic sometimes gets disconnected and reconnects, then keeps doing that (was nearly banned for it). After detecting 2 bad/unsuccessful reconnects it should disconnect until the user confirms to reconnect.

It seems like the first post in this issue is related to my issue, so I posted my idea here.

@indrora
Copy link
Owner

indrora commented Mar 4, 2017

@jcjordyn130 → It's an interaction between the "reconnect on socket error" code that I added in pIRCBot and the handler for network exchange (which disconnects, then waits for the network to come back up and reconnects).

I think the easiest answer is to drop one or the other. Dropping network transitions means you're waiting for the TCP socket to die out after the network goes away (result: maybe some missed lines from ZNC if your buffer size is smaller than the number of missed messages). Dropping reconnect on socket error means that network issues not related to the network going away have to be manually handled.

The socket connect code could keep a connect count (start it at 3, decrement until 0?) and if that's been exhausted, give up. That I suspect is a few-line patch that simply adds a bit more state to IrcConnection if memory serves.

I haven't looked at this code in literally a year plus, so forgive me if my own memory is a little weird.

@jcjordyn130
Copy link

yeah it shouldn't be that hard.

@sbug-1bit
Copy link

I have the same problem. Reconnection loop.
Could it maybe be fixed with a longer delay before a new reconnect is tried?
I mean it can take up to 30 seconds to connect, and if Atomic gives up after a few seconds then it will almost never reconnect.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants