Room not destroyed after reservation duration is exceeded

We have a reservation API implemented using the following link Reservation System setup · Jitsi Meet Handbook.

When the duration of the conference expires, the reservation is not deleted and the room destroy event is not being called. I recall this working before (prior to reservation move to Prosody).
The reservation and room is deleted when all users hang up.

Could someone confirm that this is indeed the case?
We are running jitsi-meet release 2.0.6433
Prosody version 0.11.11-1~bionic1

We use this in our deployment and it works as expected.

I presume the API calls for room creation are being made successfully and you creation/rejection works as expected?

How have you installed the module. Can you share the relevant prosody config snippets?

Appreciate the quick response.
API calls for room creation work fine. Rooms are created fine.

In /etc/prosody/config.avail/myjitsidomain.cfg.lua
Under the
VirtualHost “myjitsidomain”
modules_enabled = {
“ping”; – Enable mod_ping
reservations_api_prefix = “http://MyAPIServer

And reservations module only added to one VirtualHost block, yes? I’m asking only because I’ve seen cases where duplicate loading of the module results in race conditions in room deletion logic.

Would you mind sharing relevant prosody logs just so we can figure out the sequence of events. Perhaps grep for “reservations” and on room jid of a room that you exceeded duration.

Yes, reservations module is added to only one VirtualHost block.

The prosody log only has only 1 line for the room in question after using grep reservation

Reservation created successfully for spemmara-533@conference.myjitsidomain

On other rooms where users have left the meeting intentionally I see 2 lines
Feb 16 19:56:04 myjitsidomain:reservations info Reservation created successfully for test-531@conference.myjitsidomain
Feb 16 19:59:01 myjitsidomain:reservations info Dropped reservation data for destroyed room test-531@conference.myjitsidomain

One question, are you using the reservations module with no options specified like I am doing? I only have the api_prefix and nothing else.

Hmm… if you are seeing the “Dropped reservation data for destroyed room” logs that means the reservations table is being populated so that rules out one possibility.

Next hypothesis would be that either the periodic expiry_check_period call is not being scheduled, or these some discrepancy between server time and timings returned by API. To rule out these, could you:

  1. Add some logging at this point and restart prosody? After that, we’d expect to see that log being output every 60 seconds.
  2. Check your server time is correct.
  3. Check that the start_time and duration returned by your endpoint is as expected. N.B. expiry time is calculated relative to start_time returned by endpoint and not the time the request was made.

Almost. On my deployments we set reservations_api_prefix and reservations_api_timeout which should not make a difference to the expiry logic.

Appreciate your quick reply again. Thanks much!

I took a look at the prosody log again. This time with grep ‘reservation duration’ and I did see the lines
Feb 16 22:09:23 myjitsidomain:reservations info Room exceeded reservation duration. Terminating a-535@conference.myjitsidomain
Feb 16 22:39:18 myjitsidomain:reservations info Room exceeded reservation duration. Terminating test-531@conference.myjitsidomain
So that part is working okay.

But, I noticed that I was getting error messages from a custom module (SFT) we wrote to talk to our API on muc events such as (room created/destroyed and participant joined/left). This errors I assume prevent the participants from being evicted and consequently the room destroy event is not called.

The log is as follows.

Feb 16 22:39:18 myjitsidomain:reservations info Room exceeded reservation duration. Terminating test-531@conference.myjitsidomain
Feb 16 22:39:18 conference.myjitsidomain:sft info sft muc-occupant-left event triggered
Feb 16 22:39:18 conference.myjitsidomain:sft info sft muc-occupant-left event triggered. Room = test-531@conference.myjitsidomain, Occupant = spemmara@myjitsidomain
Feb 16 22:39:18 conference.myjitsidomain:sft info In PostTOAPIEx http://OurAPI:5000/occupant/left/test-531@conference.myjitsidomain/spemmara@myjitsidomain
Feb 16 22:39:18 timer error Traceback[timer]: /usr/lib/prosody/util/async.lua:9: Not running in an async context, see util.async – Prosody IM
stack traceback:
[C]: in function ‘error’
/usr/lib/prosody/util/async.lua:9: in function ‘checkthread’
/usr/lib/prosody/util/async.lua:69: in function ‘waiter’
/usr/lib/prosody/modules/mod_sft.lua:52: in function ‘http_get_with_retry’
/usr/lib/prosody/modules/mod_sft.lua:114: in function ‘postToAPIEx’
/usr/lib/prosody/modules/mod_sft.lua:241: in function ‘?’
/usr/lib/prosody/util/events.lua:79: in function </usr/lib/prosody/util/events.lua:75>
(…tail calls…)
/usr/lib/prosody/modules/muc/muc.lib.lua:882: in function ‘clear’
/usr/lib/prosody/modules/muc/muc.lib.lua:893: in function ‘destroy’
/usr/share/jitsi-meet/prosody-plugins/mod_reservations.lua:504: in function ‘evict_expired_reservations’
/usr/share/jitsi-meet/prosody-plugins/mod_reservations.lua:517: in function </usr/share/jitsi-meet/prosody-plugins/mod_reservations.lua:516>
[C]: in function ‘xpcall’
/usr/lib/prosody/util/timer.lua:41: in function ‘callback’
/usr/lib/prosody/net/server_select.lua:885: in function ‘?’
/usr/lib/prosody/net/server_select.lua:916: in function </usr/lib/prosody/net/server_select.lua:908>
[C]: in function ‘xpcall’
/usr/bin/prosody:76: in function ‘loop’
/usr/bin/prosody:86: in main chunk
[C]: in ?

Any ideas?
I use a function similar to async_http_request function call from

to post to my API.

Thank you.

You’re right. It does look like the reservation module is doing the right thing but the custom module you have installed is breaking the room:destroy() call.

I presume it works as expected if your disable your SFT module?

In my deployment, we use mod_reservations along with event_sync and everything plays together nicely so you issue will likely be down to the implementation of SFT.

Not sure I’m the best person to debug that, but happy to have a look if you can share the following:

  • Implementation of http_get_with_retry
  • How you are hooking your function to muc-occupant-left event

Sorry, but with all the indentation and formatting stripped out, it’s a little hard to follow.

I’m a Lua newbie so take this with a pinch of salt, but one thing that struck me is that you’re using async.waiter as well as net.http.request which is already async. Is the waiter() required?

How about if you copy over async_http_request from here and just do something like:

local function postToAPIEx(url)
    async_http_request(url, {method = "POST"}, nil, nil, 1);

I used as my base and modified it to fit our existing API that deals with room and occupant events.
Initial testing indicates that it seems to be working. I will let you know if any issues come up.

Thank you so much for the mod_event_sync_component.

best regards.

I will also try this and post how that worked out.

1 Like

I did as you suggested - copied the async_http_request and made minor changes to my code to use it. It works as expected now.

Your help is greatly appreciated.
Thank you.

You’re very welcome.

Glad your issue is resolved :+1: