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