Here is logging out of the demo room and logging right back in.
http://recordit.co/YtGlxUzNai
On 1/17/19 12:09 PM, Maxim Solodovnik wrote:
You have to be root to run tomcat on port 443
Other than that there should be no issues, just invalid certificate
(at least if you will access it using localhost)
Will try to perform run on port 443 tomorrow
On Thu, Jan 17, 2019, 23:52 Aaron Hepp <[email protected]
<mailto:[email protected]> wrote:
It would be pure Tomcat. I was playing around with it over the
weekend. I got it to load on 5443 but it never accepted the cert,
when I changed it to 443 I don't think it ever opened up the port.
I thought I had changed the settings it was looking for on the
location of the PEM files.
On 1/17/19 11:46 AM, Maxim Solodovnik wrote:
Sure :)
I'll help you to set everything, hope this will help to create
documentation ;)
Are you interested in pure tomcat based config or do you have
frontend Apache?
Actually all have to do is to set up https on tomcat :)
Packaged version of om works as expected on port 5443 by default
So you can check https without any additional steps
On Thu, Jan 17, 2019, 23:33 Aaron Hepp <[email protected]
<mailto:[email protected]> wrote:
I will test those in a little bit. Currently in the VPS I
run the delay is now over a minute from the person broadcasts
to when the guests hear it. The memory on the VPS has only
gone up about 300MB since people started coming in @ 8:30am
EST (so about 2 hours of running).
I have an active stream going in both 4.0.7 and the
4.0.8snap will watch them to see if they all start having
the same delay affect.
Oddly the screen sharing which uses the same port (1935) does
not experience the delay. So this may possible be leading to
a flash issue and not an OM issue.
I was going to start testing version 5 since that does away
with flash, but noticed the different file structure in there
for getting https to work. Do you have a quick how to on
setting up version 5 on 443?
On 1/17/19 10:28 AM, Maxim Solodovnik wrote:
Thanks Aaron,
both 4.0.7 and 4.0.8 are available for testing
I would appreciate if you can check both versions :)
On Thu, 17 Jan 2019 at 19:37, Aaron Hepp
<[email protected] <mailto:[email protected]>> wrote:
On the demo (4.0.8 rb66ef46) there is only about a 5-7
second delay from the talking till it is broadcasted
(this would be expected depending on where the servers
are located and the speed of its connection). Currently
about the same delay I have on a fresh restart of the OM
service on my VPS. I will keep both open all day and
see if the delay changes any.
On 1/16/19 11:01 PM, Maxim Solodovnik wrote:
Hello Aaron,
According to `top` our two OM instances consuming not
very much memory on demo:
1186 nobody 20 0 6716968 1.421g 23308 S 20.9
6.0 1116:35 java
25008 nobody 20 0 6647688 752492 26656 S 1.0
3.0 97:29.05 java
4.0.7 consuming 1.4G (was started right after release,
more than 2 weeks ago), will additionally check audio delay
java options used differs:
4.0.7:
export JAVA_OPTS="-Xrs -Xms4G -Xmx4G -Xss1M
-XX:PermSize=192m -XX:MaxPermSize=512m
-XX:+CMSClassUnloadingEnabled -XX:NewSize=256m
-XX:SurvivorRatio=16 -XX:MinHeapFreeRatio=20
-XX:+ExplicitGCInvokesConcurrent
-XX:+UseConcMarkSweepGC -Djava.net.preferIPv4Stack=true
-Xverify:none"
4.0.8
export JAVA_OPTS="-Xrs -Xms4G -Xmx4G -Xss1M
-XX:+CMSClassUnloadingEnabled -XX:NewSize=256m
-XX:SurvivorRatio=16 -XX:MinHeapFreeRatio=20
-XX:+ExplicitGCInvokesConcurrent
-XX:+UseConcMarkSweepGC -Djava.net.preferIPv4Stack=true
-Xverify:none"
4.0.8 options looks better to me.
Could you also check demo?
I'll update "next" with most recent build (with most
recent wicket)
On Thu, 17 Jan 2019 at 10:12, Maxim Solodovnik
<[email protected] <mailto:[email protected]>> wrote:
Hello Aaron,
I'm afraid this might be caused by this
https://issues.apache.org/jira/browse/WICKET-6629 issue
I'll try to double-check on our demo server, and
maybe speed up next releases of both wicket and
openmeetings
Thanks for the report
On Thu, 17 Jan 2019 at 07:16, Aaron Hepp
<[email protected]
<mailto:[email protected]>> wrote:
Looks like this has started with 4.0.7, but
will need to look into further. On Sunday I
restarted my VPS (Ubuntu 16.04 core 4vCPU and
6GB memory) The only applications I have
running on this one is the items needed to run
OpenMeeting (java, libreoffice, etc) When I
start up the process the memory hovers around
850MB. During the day people come and go max
at any given time is 15. Only one room; items
in that room are chat, a screen share, and a
single mic broadcasting. At the end of the day
after everyone is out and the items stopped
(screenshare and mic) the memory usage reports
around 1.5GB. The next day everyone comes and
goes as previous day idle memory after everyone
is gone is 2.1GB, today idle was running @
2.5GB. What I have noticed is that usually on
the 2nd delay there starts being a delay in the
mic. Audio is broadcast but there is about a
30 second delay. Today was got all the way up
to about a minute delay when the audio would be
broadcasted and it gets heard by the users. So
tonight I was testing and the 1min audio delay
was still there. Stop and started the red5
process re-entered the room and the delay was
gone. I have included the options in the red5
file to maybe I could need some tweaking. As
stated this did not really show up till this
4.0.7 as there had been times the process had
ran for weeks without being restarted and the
memory usage would never get above 2GB.
JVM_OPTS="-Xms1024m -Xmx4096m -Xverify:none
-XX:+TieredCompilation -XX:+UseBiasedLocking
-XX:InitialCodeCacheSize=8m
-XX:ReservedCodeCacheSize=32m
-Dorg.terracotta.quartz.skipUpdateCheck=true
-XX:MaxMetaspaceSize=128m
-XX:+DisableExplicitGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=4"
--
WBR
Maxim aka solomax
--
WBR
Maxim aka solomax
--
WBR
Maxim aka solomax
