Co to jest weblogic.socket.Muxer?

Question

Czy ktokolwiek z was rozumie, do czego służy weblogic.socket.Muxer w WebLogic 8.1?

Często w wysypisk wątku widzę stos ślady podobne do tego:

"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 

To nie tak, że nie mam żadnych problemów z tym, to jest po prostu ciekawie zrozumieć:

1) co to robi ?
2) czy może to wpłynąć na wydajność?

Answer 1

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

WebLogic Server wykorzystuje moduły oprogramowania zwane mukserów czytać przychodzące żądania na serwerze i przychodzących odpowiedzi na kliencie. Mnożniki są dwóch podstawowych typów: Java MUxer lub native MUXera .

muxer Java ma następujące cechy:

• Używa czystego Java do odczytu danych z gniazdami.
• Jest to również jedyny muxer dostępny dla klientów RMI.
• Blokuje odczyt, dopóki nie zostaną odczytane dane z gniazda. Takie zachowanie nie jest skalowane, gdy występuje duża liczba gniazd i/lub gdy dane docierają nieczęsto do gniazd o numerze . Zwykle nie jest to problemem dla klientów, ale może stworzyć ogromne wąskie gardło dla serwera.

Native mukserów wykorzystywać specyficzne dla platformy natywnych plików binarnych do odczytu danych z gniazd. Większość wszystkich platform udostępnia mechanizm do odpytywania gniazda dla danych. Na przykład systemy Unix korzystają z systemu odpytywania, a architektura systemu Windows korzysta z portów zakończenia . Język natywny zapewnia lepszą skalowalność, ponieważ implementują model blokujący wątek . Gdy używany jest muxer macierzysty , serwer tworzy ustaloną liczbę wątków przeznaczonych do odczytu żądań przychodzących . Firma BEA zaleca używanie domyślnego ustawienia dla parametru Enable Native IO, który umożliwia automatyczne wybieranie odpowiedniego serwera dla serwera dla serwera .

Jeśli nie zostanie wybrany parametr Enable Native IO , instancja serwera używa wyłącznie MUXera Java. Ten numer może być akceptowalny, jeśli liczba klientów jest mała i wynosi , a stawka podana na , która ma zostać przekazana na serwer, wynosi odpowiednio: . W tych warunkach muxer Java wykonuje tak samo dobrze jak muxer rodzimy i eliminuje narzut Jowisza Java Native (JNI). W przeciwieństwie rodzimych mukserów liczba wątków wykorzystywane do żądania odczytu nie jest stała i jest strojony do mukserów Java przez konfigurowania ustawień Percent Socket Readers parametru w konsoli administracyjnej w . Zobacz Changing the Number of Available Socket Readers. Najlepiej byłoby skonfigurować ten parametr, tak aby liczba złączy była w przybliżeniu równa liczbie zdalnych połączonych klientów do 50% łącznej wielkości puli wątków o rozmiarze . Każda wątek czeka na ustalony czas, aby dane stały się dostępne w gniazdach . Jeśli żadne dane nie zostaną dostarczone, wątek zostanie przeniesiony do następnego gniazda .

Z tych względów lepiej jest używać rodzimych muxerów.

tutaj, wygląda na to, że używasz domyślnego natywną muxer (weblogic.socket.EPollSocketMuxer), a nie muxer Java (weblogic.socket.SocketMuxer).

Answer 2

Dla każdego serwera aplikacji zrzut wątku wyświetli setki, jeśli nie tysiące wątków tła. Serwery te są złożonymi bestiami, a te wątki są tylko instalacjami w tle wykonującymi swoje zadania.

"Muxer" to multiplekser, który jest mechanizmem łączenia kilku strumieni danych z jednym kanałem. Weblogic użyje ich do wymiany danych ze sobą lub z innymi węzłami w klastrze. W danym momencie pewna liczba osób zostanie "zablokowana", ponieważ nie mają nic do roboty.

Prawie na pewno nie ma powodów do niepokoju. Jeśli spojrzysz pod skałą, z pewnością znajdziesz kilka brzydkich rzeczy pod spodem, które migoczą w słońcu.

Answer 3

znalazłem this link który wyjaśnił sytuację dość dużo:

Gniazdo muxer zarządza istniejące połączenia z gniazdem serwera. Najpierw określa, które gniazda mają przychodzące żądania oczekujące na przetworzenie. Następnie odczytuje wystarczającą ilość danych, aby określić protokół i wywołuje gniazdo do odpowiedniej warstwy protokołu runtime opartej na na protokole. W warstwie runtime wątki muxer gniazda określają , które wykonują kolejkę wątków do użycia i odpowiednio delegują żądanie.