We are observing one of the “weblogic.socket.Muxer” threads is in “Waiting on Condition” state for the managed server and the other Muxer threads in “Blocked” state when thread dumps were taken. Is this is a normal condition?
The behavior you’re describing is normal. The muxer threads contend for the poll lock to poll on the file descriptors, so a large number of threads does not add any benefit. In fact a lower number of such threads will ensure less thread contention for the lock. The muxer threads are very fast, and don’t do a whole lot of work.
The default number of muxer threads is the number of CPUs on the machine + 1. However, that’s been the default for a long time and when it was established, most machines didn’t have more than 1 or 2 CPUs. On machines with more CPUs than that, we often recommend that customers reduce the number of muxer threads from the default. Based on certain SpecJ benchmarks carried out by the performance team, we usually recommend about 3 to 4 muxer threads. You would normally experiment with the values and figure out the best setting for your system.
You set the number of muxer threads by a java option at system start up:
Where XX is the number of threads to allow. Edit your JAVA_OPTIONS so that it takes effect when you start the system.