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

Question

Certains d'entre vous comprennent-ils l'utilisation de weblogic.socket.Muxer dans WebLogic 8.1?

Souvent, dans les dumps de threads, je vois des traces de pile similaires à 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 cela me pose problème, c’est juste intéressant de comprendre:

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

Answer 1

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

  

WebLogic Server utilise des modules logiciels.   appelé muxers pour lire entrant   demandes sur le serveur et entrant   réponses sur le client. Ces muxers   sont de deux types principaux: le Java   muxer ou natif muxer.

     

Un multiplexeur Java a les éléments suivants   caractéristiques:

     

  
• Utilise Java pur pour lire les données des sockets.
  
• C’est également le seul multiplexeur disponible pour les clients RMI.
  
• Bloque les lectures jusqu'à ce qu'il y ait des données à lire depuis un socket. Ce comportement ne s'adapte pas correctement lorsqu'il existe un grand nombre de sockets et / ou lorsque les données arrivent rarement   aux prises. 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.
  

     

Les multiplexeurs natifs utilisent des plateformes spécifiques   binaires natifs pour lire les données   prises de courant. La majorité de toutes les plateformes   fournir un mécanisme pour interroger un   socket pour les données. Par exemple, Unix   systèmes utilisent le système de vote et la   L'architecture Windows utilise l'achèvement   les ports. Native fournir supérieur   l'évolutivité parce qu'ils implémentent un   modèle de fil non bloquant. Lorsqu'un   muxer natif est utilisé, le serveur   crée un nombre fixe de threads   dédié à la lecture entrante   demandes. BEA recommande d’utiliser le   réglage par défaut de sélectionné pour la   paramètre Enable Native IO qui   permet au serveur automatiquement   sélectionne le multiplexeur approprié pour le   serveur à utiliser.

     

Si le paramètre Enable Native IO est   non sélectionné, l'instance du serveur   utilise exclusivement le muxer Java. Ce   peut-être acceptable s'il y a un petit   nombre de clients et le taux à   quelles demandes arrivent sur le serveur est   assez élevé. Dans ces conditions,   le multiplexeur Java effectue aussi bien qu'un   muxer natif et éliminer Java Native   Surcharge d'interface (JNI). contrairement à   muxers natifs, le nombre de threads   utilisé pour lire les demandes n'est pas fixe et   est accordable pour les muxers Java par   configuration des pourcentage de lecteurs de sockets   paramétrage dans le   Console d'administration. Voir Modification   le nombre de sockets disponibles   Lecteurs . Idéalement, vous devriez configurer   ce paramètre donc le nombre de   fils est à peu près égal au nombre de   clients connectés simultanément à distance   jusqu'à 50% du pool de threads total   Taille. Chaque thread attend un fixe   quantité de temps pour que les données deviennent   disponible à une prise. Si aucune donnée   arrive, le fil passe au suivant   prise.

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

Ici, on dirait que vous utilisez le multiplexeur natif par défaut ( weblogic.socket.EPollSocketMuxer ), pas le multiplexeur Java ( weblogic.socket.SocketMuxer) .

Answer 2

J'ai trouvé ce lien cela explique assez bien la situation:

  

Le socket Muxer gère le serveur.   connexions de socket existantes. C'est d'abord   détermine quelles prises ont entrant   demandes en attente de traitement. Il   lit alors assez 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 du multiplexeur de socket déterminent   quelle file d'attente à utiliser   et délègue la demande en conséquence.

Answer 3

Pour tout serveur d'applications donné, un vidage de threads vous montrera des centaines, voire des milliers, de threads d'arrière-plan. Ces serveurs sont des bêtes complexes, et ces threads ne sont que l’arrière-plan qui fait son travail.

Un " muxer " est un multiplexeur, mécanisme permettant de combiner plusieurs flux de données sur un même canal. Weblogic les utilisera pour échanger des données avec lui-même ou avec d'autres noeuds du cluster. À tout moment, un certain nombre d'entre eux seront "bloqués", car ils n'ont rien à faire.

Ce n’est presque certainement pas un sujet de préoccupation. Si vous regardez sous le rocher, vous trouverez forcément quelques choses laides en dessous qui clignotent vers vous au soleil.