How does WebLogic handle socket muxers ?
Muxer ? What’s that ?
Taken from the documentation (http://edocs.bea.com/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:
(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. )
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.
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.
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.</p>
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.
First one, when you start your server, if the log level is high enough, you should see a line like this one :
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).
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 jrockit/vm/RNI.c2java(IIIII)V(Native Method)
— end of trace </p> </blockquote>
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
As said above, a java muxer is embodied by the class weblogic.socket.SocketMuxer
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:</div>