Pergunta

Será que algum de vocês entendem o que weblogic.socket.Muxer é usado no WebLogic 8.1?

Muitas vezes, em linha despeja vejo rastreamentos de pilha semelhantes a esta:

"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

Não é que eu tenho nenhum problema com isso, é apenas intresting para entender:

1) o que ele está fazendo?
2) ele pode afetar qualquer desempenho?

Foi útil?

Solução

A partir da documentação ( http: // download.oracle.com/docs/cd/E13222_01/wls/docs100/perform/WLSTuning.html#wp1152246 ):

WebLogic Server utiliza módulos de software chamado muxers para ler de entrada pedidos no servidor e de entrada respostas no cliente. estes muxers são de dois tipos principais: o Java muxer ou muxer nativa.

muxer A Java tem a seguinte características:

  • Usa puro Java para ler dados de sockets.
  • É também a única muxer disponível para clientes RMI.
  • Blocks on lê até que haja dados a serem lidos de um socket. Este comportamento não escala bem quando há um grande número de tomadas e / ou quando os dados chega com pouca frequência em soquetes. Este não é normalmente um problema para os clientes, mas pode criar um enorme gargalo para um servidor.

muxers nativos usam específico da plataforma binários nativos para ler dados de tomadas. A maioria de todas as plataformas fornecer algum mecanismo para pesquisa de um soquete para dados. Por exemplo, Unix sistemas usam o sistema de votação e ao Janelas conclusão arquitetura usos portos. Native fornecer superiores escalabilidade porque implementar uma non-blocking modelo de thread. Quando um muxer nativa é usado, o servidor cria um número fixo de segmentos dedicado à leitura de entrada solicitações de. BEA recomenda a utilização do configuração padrão seleccionada para o parâmetro Enable Native IO que permite que o servidor automaticamente selecciona o muxer apropriado para o servidor para uso.

Se o parâmetro Enable Native IO é não selecionado, a instância do servidor usa exclusivamente o muxer Java. este talvez aceitável se houver uma pequena número de clientes e a taxa em que os pedidos chegam ao servidor é bastante elevado. Sob estas condições, os executa muxer Java, bem como um muxer nativa e eliminar Java Native Interface (JNI) sobrecarga. Ao contrário muxers nativas, o número de segmentos utilizado para pedidos de leitura não é fixo e é ajustável para muxers Java configurar o Percent Socket Readers parametrização no Console de Administração. Consulte Mudança o número de socket disponíveis Leitores . Idealmente, você deve configurar este parâmetro para que o número de tópicos mais ou menos igual ao número de Os clientes remotos conectados simultaneamente até 50% do pool total rosca Tamanho. Cada segmento aguarda uma fixa quantidade de tempo para os dados para tornar-se disponível em um soquete. Se há dados chega, o fio se move para a próxima socket.

Então, por essas razões, é obviamente melhor usar muxers nativas.

Aqui, parece que você está usando o muxer nativo padrão (weblogic.socket.EPollSocketMuxer), não o muxer Java (weblogic.socket.SocketMuxer).

Outras dicas

Eu encontrei este link que explicou a situação praticamente:

A tomada Muxer administra do servidor conexões de soquete existentes. ele primeiro determina que têm tomadas de entrada solicitações aguardando para serem processados. isto em seguida, lê dados suficientes para determinar o protocolo e despacha o soquete para uma camada de tempo de execução apropriado baseado no protocolo. Na camada de tempo de execução, os fios de soquete muxer determinar que executar rosca fila para ser utilizada e delega a solicitação em conformidade.

Para qualquer servidor de aplicação dada, um despejo thread irá mostrar-lhe centenas, se não milhares, de threads em segundo plano. Esses servidores são bestas complexos, e esses tópicos são apenas o encanamento fundo fazendo seu trabalho.

Um "muxer" é um multiplexador, que é um mecanismo para a combinação de vários fluxos de dados para um único canal. Weblogic será usá-los para trocar dados com ele próprio, ou com outros nós do cluster. Em um determinado momento, um número de pessoas será "bloqueado", uma vez que eles não têm nada para fazer.

É quase certo que não há motivo para preocupação. Se você olhar sob a rocha, você é obrigado a encontrar algumas coisas feias debaixo piscando para você na luz solar.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top