¿Qué es weblogic.socket.Muxer?

Question

¿Alguno de ustedes entiende para qué se utiliza weblogic.socket.Muxer en WebLogic 8.1?

A menudo, en volcados de subprocesos, veo rastros de pila similares a este:

"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

No es que tenga ningún problema con eso, solo es interesante entenderlo:

1) ¿qué está haciendo?
2) ¿puede afectar el rendimiento?

Answer 1

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

  

WebLogic Server usa módulos de software   llamados silenciadores para leer entrantes   solicitudes en el servidor y entrantes   respuestas sobre el cliente. Estos muxers   son de dos tipos principales: el Java   muxer o muxer nativo.

     

Un muxer de Java tiene lo siguiente   características:

     

  
• Utiliza Java puro para leer datos de sockets.
  
• También es el único muxer disponible para clientes RMI.
  
• Bloquea las lecturas hasta que haya datos para leer desde un socket. Este comportamiento no se escala bien cuando hay una gran cantidad de sockets y / o cuando los datos llegan con poca frecuencia   En los enchufes. Por lo general, esto no es un problema para los clientes, pero puede crear un gran cuello de botella para un servidor.
  

     

Los silenciadores nativos usan plataformas específicas   binarios nativos para leer datos de   enchufes La mayoría de todas las plataformas.   proporcionar algún mecanismo para sondear un   zócalo para datos. Por ejemplo, Unix   sistemas utilizan el sistema de votación y el   La arquitectura de Windows utiliza la finalización   puertos Nativo proporcionar superior   escalabilidad porque implementan una   modelo de hilo sin bloqueo. Cuando un   se utiliza el muxer nativo, el servidor   crea un número fijo de hilos   dedicado a la lectura entrante   peticiones. BEA recomienda usar el   configuración predeterminada de seleccionado para el    Habilitar IO nativo parámetro que   permite al servidor automáticamente   selecciona el silenciador apropiado para el   servidor para usar.

     

Si el parámetro Habilitar E / S nativo es   no seleccionado, la instancia del servidor   utiliza exclusivamente el muxer de Java. Esta   tal vez aceptable si hay un pequeño   número de clientes y la tasa en   qué solicitudes llegan al servidor es   bastante alto. Bajo estas condiciones,   el muxer de Java funciona tan bien como   Muxer nativo y eliminar Java Native   Interfaz (JNI) sobrecarga. diferente a   silenciadores nativos, el número de hilos   utilizado para leer solicitudes no es fijo y   es sintonizable para muxers de Java por   configurar los lectores de socket porcentuales   ajuste de parámetros en el   Consola de administración. Consulte Cambio   el número de zócalos disponibles   Lectores . Idealmente, deberías configurar   este parámetro por lo que el número de   hilos aproximadamente es igual al número de   clientes remotos conectados simultáneamente   hasta el 50% del conjunto total de subprocesos   tamaño. Cada hilo espera un fijo   cantidad de tiempo para que los datos se conviertan   Disponible en un enchufe. Si no hay datos   llega, el hilo se mueve al siguiente   zócalo.

Entonces, por esas razones, obviamente es mejor usar silenciadores nativos.

Aquí, parece que está utilizando el silenciador nativo predeterminado ( weblogic.socket.EPollSocketMuxer ), no el silenciador de Java ( weblogic.socket.SocketMuxer) .

Answer 2

He encontrado este enlace eso explicaba la situación más o menos:

  

El socket Muxer gestiona el servidor & # 8217; s   conexiones de enchufe existentes. Primero   determina qué enchufes tienen entrada   solicitudes en espera de ser procesadas. Eso   luego lee suficientes datos para determinar   el protocolo y despacha el zócalo   a una capa de tiempo de ejecución adecuada basada   en el protocolo En la capa de tiempo de ejecución,   los hilos del zócalo muxer determinan   que ejecutan la cola de subprocesos que se utilizará   y delega la solicitud en consecuencia.

Answer 3

Para cualquier servidor de aplicaciones dado, un volcado de subprocesos le mostrará cientos, si no miles, de subprocesos en segundo plano. Estos servidores son bestias complejas, y estos hilos son solo las tuberías de fondo que hacen su trabajo.

A '' muxer '' es un multiplexor, que es un mecanismo para combinar varios flujos de datos en un solo canal. Weblogic los utilizará para intercambiar datos consigo mismo o con otros nodos del clúster. En un momento dado, algunos de esos serán "bloqueados", ya que no tienen nada que hacer.

Es casi seguro que no es motivo de preocupación. Si miras debajo de la roca, seguramente encontrarás algunas cosas feas debajo de ti parpadeando a la luz del sol.