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> 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> 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 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 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> 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> >>>>> 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> >>>>>> 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
