What is weblogic.socket.Muxer?

Question

Does any of you understand what weblogic.socket.Muxer is used for in WebLogic 8.1?

Often in thread dumps I see stack traces similar to this:

"ExecuteThread: '0' for queue: 'weblogic.socket.Muxer'" id=20 idx=0x68 tid=26709 prio=5 alive, in native, blocked, daemon
    -- Blocked trying to get lock: java/lang/String@0x2b673d373c50[fat lock]
    at jrockit/vm/Threads.waitForUnblockSignal()V(Native Method)
    at jrockit/vm/Locks.fatLockBlockOrSpin(Locks.java:1675)[optimized]
    at jrockit/vm/Locks.lockFat(Locks.java:1776)[optimized]
    at jrockit/vm/Locks.monitorEnterSecondStageHard(Locks.java:1312)[optimized]
    at jrockit/vm/Locks.monitorEnterSecondStage(Locks.java:1259)[optimized]
    at jrockit/vm/Locks.monitorEnter(Locks.java:2439)[optimized]
    at weblogic/socket/EPollSocketMuxer.processSockets(EPollSocketMuxer.java:153)
    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)
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)
    -- end of trace

It's not that I have any problems with that, it is just intresting to understand:

1) what is it doing?
2) can it affect any performance?

Absently

The word "muxer" is a contraction of the word "multiplexer". The thing you're seeing is an internal Weblogic class. Sorry, I don't know why you get those errors. – Gemmulation

It's not an error, it just a stack trace cut from a thread dump. – Absently

Answer 1

From the documentation (http://download.oracle.com/docs/cd/E13222_01/wls/docs100/perform/WLSTuning.html#wp1152246):

WebLogic Server uses software modules called muxers to read incoming requests on the server and incoming responses on the client. These muxers are of two primary types: the Java muxer or native muxer.

A Java muxer has the following characteristics:

• Uses pure Java to read data from sockets.
• It is also the only muxer available for RMI clients.
• Blocks on reads until there is data to be read from a socket. This behavior does not scale well when there are a large number of sockets and/or when data arrives infrequently at sockets. This is typically not an issue for clients, but it can create a huge bottleneck for a server.

Native muxers use platform-specific native binaries to read data from sockets. The majority of all platforms provide some mechanism to poll a socket for data. For example, Unix systems use the poll system and the Windows architecture uses completion ports. Native provide superior scalability because they implement a non-blocking thread model. When a native muxer is used, the server creates a fixed number of threads dedicated to reading incoming requests. BEA recommends using the default setting of selected for the Enable Native IO parameter which allows the server automatically selects the appropriate muxer for the server to use.

If the Enable Native IO parameter is not selected, the server instance exclusively uses the Java muxer. This maybe acceptable if there are a small number of clients and the rate at which requests arrive at the server is fairly high. Under these conditions, the Java muxer performs as well as a native muxer and eliminate Java Native Interface (JNI) overhead. Unlike native muxers, the number of threads used to read requests is not fixed and is tunable for Java muxers by configuring the Percent Socket Readers parameter setting in the Administration Console. See Changing the Number of Available Socket Readers. Ideally, you should configure this parameter so the number of threads roughly equals the number of remote concurrently connected clients up to 50% of the total thread pool size. Each thread waits for a fixed amount of time for data to become available at a socket. If no data arrives, the thread moves to the next socket.

Then, for those reasons, it is obviously better to use native muxers.

Here, it looks like you are using the default native muxer (weblogic.socket.EPollSocketMuxer), not the Java muxer (weblogic.socket.SocketMuxer).

Eureetloir

Answer 2

I have found this link that explained the situation pretty much:

The socket Muxer manages the server’s existing socket connections. It first determines which sockets have incoming requests waiting to be processed. It then reads enough data to determine the protocol and dispatches the socket to an appropriate runtime layer based on the protocol. In the runtime layer, the socket muxer threads determine which execute thread queue to be used and delegates the request accordingly.

Absently

Answer 3

For any given application server, a thread dump will show you hundreds, if not thousands, of background threads. These servers are complex beasts, and these threads are just the background plumbing doing its job.

A "muxer" is a multiplexer, which is a mechanism for combining several streams of data on to a single channel. Weblogic will be using these to exchange data with itself, or with other nodes in the cluster. At any given time, a number of those will be "blocked", since they have nothing to do.

It's almost certainly no cause for concern. If you look under the rock, you're bound to find a few ugly things underneath blinking up at you in the sunlight.

Frustum