[jbossweb] LOW ON THREADS: SocketListener@0.0.0.0:8080

[sysuser1]

I'm getting this warning when I run a single user continuously on a Web App:
13:16:12,244 INFO [jbossweb] LOW ON THREADS: SocketListener@0.0.0.0:8080

I configured the Jetty socket listener as follows:





64
64
30000
5000




How is this low on threads ? Why will the server require more than 64 threads if I'm just running a single user ?

Thanks!
Trev

[jonlee]

The test for low threads is:
getThreads()==getMaxThreads() &&
getIdleThreads()<getMinThreads()

Setting high and low watermarks to the same value is not going to make the socket listener a happy camper.

[sysuser1]

Okay thanks! My intent in setting it the same is since I know my expected workload and dont want additional creation of threads so I'm setting it to a min and max of 64. I'm assuming JBoss works the same way as WLS whereas if there are no idle threads, and new requests come in, requests will go to the queue, or is it not ? What are the guidelines for setting the min and max for threads if you want to work with a predifined set of threads to avoid any additional creation and destuction of threads and mimimizing context switching ? This is really a benchmarking scenario why I'm doing it this way.

thanks,
Trev

[jonlee]

The socket settings you are using effect the servlet container, Jetty. I'm not sure that there are any thread tuning settings in JBoss - could be wrong here, so someone can jump in at any time. You do get some fine-grained control on the EJB side of things by setting pool maximums and minimums (for stateless session beans) and that sort of thing.

With Jetty, reading the socket listener code, essentially it says that the minimum setting defines the minimum number of idle threads there should be and if there are less than that many idle threads, indicate a "low on threads" status, and start enforcing the persist timeout. The maximum says that these are the maximum number of threads that should ever be created to service requests.

It is up to the Jetty container to generate threads and manage them to meet the criteria. So you can't control the start point for threads - however, in steady state, connection persistence will help smooth resource churn if your application has medium to long user sessions.

Hope that helps.