Scalelite Meeting Expiry Problems: Fixing Long Meetings

Hey everyone, let's talk about a pretty gnarly issue some of you might be running into with Scalelite and those super long meetings. Specifically, we're diving deep into how the meeting expiry settings, introduced in version 1.6.6, can cause some headaches for deployments that like to keep the party going – even for more than a day! This is all about meeting expiry in Scalelite, and how it can affect your long-running virtual gatherings.

The Problem: Scalelite and the 24-Hour Meeting Limit

So, here's the deal. Since version 1.6.6, Scalelite started using a default Time-To-Live (TTL) for removing meetings from Redis. Think of Redis as a sort of memory bank that Scalelite uses to keep track of all the ongoing meetings. The problem? This default TTL can clash with users who intentionally keep their meeting rooms open for extended periods, using settings like "meetingExpireWhenLastUserLeftInMinutes=X." This setting is super handy, it allows meetings to persist even after everyone has left, perfect for ongoing projects or always-available virtual spaces. But, when that default TTL kicks in, and the meeting data gets wiped from Redis, things can get messy.

Imagine this: you've set up a meeting room that's supposed to stay open indefinitely. Everyone leaves, but the room should still be there, ready for the next person to pop in. However, because of this TTL, Scalelite might think the meeting is over and try to restart it on a different BigBlueButton (BBB) server when someone tries to rejoin. This means your participants could end up scattered across different servers, completely disrupting the flow and confusing everyone involved. This is a classic example of Scalelite meeting expiry causing issues. It's like the system forgetting where the party is supposed to be, and sending everyone to the wrong address. This is especially problematic for those using Scalelite-run deployments, as they might be more susceptible to this problem if not configured correctly. The core issue revolves around how Scalelite manages and persists meeting information, and how the default settings can interfere with custom configurations designed for extended meeting durations. The implications can range from minor inconveniences to complete meeting disruptions, making it a critical issue to address.

The Root Cause: Redis and the Default TTL

Let's get a little technical for a second. The heart of the issue lies in Redis, the in-memory data store that Scalelite uses. Redis is super speedy, but it's also designed to clean up data over time. The TTL is the mechanism that tells Redis how long to keep information around before deleting it. In Scalelite 1.6.6 and later, a default TTL was introduced for meeting entries in Redis. This means that after a certain amount of time, Scalelite automatically removes these entries. This is usually fine, but it becomes a problem when you want your meetings to live longer than that default time, especially if you're using settings like "meetingExpireWhenLastUserLeftInMinutes=2880" (which is 48 hours). If the TTL is shorter than the time specified in your meeting expiration settings, the meeting data will be deleted prematurely. Then, when a user tries to rejoin, Scalelite can get confused, thinking the meeting doesn't exist anymore, and potentially start a new instance of the meeting on a different server. This is where the core issue of Scalelite meeting expiry really surfaces: the system's default behavior doesn't align with the needs of users who want long-lasting meeting rooms.

Understanding the TTL

The TTL (Time-To-Live) is the key culprit here. The default TTL dictates how long the meeting information stays active in Redis. Once the TTL expires, the meeting data is removed. This means that if a user tries to rejoin a meeting after the TTL has expired, Scalelite may not recognize the existing meeting and may start a new one on a different server. This leads to participants potentially joining different servers for the same meeting, causing confusion and disrupting the user experience. The hardcoded nature of the TTL in current Scalelite versions exacerbates the problem, as it does not allow for customization based on specific deployment needs. This inflexibility prevents administrators from setting a TTL that aligns with the desired meeting duration, especially for meetings that are meant to last longer than 24 hours. The fix is to allow setting a custom value for the TTL. Without this feature, deployments relying on long-running meetings are forced to work around this limitation, potentially leading to instability and user dissatisfaction.

How to Spot the Bug

Okay, so how do you know if you're experiencing this issue? The symptoms are pretty straightforward:

• Participants Joining Different Servers: The most obvious sign is if users are ending up on different BBB servers when they try to rejoin the same meeting, this is a clear sign that Scalelite is not correctly identifying the existing meeting.
• Meetings Disappearing After Extended Absence: If you've set a long expiration time for your meetings (like "meetingExpireWhenLastUserLeftInMinutes=2880") and they're still disappearing after 24+ hours, the TTL is likely the problem.
• Unexpected Meeting Restarts: You might also notice meetings unexpectedly restarting, especially if no one is actively in the meeting but it's supposed to remain open. These are all critical signs of Scalelite meeting expiry issues in action.

To reproduce the issue, you can try this:

1. Set up a meeting room and configure it with a long meeting expiration time. For example, set "meetingExpireWhenLastUserLeftInMinutes=2880." This tells the server to keep the meeting active for 48 hours after the last user leaves.
2. Leave the meeting, but do not close the room. This simulates a situation where you want the meeting to remain accessible.
3. Wait for more than 24 hours. This is to ensure that the default TTL has expired. The longer the wait, the more likely the issue is. Since the TTL is set to a default value, the meeting is deleted from Redis after some time.
4. Try to rejoin the meeting after this period. If you end up on a different server or the meeting has been reset, you've likely encountered the bug. This is the core testing procedure to showcase the problems of Scalelite meeting expiry.

What Needs to Change: The Solution

The most important change needed is the ability to customize the TTL setting. The current hardcoded TTL is the root of the problem. Scalelite needs to allow administrators to set a custom value for the TTL. This way, users can align the TTL with their specific meeting duration requirements. The implementation should allow for a configuration option, perhaps in the Scalelite configuration file or through environment variables, where administrators can specify how long meeting entries should persist in Redis. This will directly address the issue by allowing for longer meeting durations and prevent premature deletion of meeting data. Providing control over the TTL would empower administrators to tailor Scalelite to their needs. A user can set a TTL that matches the "meetingExpireWhenLastUserLeftInMinutes" setting. For example, if a meeting is set to expire 48 hours after the last user leaves, the TTL should also be set to 48 hours or longer. This ensures that the meeting data remains in Redis for the expected duration. The option to disable the TTL completely would be another solution to offer flexibility in deployments that do not need automatic cleanup.

Impact of the Fix

Implementing a customizable TTL would significantly improve the user experience, particularly for those using long-running meeting rooms. Here's a quick rundown of the positive impacts:

• Improved Meeting Continuity: Users can rejoin meetings without being unexpectedly routed to new or different servers.
• Enhanced Reliability: The system will more accurately reflect the desired meeting persistence, reducing confusion and frustration.
• Greater Flexibility: Administrators will have the control to adapt Scalelite to their deployment’s specific needs. They can configure the TTL to match how long they want meetings to remain open.
• Reduced Support Tickets: Fewer users will encounter problems, leading to a reduction in support tickets and troubleshooting efforts.

Conclusion: Keeping Meetings Alive

In a nutshell, this is a critical issue. By allowing for a custom TTL setting, we can resolve the Scalelite meeting expiry problems, ensuring that those long-running meetings stay alive and kicking. The current situation, with its hardcoded default, isn't ideal for everyone, and it's essential that the developers address this. Stay tuned for updates and possible workarounds. Hopefully, a fix or a configuration option is on the way to resolve these issues, so meetings can last as long as they need to!