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

Pour tout serveur d'applications donné, un vidage de thread vous montrera des centaines, voire des milliers de fils de fond. Ces serveurs sont des bêtes complexes et ces threads ne sont que la plomberie de fond faisant son travail.

Un "Muxer" est un multiplexeur, qui est un mécanisme permettant de combiner plusieurs flux de données sur un seul canal. Weblogic utilisera celles-ci pour échanger des données avec elles-mêmes ou avec d'autres nœuds dans le cluster. À tout moment, un certain nombre de personnes seront "bloquées", car elles n'ont rien à faire.

Ce n'est presque certainement aucune cause de préoccupation. Si vous regardez sous le rocher, vous êtes tenu de trouver quelques objets laids sous clignotant à vous à la lumière du soleil.

J'ai trouvé Ce lien Cela a expliqué la situation à peu près:

Le muxeur de la prise gère le serveur connexions de socket existantes. C'est d'abord détermine les prises entrantes Demandes en attente d'être traitées. Il Ensuite, lit suffisamment de données pour déterminer le protocole et envoie la prise à une couche d'exécution appropriée basée sur une couche d'exécution sur le protocole. Dans la couche d'exécution, Les fils de la prise Muxer déterminent qui exécute la file d'attente de fil à utiliser et déléguette la demande en conséquence.

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

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

A Java muxer a ce qui suit Caractéristiques:

• Utilise Java pur pour lire les données prises.
• Il est aussi le seul muxer disponible pour les clients RMI.
• Les blocs se lit sur jusqu'à ce qu'il y a des données à lire à partir d'une prise. Ce comportement n'échelle pas bien quand il y a un grand nombre de prises et / ou lorsque les données arrivent rarement à des prises. Cela est généralement pas un problème pour les clients, mais il peut créer un énorme goulot d'étranglement pour un serveur.

  muxeurs autochtones utilisent spécifique à la plateforme binaires natifs de lire les données prises de courant. La majorité de toutes les plateformes fournir un mécanisme à un sondage socket pour les données. Par exemple, Unix utilisent le système de scrutin et la l'architecture Windows utilise l'achèvement ports. Natif fournir supérieure l'évolutivité, car ils mettent en œuvre 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 entrant demandes. BEA recommande d'utiliser le Le réglage par défaut de sélectionné pour la Activer natif IO paramètre qui permet automatiquement le serveur sélectionne pour le multiplexeur approprié serveur à utiliser.

  Si le Activer natif IO paramètre est non sélectionné, l'instance de serveur utilise exclusivement Java muxer. Ce peut-être acceptable s'il y a un petit nombre de clients et le taux qui demande arrivent sur le serveur est assez élevé. Dans ces conditions, les Java exécute Muxer ainsi qu'un muxer native et éliminer Java Native Interface (JNI) au-dessus. contrairement à muxeurs natifs, le nombre de fils utilisé pour les requêtes de lecture est pas fixe et est réglable pour Java muxeurs par configuration Pourcentage Lecteurs Socket réglage des paramètres dans le Console d'administration. Voir le Changing . Idéalement, vous devriez configurer ce paramètre de sorte que le nombre de fils équivaut à peu près le nombre de clients connectés simultanément à distance jusqu'à 50% du pool total du fil Taille. Chaque thread attend un fixe Laps de temps pour que les données deviennent disponible sur une prise de courant. Si aucune donnée arrive, le fil se déplace à l'autre socket.

  Alors, pour ces raisons, il est évidemment préférable d'utiliser muxeurs natif.

  Ici, il semble que vous utilisez la valeur par défaut muxer native ( weblogic.socket.EPollSocketMuxer ), non Java muxer ( weblogic.socket.SocketMuxer) . < / p>