Bug: phantom users using BOSH with Openfire 3.7

I built a small test application in a brand new installation of Openfire 3.7.0. The application just connects and logs in a user using bosh, with the Strophe javascript api, using different resources.

When I hit F5, many connections from the same user are created (random resources are set). When the page is closed, the users still logged in, even if the browser is closed.

The code I used to connect:

Teste

Anyone?

Hello,

I had problems with this too, but then updated to the latest development version of strophe. The problem is that the 1.0.1 version has issues disconnecting from the server. You’ll need to apply a patch to make the development version work with Internet Explorer, check out the tickets.

daryl

Even if there is a problem with Strophe, tere is also a problem in Openfire because when the browser is closed, the server should identify that the connection no longer exists (the user still marked ‘online’ days after the browser is closed).

I am not using IE, I am using FF.

I am also having a similar problem (In addition to BOSH connections just going into a CONNFAIL state). The best solution I had was to set the ‘timeout idle clients’ to 60 seconds. It seems like anything lower than this doesn’t even get recognized by openfire (using 3.7.0).

Tim, default bosh polling will be for a period of 60 seconds, so setting it lower than that may not do anything. You should look at using punjab to bridge your users from BOSH clients to openfire.

It seems like an issue with Openfire, however, since I can completely close the browser running the Javascript that connects and it still takes at least 60 seconds to disconnect a client. Although, I will look into punjab. Thanks for the suggestion!

Is the property to set xmpp.httpbind.client.idle or xmpp.client.idle?

Is xmpp.httpbind.client.idle even a setting? I don’t see it listed by default in Openfire 3.7.

It is listed here: http://community.igniterealtime.org/docs/DOC-1061

1 Like

Oh wow - thank you for that link! Unfortunately, those two settings don’t seem to affect the timeout after a user closes the window on the client with the javascript.