HandlerThreadPool and TransportThreadPool

[wolfza]

I just want to clarify if I understand it correctly that these 2 thread pools handles incoming events, does it mean that whenever a connect request is made it will create one thread in the pool? Once the connection is satisfied that thread is dropped from the pool? I was observing the the currentActive and Que size from JConsole and it seem that threads are getting created then dropped immediately too, but in some point let say the server is bombarded by 500 connect requests simultaneously, the current thread pool would jump to reach the 240 limit (for quad core) and the quesize increases too, from what I understand those ones in the que are waiting for a slot in the pool to get freed to be able to get processed, am I correct? So when this happens where the current and que size is bigger than the maximum 240, the client would take forever to connect because the current count would hold until and appears that the server is frozen but actually the connections gets stuck in the que. Please enlighten me if my observation is correct.

[charlie]

The threads are you for small bits of work and are not allocated per connection. So there is no issue if there is a large influx of connects. They will be serviced as fast as possible.

Charlie

[wolfza]

What it is then that is getting created in the threadpool? My application is not using any threadpool calls at all but there seem to be something getting caught in the pool at some point which causes wowza to not respond to connect. Any clue what else using threadpool when not call in the application code?

[wolfza]

also another question, on the tuning guide:
For low latency chat applications, it is best to use smaller socket buffer sizes (16000 bytes for read and write). The socket buffer sizes are configured in [install-dir]/conf/VHost.xml

does it mean it is recommended to set higher value for normal live streaming application, any recommended values?

[charlie]

Please explain the problem you are having. It most likely has nothing to do with the threadpool.

The default socket sizes are correct for one to many live streaming. That is why no additional values are suggested.

Charlie

[wolfza]

sorry, but as I mentioned there is a certain point in time that wowza responds very slow or does not respond at all, then when I checked in JConsole I can see the the threadpool reaching the maximum 240 and quesize going up as well, memory heap, cpu, etc. are not in high level only the threadpool seems to be choking.

[charlie]

This indicates a couple potential issues:

1. The network is backed up which will cause jobs to run more slowly.
2. The process is not fast enough
3. There is some kind of lock contention

What version of Wowza are you running. What are the hardare, Os and Java specifics? What processor is in the machine? How is hte machine connected to the internet (speed)?

Charlie

[wolfza]

DELL 1950
CPU: Quad Core Xeon 1.66
Memory: 4gb
Harddrive: 73GB SAS
Raid: RAID0
NIC: 1Gbps
OS: CentOS 5.x
Wowza: 2.2.3
Java: Hotspot VM 64
All fine tuning guidelines applied including Java memory heap, garbage collection, etc.

[rrlanham]

answered on support ticket

[Patrick Lie]

Hi, sorry to resurrect this old thread, but we are experiencing a similar issue where client connects appear to be getting backed up (it takes > 20 seconds for onConnect to be called). I'm very interested to know what the solution or issue was in the mentioned support ticket.

Thanks,
Patrick