More > JRiver Media Center 31 for Linux
JRiver Panel/MCWS stops serving over HTTPS after a large amount of requests
danrien:
--- Quote from: bob on September 19, 2023, 01:50:14 pm ---Something like if there were thousands of sockets in time_wait state or similar.
--- End quote ---
I do not see anything related time_wait, the vast majority (if not all) of the connections are in the "Connected" state.
--- Quote from: mattkhan on September 19, 2023, 12:11:15 pm ---I would look at the browser console as well to see what it reports
--- End quote ---
The browser eventually just reports a connection timeout error...
I recorded a video if you are looking for some exciting Friday night entertainment... top left is the Firefox developer tools, top right is a `tail -f` of the media center logs, bottom right is just the top command running, and bottom left is me crazy scrolling through the playlist view. Interestingly, loading large resources such as images seems to trigger it sooner.
https://photos.app.goo.gl/p38XvpGvwKWBwwVs6
Happily, I got SSL working through an nginx reverse proxy to the Media Center HTTP port, so this is now a non-issue for me, but if there's a fix it would definitely simplify things for me.
mattkhan:
running debian testing/kde
I have reproduced this using firefox (but only the 1st time I tried this, subsequent attempts didn't fail)
I have not reproduced it using chrome at all
IMO this is a panel issue in the first instance, I think its throttling/debounce code is not working efficiently, which leads to a massive number of completely unnecessary requests & the number of these varies significantly between chrome & firefox.
My highly scientific way to test this is as following
open large playlist (mine has ~15k items in it)
open it in browser
hold down the page down key until you get to the bottom of the list
in chrome, this consistently results in ~8k requests of which I actually needed just the 1st and last page
in firefox, this consistently results in about 50% more requests (~12k)
once I get to the bottom of the list, if I scroll back up then it starts making the same requests again so there must be zero caching in here (i.e. the viewport is just the visible area) and if there is a throttle, it's really not working properly.
MC completely falling over is a different problem but probably you could test this properly by taking panel out of hte equation and writing a load script that batters MC with GetInfo?File=XXX requests from multiple threads and see if it you can break it
bob:
Also please verify that the issue is only with https.
mattkhan:
the main difference between chrome and ff is that chrome is visibly faster to scroll so makes fewer requests, there's definitely some sort of missing debounce on scroll though (or similar)
I can't reliably reproduce this on FF so probably the OP has to confirm https vs http
danrien:
--- Quote from: bob on September 24, 2023, 12:02:52 am ---Also please verify that the issue is only with https.
--- End quote ---
I have only reproduced this on HTTPS.
Navigation
[0] Message Index
[*] Previous page
Go to full version