Hello
We're having trouble deploying the latest version of the WebCallServer (5.2.944) on AWS.
When deploying a WebCallServer, we also mount Amazon's EFS to the records directory so that we can have multiple WebCallServers sharing the same network file system.
However when deploying the latest version it fails to restart the WCS successfully since after waiting a minute for the command to execute and continue, we cannot access the demo page. We can still ssh into the server but running
This only seems to happen when a particular EFS is mounted:
Works fine when deploying without EFS.
Works fine when deploying with EFS (Total Size: ~50GiB).
Fails when deploying with EFS (Total Size: > 300GiB).
Regarding the deployment with EFS of 300GiB, it failed to finish restarting the WCS successfully, but then after about 15 minutes from executing the command we could then access the demo page and do stream recording fine.
We have also tested changing the
---
We would greatly appreciate help in figuring out why restarting the WCS takes so long with EFS and if there's a solution that doesn't drastically change our architecture.
The
Configurations:
WCS Version: 5.2.944
AMI: Amazon Linux 2 AMI (SystemD246)
Instance Type: t3a.medium
EFS: Enabled
Flashphoner Properties:
Java Memory Settings:
We're having trouble deploying the latest version of the WebCallServer (5.2.944) on AWS.
When deploying a WebCallServer, we also mount Amazon's EFS to the records directory so that we can have multiple WebCallServers sharing the same network file system.
However when deploying the latest version it fails to restart the WCS successfully since after waiting a minute for the command to execute and continue, we cannot access the demo page. We can still ssh into the server but running
top
in the terminal window doesn't show 'java' as one of the active processes running.This only seems to happen when a particular EFS is mounted:
Works fine when deploying without EFS.
Works fine when deploying with EFS (Total Size: ~50GiB).
Fails when deploying with EFS (Total Size: > 300GiB).
Regarding the deployment with EFS of 300GiB, it failed to finish restarting the WCS successfully, but then after about 15 minutes from executing the command we could then access the demo page and do stream recording fine.
We have also tested changing the
record_dir
property to "/usr/local/FlashphonerWebCallServer/records_efs" and creating a directory there and mounting it. This seems to work fine too (restarting WCS responds much faster).---
We would greatly appreciate help in figuring out why restarting the WCS takes so long with EFS and if there's a solution that doesn't drastically change our architecture.
The
record_dir
is the best solution we currently have but since we need to access files in that mounted directory, that'll require deploying something new to access the recorded files from the EFS (and having someway to determine which EFS to fetch from) and thus not an ideal solution for us.Configurations:
WCS Version: 5.2.944
AMI: Amazon Linux 2 AMI (SystemD246)
Instance Type: t3a.medium
EFS: Enabled
Flashphoner Properties:
Code:
stream_record_policy_template={streamName}
wss.port=443
ws.port=80
periodic_fir_request=true
record_audio_codec_channels=1
file_recorder_thread_pool_max_size=8
Code:
-Xms2g -Xmx2g
-XX:+UseConcMarkSweepGC
-XX:NewSize=256m