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