tom quas opened 1 decade ago
-
There was a bug in version beta1 and earlier which could cause similar problems. It was fixed in version about beta2 - beta3. So either the version used by the user was earlier or the bug still exists. I distinctly remember testing this case for one customer and this was working fine.
I used Jaxmpp2 library to generate both standard XMPP connections and Bosh connections and unavailable presence were sent correctly.
One of the problem with strophe is that when it runs under a web browser like IE, when the window is closed, IE sometimes still runs the javascript code in background for some period of time. Hence the client may still be online in fact.
Wojtek, could you please rerun tests using Jaxmpp2 library and test the MUC scenario provided by the user?
-
i'm 100% certain that i'm running 5.1b3.
your hint with background processes was a good one, so i repeated my scenario and killed the browser process. still, the unavailable message only got delivered way after the BOSH session timeout and only when there was new activity in the room.
-
Ah, so the unavailable presence was delivered in fact! That's a good news. Could you tell us an approximate time between killing browser and presence unavailable delivery? There is a few timeouts in Bosh, inactivity, wait, etc... so maybe they sum up in some cases.
Also, to be sure we have as much information as possible. Could you also test following scenario:
-
Make the Bosh user a friend with some other user connected via standard XMPP
-
The user connected via standard XMPP is online so you can see status changes for Bosh user
-
Run your usual MUC scenario
-
Check whether the unavailable presence is delivered at the same time to the user connected via standard XMPP and to the MUC room
-
-
from the listener script logs we can see that the unavailable message for 8a1 arrived after new activity in the room (bba joined); that order looks wrong to me:
10:10:44 <8a1> joined
10:12:23 [killed 8a1's environment, bosh/max-inactivity=60]
10:13:23 [expecting the unavailable message for 8a1]
10:17:45 joined
10:17:45 <8a1> left
| Type |
Bug
|
| Priority |
Critical
|
| Assignee | |
| RedmineID |
160
|
| Version |
tigase-server-5.1.0
|
env: tigase 5.1b3
setup:
several room occupants connected via port 5222 (simple ruby xmpp4r scripts)
one BOSH client (Strophejs)
actual behavior / steps to reproduce:
let port-5222-clients enter the room
let BOSH client enter same room - all port-5222-clients receive presence=available
kill BOSH client to trigger BOSH session timeout, do not let it disconnect properly
the time specified in bosh/max-inactivity goes by, no presence=unavailable received by port-5222-clients
connect a new client
the presence=unavailable stanze of BOSH client is being delivered
the current impression is that a BOSH client is still available for chat when this is no longer true
expected behavior:
BOSH client's presence=unavailable should be pushed to all occupants remaining in the room immediately