How does WebLogic handle socket muxers ?

Muxer ? What's that ?

Taken from the documentation [http://download.oracle.com/docs/cd/E11035_01/wls100/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.

How do you know that your muxers are native and not java ?

Well, you've got two ways to know that.

Log File

First one, when you start your server, if the log level is high enough, you should see a line like this one :

<Info> <Socket> <BEA-000446> <Native IO Enabled.>

If you don't have the opportunity to check for that line in the logs, it is possible to see that information, thanks to thread dumps.
To perform a thread dump, you've got to send a precise signal to the JVM (http://en.wikipedia.org/wiki/SIGQUIT).

Thread dump

Perform a thread dump

If you're in a Windows environment and your server has been launched with a startup script, switch to the command line window and press CTRL + Break.

That will display the thread dump in the console.

If you're in a Windows environment, but in a service mode, use the beasvc tool to perform the dump. (beasvc -dump)

If Unix is your playground, then you should use the following command "kill -3 PID" (PID is the process id of your JVM)

Another way is to use WLST to perform the dump (quite useful in a AIX environment, trust me !). Take a look at one of my previous post to know more about it.

Once you have your thread dump, you'll have to analyze it.

Analyze a thread dump

In the dump, look for a section in which you can find queue: 'weblogic.socket.Muxer'"

Like that :

"ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'" id=25 idx=0x5c tid=2492 prio=5 alive, in native, daemon
    at weblogic/socket/NTSocketMuxer.getIoCompletionResult(Lweblogic/socket/NTSocketMuxer$IoCompletionData;)Z(Native Method)
    at weblogic/socket/NTSocketMuxer.processSockets(NTSocketMuxer.java:81)
    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(IIIII)V(Native Method)
    -- end of trace

Here you can see (in blue) that the muxer used is the NTSoketMuxer. As long as it is NOT the class weblogic.socket.SocketMuxer, you're using a native muxer.

Else it's a java muxer.

List of Muxers

Java Muxer

As said above, a java muxer is embodied by the class weblogic.socket.SocketMuxer

Native muxers

Windows : weblogic.socket.NTSocketMuxer

UNIX weblogic.socket.PosixSocketMuxer & weblogic.socket.DevPollSocketMuxer

Note : On UNIX environments (such as Solaris and HP-UX), WebLogic Server uses DevPollSocketMuxer by default,

which prints out unnecessary SocketExceptions errors to the server log.

As a workaround, you can enable PosixSocketMuxer via the WebLogic Scripting Tool as follows:

edit()

cd ('Servers/'MyServerName')

startEdit()

set('MuxerClass','weblogic.socket.PosixSocketMuxer')

activate()