I would not spend too much time on it. It is looking like it is Flash
related and not on the OM side.
On 1/18/19 9:35 AM, Maxim Solodovnik wrote:
weird enough this issue was not reproducible on my local machine
(Chrome+Chromium)
Will do some tests
On Fri, 18 Jan 2019 at 08:20, Maxim Solodovnik <solomax...@gmail.com
<mailto:solomax...@gmail.com>> wrote:
Thanks for the video
Will try to reproduce this issue today (it also might be caused by
red5 update ....)
Could you please start another thread regarding OM5 configuration
On Fri, 18 Jan 2019 at 00:45, Aaron Hepp <aaron.h...@gmail.com
<mailto:aaron.h...@gmail.com>> wrote:
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 <aaron.h...@gmail.com
<mailto:aaron.h...@gmail.com> 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
<aaron.h...@gmail.com <mailto:aaron.h...@gmail.com> 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
<aaron.h...@gmail.com
<mailto:aaron.h...@gmail.com>> 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
<solomax...@gmail.com
<mailto:solomax...@gmail.com>> 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
<aaron.h...@gmail.com
<mailto:aaron.h...@gmail.com>> 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
--
WBR
Maxim aka solomax
--
WBR
Maxim aka solomax
