Add support for JVB_MAX_MEM var

[goacid]

Fix to update over .env file the amount of memories of the videobridge java process.

[alexanderankin]

shouldnt this set the VIDEOBRIDGE_MAX_MEMORY instead, per the variable used in this file:

/usr/share/jitsi-videobridge# cat jvb.sh 
#!/bin/bash

if [[ "$1" == "--help"  || $# -lt 1 ]]; then
    echo -e "Usage:"
    echo -e "$0 [OPTIONS], where options can be:"
    echo -e "\t--secret=SECRET\t sets the shared secret used to authenticate to the XMPP server"
    echo -e "\t--domain=DOMAIN\t sets the XMPP domain (default: none)"
    echo -e "\t--min-port=MP\t sets the min port used for media (default: 10001)"
    echo -e "\t--max-port=MP\t sets the max port used for media (default: 20000)"
    echo -e "\t--host=HOST\t sets the hostname of the XMPP server (default: domain, if domain is set, \"localhost\" otherwise)"
    echo -e "\t--port=PORT\t sets the port of the XMPP server (default: 5275)"
    echo -e "\t--subdomain=SUBDOMAIN\t sets the sub-domain used to bind JVB XMPP component (default: jitsi-videobridge)"
    echo -e "\t--apis=APIS where APIS is a comma separated list of APIs to enable. Currently supported APIs are 'xmpp' and 'rest'. The default is 'xmpp'."
    echo
    exit 1
fi

SCRIPT_DIR="$(dirname "$(readlink -f "$0")")"

mainClass="org.jitsi.videobridge.Main"
cp=$(JARS=($SCRIPT_DIR/jitsi-videobridge*.jar $SCRIPT_DIR/lib/*.jar); IFS=:; echo "${JARS[*]}")
libs="$SCRIPT_DIR/lib/native/linux-64"
logging_config="$SCRIPT_DIR/lib/logging.properties"
videobridge_rc="$SCRIPT_DIR/lib/videobridge.rc"

# if there is a logging config file in lib folder use it (running from source)
if [ -f $logging_config ]; then
    LOGGING_CONFIG_PARAM="-Djava.util.logging.config.file=$logging_config"
fi

if [ -f $videobridge_rc  ]; then
        source $videobridge_rc
fi

if [ -z "$VIDEOBRIDGE_MAX_MEMORY" ]; then VIDEOBRIDGE_MAX_MEMORY=3072m; fi

LD_LIBRARY_PATH=$libs exec java -Xmx$VIDEOBRIDGE_MAX_MEMORY $VIDEOBRIDGE_DEBUG_OPTIONS -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djava.library.path=$libs $LOGGING_CONFIG_PARAM $JAVA_SYS_PROPS -cp $cp $mainClass $@

[goacid]

Yes this is also possible, but this variable is not yet retrieve over the env variable set in .env file.

[alexanderankin]

that is right, i forgot that i had just edited my docker-compose file as well

[saghul]

This won't work unless you declare it on docker-compose.yml

[dofl]

Would be nice if this can be commited, I need to be able to set this variable

[goacid]

Would be nice if this can be commited, I need to be able to set this variable

cherry-pick will help

[vetorialnet]

Hi,
there is a typo on 10-config (\n and /libs/viedobridge.rc)

diff --git a/jvb/rootfs/etc/cont-init.d/10-config b/jvb/rootfs/etc/cont-init.d/10-config
index 3cab1fb..5532ed5 100644
--- a/jvb/rootfs/etc/cont-init.d/10-config
+++ b/jvb/rootfs/etc/cont-init.d/10-config
@@ -20,7 +20,11 @@ if [[ ! -f /config/logging.properties ]]; then
fi

if [[ ! -z $JVB_JVM_MAX_MEM ]]; then

• echo -n "# The amount of memory that the java process can consume.\n# Use the format that is in use for java's -Xmx switch# The default is 3072m\n# Only effective on linux, 64 bit \nVIDEOBRIDGE_MAX_MEMORY=$JVB_JVM_MAX_MEM" > /usr/share/jitsi-videobridge/libs/viedobridge.rc

• echo "# The amount of memory that the java process can consume." > /usr/share/jitsi-videobridge/lib/videobridge.rc
• echo "# Use the format that is in use for java's -Xmx switch" >> /usr/share/jitsi-videobridge/lib/videobridge.rc
• echo "# The default is 3072m" >> /usr/share/jitsi-videobridge/lib/videobridge.rc
• echo "# Only effective on linux, 64 bit" >> /usr/share/jitsi-videobridge/lib/videobridge.rc
• echo "VIDEOBRIDGE_MAX_MEMORY=$JVB_JVM_MAX_MEM" >> /usr/share/jitsi-videobridge/lib/videobridge.rc
  fi

chown -R jvb:jitsi /config

[goacid]

@saghul : any improvement to perform ? or this PR is ok ?

[saghul]

Hum, can't we set it in the run file, as a generic Java prop?

[goacid]

Hum, can't we set it in the run file, as a generic Java prop?

I will ask a friend for that, unfortunately not a java dev

[johncadengo]

Is this a PR that's still relevant?

[saghul]

It no longer applies cleanly, so I'd say it needs a rebase at least.