Che cos'è weblogic.socket.Muxer?

Question

Qualcuno di voi capisce per cosa viene utilizzato weblogic.socket.Muxer in WebLogic 8.1?

Spesso nei dump del thread vedo tracce di stack simili a questo:

"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

Non è che io abbia dei problemi, è solo interessante capire:

1) cosa sta facendo?
2) può influire sulle prestazioni?

Answer 1

Dalla documentazione ( http: // download.oracle.com/docs/cd/E13222_01/wls/docs100/perform/WLSTuning.html#wp1152246 ):

  

WebLogic Server utilizza moduli software   chiamato muxers per leggere in arrivo   richieste sul server e in arrivo   risposte sul cliente. Questi muxer   sono di due tipi principali: Java   muxer o muxer nativo.

     

Un muxer Java ha il seguente   Caratteristiche:

     

  
• Utilizza Java puro per leggere i dati dai socket.
  
• È anche l'unico muxer disponibile per i client RMI.
  
• Blocca le letture fino a quando non ci sono dati da leggere da un socket. Questo comportamento non si ridimensiona bene quando ci sono molti socket e / o quando i dati arrivano raramente   alle prese. Questo non è in genere un problema per i client, ma può creare un enorme collo di bottiglia per un server.
  

     

I mux nativi usano specifici della piattaforma   binari nativi da cui leggere i dati   prese. La maggior parte di tutte le piattaforme   fornire un meccanismo per il polling a   socket per dati. Ad esempio, Unix   i sistemi utilizzano il sistema di sondaggio e il   L'architettura di Windows utilizza il completamento   porti. I nativi forniscono un livello superiore   scalabilità perché implementano a   modello di thread non bloccante. Quando un   viene usato il muxer nativo, il server   crea un numero fisso di thread   dedicato alla lettura degli arrivi   richieste. BEA consiglia di utilizzare il   impostazione predefinita di selezionata per il    Abilita il parametro IO nativo che   consente automaticamente il server   seleziona il muxer appropriato per il   server da utilizzare.

     

Se il parametro Enable Native IO è   non selezionato, l'istanza del server   utilizza esclusivamente il muxer Java. Questo   forse accettabile se ce ne sono di piccoli   numero di clienti e tariffa a   quali richieste arrivano al server è   Piuttosto alto. In queste condizioni,   il muxer Java esegue così come a   muxer nativo ed eliminare Java Native   Interfaccia (JNI) overhead. diversamente da   mux nativi, il numero di thread   usato per leggere le richieste non è fisso e   è sintonizzabile per i muxer Java di   configurazione del Lettore percentuale di socket   impostazione dei parametri in   Console di amministrazione. Vedi Modifica   il numero di socket disponibili   I lettori . Idealmente, dovresti configurare   questo parametro quindi il numero di   le discussioni equivalgono approssimativamente al numero di   client remoti connessi contemporaneamente   fino al 50% del pool di thread totale   taglia. Ogni thread attende una correzione   quantità di tempo perché i dati diventino   disponibile in una presa. Se nessun dato   arriva, il thread passa al successivo   presa.

Quindi, per questi motivi, è ovviamente meglio usare i muxer nativi.

Qui sembra che tu stia utilizzando il muxer nativo predefinito ( weblogic.socket.EPollSocketMuxer ), non il muxer Java ( weblogic.socket.SocketMuxer) .

Answer 2

Ho trovato questo link che spiegava la situazione praticamente:

  

Il socket Muxer gestisce il server   connessioni socket esistenti. Prima di tutto   determina quali socket hanno un ingresso   richieste in attesa di essere elaborate. esso   quindi legge dati sufficienti per determinare   il protocollo e invia il socket   in base a un livello di runtime appropriato   sul protocollo. Nel livello di runtime,   determinano i thread del socket muxer   che esegue la coda di thread da utilizzare   e delega la richiesta di conseguenza.

Answer 3

Per un determinato server delle applicazioni, un dump del thread mostrerà centinaia, se non migliaia, di thread in background. Questi server sono bestie complesse e questi thread sono solo l'idraulico di sfondo che fa il suo lavoro.

Un "muxer" è un multiplexer, che è un meccanismo per combinare diversi flussi di dati su un singolo canale. Weblogic li utilizzerà per scambiare dati con se stesso o con altri nodi nel cluster. In qualsiasi momento, un certo numero di questi verrà "bloccato", poiché non hanno nulla da fare.

Quasi certamente non è motivo di preoccupazione. Se guardi sotto la roccia, sei obbligato a trovare alcune cose brutte sotto che ti sbattono gli occhi alla luce del sole.