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?


I think I’ve fixed it via changing

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


archive_expires_after = “60s”

in :


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.



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?

Hi Damencho,
I have a couple of questions about the Jitsi Meet. Once the participant joined the call and started the call, is the client keep the connection with the server directly? Somewhere I found that it is using pubsub architecture, so that means after a call started if the Jitsi Server is out of connection then the call will not be continued. Correct me If I am wrong.

Waiting for your reply.

Not sure what you mean by pubsub, xmpp pubsub?

Not sure what your question is?

Ok, my question if the call started then do we need to keep the connection with the Jitsi server?

Yes, the connection is constant … on internet interruptions it reconnects, sometimes there are unrecoverable errors which will cause page reload and all this is for signalling.
I don’t understand how if you drop the connection, the call will continue … all participants are sending media to jvb and are receiving media from it, without that connection there is no conference.