Why blocking weblogic.socket.Muxer Threads are acceptable in webogic?

Question

Ιs it really a blocking issue in my Application?

weblogic.socket.DevPollSocketMuxer.processSockets(DevPollSocketMuxer.java:92) shows blocking in thread analyzer , is it really a blocking thread I should worry about?

ExecuteThread: '3' for queue: 'weblogic.socket.Muxer'"   daemon prio=3 tid=0x0000000101f38000 nid=0x38 waiting for monitor entry [0xfffffffe40dff000]      
java.lang.Thread.State: BLOCKED (on object monitor)      at 
weblogic.socket.DevPollSocketMuxer.processSockets(DevPollSocketMuxer.java:92)      - 
waiting to lock <0xfffffffe70ec4898> (a java.lang.String)      at 
weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:29)      at 
weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:42)      at 
weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:145)      at 
weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)

EDIT:

I got a link explaining answer ( Which says its not an issue) but Not sure what purpose can a blocked Thread serve ? Why it is designed in this way? So changing title of question as below

Old Title- weblogic.socket.DevPollSocketMuxer.processSockets shows blocking in thread analyzer , is it really a blocking thread I should worry about?

New Title -Why blocking weblogic.socket.Muxer Threads are acceptable ? What purpose will it serve?

Yes I am aware of normal blocking , this is special case of 'weblogic.socket.Muxer' , not coming from the code I have written. — Vipin, Dec 06 '13 at 13:14

score 3 · Accepted Answer · edited May 23 '17 at 12:07

Observing Muxer threads to be blocked is not an issue and this is a normal behavior. You should not worry about this.

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. One Muxer thread is usually in the poll function, while the others are available to process requests. The polling thread is visible in a thread dump.

Here is more detail on this :

see Analyzing Thread Dumps in Middleware - Part 2 - a great post describing all different WSL thread dump situations - including Muxer threads. They say:

One can see that both ExecuteThread:'5' and '4' are belonging to the weblogic.socket.Muxer queue with ExecuteThread:'5' holding a lock on java/lang/String@0x17674d0c8 and ExecuteThread: '4' blocking for the same lock. The Muxer thread holding the lock is doing a native poll while other muxer threads are blocked as there can be only one thread doing poll on a set of fds.

Other resources:

Muxer thread tuning:

Even though the threads remain BLOCKED in your thread dump and you do not need to worry about this, you always need to check that you an appropriate number of threads allocated for your WLS instance - based on number of available cores per WLS instance. See Weblogic Tuning - Tuning Muxers.

Thanks for the answer I found it lot of places but the real answer was one liner "you can leave Muxer thread (It will always be blocked), as it will always be in polling state to serve the incoming request to the server" , well I aceept your answer as same ting you have given in another format which was not clear for me :) — Vipin, Dec 12 '13 at 11:12

Why blocking weblogic.socket.Muxer Threads are acceptable in webogic?

1 Answers1