KiwiIRC keeps connection alive if browser is closed instead of tab

[madjo80]

I have found that when a webchat user closes the webbrowser without first navigating away from the webchat or closing the webchat tab, the connection to the irc-server remains alive, while the user itself does leave the chatroom.

When that user tries to log in again with his/her original name, the server reports that it's already in use (obviously).

The connection persists, until KiwiIRC is restarted.

[asdofindia]

Looks similar to #723

[madjo80]

Kind of, sort of, except the connection doesn't die, at all, no ping timeout or anything. but to answer the questions in that one: 1) version 0.9.1 2) yes, all users, if they don't close the tab before closing the browser, or if they don't close the connection via the [x] at the console tab. 3) I'm not aware of any reverse proxies (but I'll have to double check this with the host of the webclient) 4) No SSL.

Right now I circumvented maxing out the webclient irc-connections by doing a daily KiwiIRC restart.

[Xeeke]

Running into the same thing. If the HTTP client just goes away unexpectedly, KiwiIRC is keeping the connection to IRC open forever.

[hexsum]

I encountered the same issues. The IRC server keep reponsing: Nickname already in use forever and ever

Dose anyone know how to fix it..

[no-trick-pony]

We encounter similar issues, however, we can't reproduce them the way people describe it here (simply closing the browser. Neither closing it normally, nor closing it with kill -9 produces the problems described).

Could anyone provide detailed steps on how to reproduce the issues?

[CoryChaplin]

For now, the best way to avoid having this issue is to put this option in the settings : conf.ircd_reconnect = false;

Elephantman

De : no-trick-pony notifications@github.com Répondre à : prawnsalad/KiwiIRC <reply+004e6cd532a790443cc7d5470e1d744712868c61c63ef96392cf0000000111e6e27b9 2a169ce05db788f@reply.github.com> Date : samedi 15 août 2015 13:20 À : prawnsalad/KiwiIRC KiwiIRC@noreply.github.com Objet : Re: [KiwiIRC] KiwiIRC keeps connection alive if browser is closed instead of tab (#732)

We encounter similar issues, however, we can't reproduce them the way people describe it here (simply closing the browser. Neither closing it normally, nor closing it with kill -9 produces the problems described).

Could anyone provide detailed steps on how to reproduce the issues?

‹ Reply to this email directly or view it on GitHub https://github.com/prawnsalad/KiwiIRC/issues/732#issuecomment-131354992 .

[cacheworks]

This was also discussed on the Google groups page, where I shared my plugin which helps to mitigate this a bit more than just the conf.ircd_reconnect = false; setting mentioned above https://groups.google.com/d/msg/kiwiirc/5yLqSZD9UhI/Ph1GZzmQodMJ

I've taken out the beforeunload popup in /client/src/views/application.js and added a plugin with the following code:

<script> 
        window.addEventListener("beforeunload", function(e){ 
                kiwi.components.Network().quit('Closing tab') 
        }, false); 
</script> 

This unfortunately only works when users close their tabs nicely, tab crashes and connection issues often still result in the username being locked up

I've also set up /recover as alias for /ns RECOVER to make it easier for users to recover their nicknames, but when that is done too often the user will max out their connection limit and then Kiwi needs a restart so it's still quite an annoyance for an active chat I've tried finding where the cause might be in the code without luck so far

As a hacky workaround I I'll soon try to change Kiwi to disconnect users that aren't in any channels.

[cacheworks]

This seems to be resolved after I applied e0c7837a70912a285ca6b336b3aea03f0ec48a34 (and ab62611332ab8422bd07ec8a16c3c946c1591656 ) It has now been several days without any username getting ghosted.

[landergate]

@cacheworks Thanks for feedback! Unfortunately our users still have issues #723 , even after applying those particular patches. :person_frowning:

[prawnsalad]

@michaelforge Could you tell me a bit about your setup?

• Any reverse proxies? (nginx/apache/cloudflare/etc)
• Using SSL?
• Is it happening to everybody or just a select few? How many?
• Connections that get stuck, how are you detecting them? Can you CTCP TIME them?

[cacheworks]

Too bad that didn't solve your issue, but I believe this issue (#732) was solved as it's about persisting connections until Kiwi is restarted

In #723 you mentioned:

but user keep disconnecting only since 40-60 sec after closing browser tab.

Do your users lock up for long periods though?

Users will still sometimes take a few seconds to timeout (without the beforeunload quit) ,but they wont persist until Kiwi is restarted anymore

[landergate]

@cacheworks Yeah, the main different is about our users being disconnected in the end (after some long time). We don't experiencing persisting connections.

Thanks for mentioning, as firstly I thought it could be related.

@prawnsalad

Any reverse proxies? (nginx/apache/cloudflare/etc)

KiwiIRC behing nginx

nginx config:

    location / {
            proxy_set_header X-Real-IP  $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;

            proxy_pass http://10.0.8.40:7778;
            proxy_redirect default;

            # Websocket support (from version 1.4)
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
    }

Using SSL?

Yes.

Is it happening to everybody or just a select few? How many?

To everybody who closing their browser tab without manually disconnecting server by KiwiIRC interface (clicking cross icon on server's tab).

Connections that get stuck, how are you detecting them? Can you CTCP TIME them?

By reproducing it myself with any browser. CTCP TIME is not answering after user closing browser.

[Strategy47]

Is not solved ?

I use Nginx, inspircd, ssl users are not disconnected from the network the CTCP version/time are apparently null.