Recent content by SLM

No more issues concerning unresponsiveness after update to version 1924, so that's great. Thanks. I'm still seeing the socketexceptions in the logs though and sometimes quite a lot: 21:00:00,029 WARN StunUdpSocket - STUN-UDP-pool-40-thread-1749 [id: 0x5935f9c6, /172.xx.xx.xxx:31618]...

Thanks. Current values after these rmem settings are now: net.core.rmem_default = 26214400 net.core.rmem_max = 26214400 net.ipv4.tcp_rmem = 4096 87380 6291456 net.ipv4.udp_rmem_min = 4096 I will monitor the situation the next 48 hours

Can I do this UDP socket buffer tuning while WCS is running and handling streams? Or do I need to stop the service first? Will it retain these values at server reboot ? Are there any downsides of this setting: ice_tcp_transport=true

Thank you Max. I've updated the server yesterday and it's running for 24 hours now. However, I'm seeing a few strange values in the WCS stats: core_java_totalPhysicalMemorySize = 16318554112 core_java_committedMemory = 426256351232 core_heap_memory_used = 526385152...

I've sent a second report. This time from the other server (with ZGC setting) on version v.2.0.240-5.2.1920 which saw the same issue after just 5 hours. CPU spiked to 100% and then Flashphoner refused all streaming connections even when CPU went back to 0.

I've sent the report. The ZGC was not yet configured on this server. Traffic is now on another server with that configuration.

Yes, I figured that out after I posted the edit. Complete result is too big to post in here. I see mostly RUNNABLE and TIMED_WAITING

No, currently the following (default/unchanged) is in wcs core: -XX:ErrorFile=/usr/local/FlashphonerWebCallServer/logs/error%p.log -Xlog:gc*:/usr/local/FlashphonerWebCallServer/logs/gc-core-:time # Use System.gc() concurrently in CMS -XX:+ExplicitGCInvokesConcurrent # Disable System.gc() for...

Jmap is reachable but the Jstack command is not found. Current java version: openjdk version "14.0.1" 2020-04-14 OpenJDK Runtime Environment (build 14.0.1+7) OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing) ------------------------- EDIT (2):/ Sorry, jstack command was not in...

Unfortunately the problem happened again. It took longer this time to get to the point of unresponisveness and the server wasn't totally unresponsive but the CPU fluctuated rapidly but constantly from 1 to 100% and this did not stop even when all sessions and streams were diverted to another...

After a WCS update to v.2.0.239-5.2.1914 we experienced that both our Flashphoner EC2 instances became unresponsive after a several hours. Streams were not handled anymore, publishers' sessions were interrupted and REST API access timed out. This happened both on a m5.xlarge (4vCPU, 16GB) and a...

I have sent the reports from both servers to support@flashphoner.com. Please note that the log I sent yesterday via the form was an old log file which is not present at that server at the time of the report and that its WCS version had also been updated after cutting all the traffic from that...

Can we also close TCP ports 8445 and 8082 ? I don't think it's a Dos attack however because after we switch the traffic from our sites to the other server the logs do not grow that much. I will collect this tomorrow

I have uploaded an old log file via the form. Also included a link to a client log of which there are also a lot: bad-request-HLS-[id] which is weird because we don't use HLS. I'm not sure but on the manually installed server I think it was 5.2.1744 and on the Flashphoner AMI it was 5.2.1825...

This seems to be working on one of the servers (with the hourly AWS license). This TCP setting was missing in the predefined rules list. However, this TCP setting was/is present on the other (manually installed) EC2 server and besides the Flashphoner WCS update nothing changed there and it was...