|
tom quas opened 1 decade ago
|
|
|
sorry for the crappy formatting; why the heck has every wiki have to have it's own syntax? |
|
I think this is not MUC problem. Rather this is problem of Tigase Server (BOSH module?). |
|
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:
|
|
|
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 |
|
|
can you confirm this behavior? can i provide anything else to support you guys? |
|
|
I am sorry we are occupied right now and we will get back to it as soon as possible. |
|
|
Cannot replicate the problem and we have to little information about it to proceed with investigation. |
| 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