Qu'est-ce que weblogic.socket.Muxer?

Question

Est-ce que l'un d'entre vous comprend ce que weblogic.socket.Muxer est utilisé dans WebLogic 8.1?

Souvent dans des décharges de fil que je vois traces de pile semblable à ceci:

"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 

Ce n'est pas que j'ai aucun problème avec cela, il est juste intresting comprendre:

1) que fait-il ?
2) cela peut-il affecter les performances?

Answer 1

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

WebLogic Server utilise des modules logiciels appelés muxeurs à lire les demandes entrantes sur le serveur et entrants réponses sur le client. Ces muxers sont de deux types principaux: le muxer Java ou muxer natif.

A Java muxer a les caractéristiques suivantes:

• Utilise Java pur pour lire les données de prises.
• C'est également le seul multiplexeur disponible pour les clients RMI.
• Bloque les lectures jusqu'à ce qu'il y ait des données à lire à partir d'une socket. Ce comportement ne s'adapte pas bien lorsqu'il y a un grand nombre de sockets et/ou lorsque les données arrivent rarement aux sockets. Ce n'est généralement pas un problème pour les clients, mais cela peut créer un énorme goulot d'étranglement pour un serveur.

muxeurs autochtones utilisent des binaires natifs spécifiques à la plateforme pour lire les données de prises. La majorité de toutes les plates-formes fournissent un mécanisme pour interroger un socket pour les données. Par exemple, les systèmes Unix utilisent le système de sondage et l'architecture Windows utilise les ports d'achèvement . Les natifs offrent une évolutivité supérieure à car ils implémentent un modèle de thread non bloquant . Lorsqu'un multiplexeur natif est utilisé, le serveur crée un nombre fixe de threads dédié à la lecture des demandes entrantes . BEA recommande d'utiliser le paramètre par défaut de sélectionné pour le paramètre Enable Native IO qui permet au serveur d' de sélectionner automatiquement le multiplexeur approprié pour le serveur à utiliser. Si le paramètre Enable Native IO n'est pas sélectionné, l'instance de serveur utilise exclusivement le multiplexeur Java. Ce peut-être acceptable s'il y a un petit nombre de clients et le taux à demandes qui arrivent au serveur est assez élevé. Dans ces conditions, le multiplexeur Java fonctionne aussi bien qu'un multiplexeur natif et élimine l'en-tête Java Native Interface (JNI). Contrairement à muxeurs indigènes, le nombre de threads utilisé pour lire les demandes ne sont pas fixes et est réglable pour Java muxeurs par configurer le réglage des paramètres Percent Socket Readers dans la console d'administration . Voir Changing the Number of Available Socket Readers. Idéalement, vous devez configurer ce paramètre afin que le nombre de threads corresponde à peu près au nombre de clients connectés simultanément et à distance jusqu'à 50% de la taille totale du pool de threads . Chaque thread attend un temps fixe pour que les données deviennent disponibles sur un socket. Si aucune donnée n'arrive, le thread passe à la prise suivante.

Ensuite, pour ces raisons, il est évidemment préférable d'utiliser des multiplexeurs natifs.

Ici, il semble que vous utilisez la valeur par défaut muxer natif (weblogic.socket.EPollSocketMuxer), pas. Java muxer (weblogic.socket.SocketMuxer)

Answer 2

Pour un serveur d'applications donné, un vidage de thread vous montrera des centaines, voire des milliers de threads d'arrière-plan. Ces serveurs sont des bêtes complexes, et ces threads sont juste la plomberie de fond faisant son travail. Un "multiplexeur" est un multiplexeur, qui est un mécanisme permettant de combiner plusieurs flux de données sur un seul canal. Weblogic les utilisera pour échanger des données avec lui-même ou avec d'autres nœuds du cluster. A un moment donné, un certain nombre de ceux-ci seront "bloqués", puisqu'ils n'ont rien à faire.

Ce n'est certainement pas un sujet de préoccupation. Si vous regardez sous le rocher, vous trouverez forcément quelques choses laides sous les lumières du soleil.

Answer 3

J'ai trouvé this link qui expliquait la situation à peu près:

La prise Muxer gère du serveur des connexions socket existantes. Il détermine d'abord quelles sockets ont des demandes entrantes en attente de traitement. Il lit ensuite suffisamment de données pour déterminer le protocole et distribue le socket à une couche d'exécution appropriée basée sur le protocole. Dans la couche d'exécution, , les threads socket muxer déterminent qui exécute la file d'attente de threads à utiliser et délègue la requête en conséquence.