Prosody bosh timeout issue?

Tested most of the stuff(our custom modules), seems working.


Still need to test the debian packages ^ before merging it

So the only changes I needed to do are the storage and mod_auth_token should hook to the global events.

Nice, thanks!

We are not using mod_auth_token, so only the storage change then. Will watch the version 0.11 and see if the problem goes away.

Just wanna to report back that I’m not seeing this issue anymore after the prosody upgrade. Hope it’s helpful for the others.

Sry for addressing this post after almost 1 year.

So last year we only use this conference tool in small groups. after that my colleagues use this conference too. i get a report that there is timeout issue when the user disconnect. it became zombie user and wont release.

When I try this in busy hour, they were right. the problem occur. But when i try this at early morning, the timeout is working just fine.

cpu & ram usage in jitsi-meet web server is still low
cpu & ram usage in jitsi-videobridge is still around 20%

my storage setting is “none”, when I change to memory, there is an error:

I tried to update the prosody to 0.11 but the user doesn’t met each other although the name of the room is the same. so i immediately roll back to prosody 0.10.

is there any idea?

Thanks

I think I’ve fixed it via changing

–archive_expires_after = “1w” – Remove archived messages after 1 week

to

archive_expires_after = “60s”

in :

/etc/prosody/prosody.cfg.lua

Seems just a failure in the distributed config file or a failure in Prosody, because the config file claims, that the mam-module is commented out and archive_expires_after is just a sub option of the mam-module.

Issue was: zombie participants left in a Itsi meet room for long time.

Hope that helps some people in this crazy times.

greetings

Andreas

1 Like

Thanks for reporting back Andreas! Interesting, archive_expires_after is a setting for message archive. You meant changing this will solve the ghost participants issue?

I thought the issue was gone for us, but maybe that’s because we switched to use websocket. After we reenable http-bind, it seems like the issue is back. So we are interested to learn potential solution as well.

Is it enough to change strophe timeout to match bosh_max_inactivity or other changes needed?