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
