¿Qué es weblogic.socket.Muxer?

Question

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

menudo en vertederos hilo veo trazas de la pila similar a esto:

"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 no tengo ningún problema con eso, se acaba de intresting de entender:

1) ¿qué es lo que hace ?
2) ¿puede afectar a cualquier rendimiento?

Answer 1

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

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

Java muxor tiene las siguientes características :

• utiliza Java pura para leer datos de tomas.
• También es el único muxer disponible para los clientes de RMI.
• Bloquea las lecturas hasta que haya datos para leer desde un socket. Este comportamiento no se escala correctamente cuando hay un gran número de sockets y/o cuando los datos llegan con poca frecuencia a en sockets. Esto normalmente no es un problema para los clientes, pero puede crear un gran cuello de botella para un servidor.

muxers nativos utilizan binarios nativos específicos de la plataforma para leer datos de zócalos. La mayoría de todas las plataformas proporcionan algún mecanismo para sondear un socket para datos. Por ejemplo, los sistemas Unix usan el sistema de sondeo y la arquitectura de Windows usa los puertos de terminación . Native proporciona una escalabilidad superior de porque implementan un modelo de subprocesos no bloqueantes . Cuando se utiliza un muxer nativo , el servidor crea un número fijo de hilos dedicado a leer las solicitudes entrantes . BEA recomienda utilizar la configuración predeterminada seleccionada para el parámetro Enable Native IO que permite al servidor seleccionar automáticamente el silenciador apropiado para el servidor que se utilizará.

Si el parámetro Enable Native IO es no seleccionado, la instancia de servidor utiliza exclusivamente el muxer de Java. Este puede ser aceptable si hay un pequeño número de clientes y la tasa en cuyas solicitudes llegan al servidor es bastante alta. En estas condiciones, el muxer de Java funciona igual que un muxer nativo y elimina la sobrecarga de la interfaz (JNI) Java Native . A diferencia de muxers nativos, el número de hilos utiliza para peticiones de lectura no es fijo y se puede ajustar para muxers Java por definir la configuración de Percent Socket Readers parámetro en la Consola de administración . Ver Changing the Number of Available Socket Readers. Idealmente, debe configurar este parámetro para que el número de hilos sea aproximadamente igual al número de clientes simultáneos conectados simultáneamente hasta 50% del tamaño total del conjunto de subprocesos . Cada subproceso espera un tiempo fijo de para que los datos se vuelvan disponibles en un socket. Si no llega el dato , el hilo pasa al siguiente zócalo .

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

Aquí, parece que está utilizando el muxor predeterminado nativa (weblogic.socket.EPollSocketMuxer), no el muxor Java (weblogic.socket.SocketMuxer).

Answer 2

Para cualquier servidor de aplicaciones determinado, un volcado de subprocesos le mostrará cientos, si no miles, de subprocesos de fondo. Estos servidores son bestias complejas, y estos hilos son solo la fontanería de fondo que hace su trabajo.

Un "muxer" es un multiplexor, que es un mecanismo para combinar varias secuencias de datos en un solo canal. Weblogic los usará para intercambiar datos consigo mismo o con otros nodos en el clúster. En cualquier momento dado, algunos de ellos 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 parpadear a la luz del sol.

Answer 3

he encontrado this link que explica la situación más o menos:

La toma Muxer gestiona conexiones de socket existentes del servidor. Primero, determina qué sockets tienen solicitudes entrantes esperando a ser procesadas. Es luego lee suficientes datos para determinar el protocolo y envía el socket a una capa de tiempo de ejecución adecuada basada en en el protocolo. En la capa de tiempo de ejecución, , los subprocesos de muxer de socket determinan , que ejecuta la cola de subprocesos para su uso y delega la solicitud en consecuencia.