Socket.read () Thread zwischen JBoss und ActiveMQ

8
Gegeben
  • Meine Java-App ist eine WAR, die auf JBoss (4.0.4GA) bereitgestellt wird
  • Veröffentlicht und abonniert eine ActiveMQ (5.6.0) -Instanz
  • Die Java-App verwendet Apache Camel (2.10.3) für die gesamte Integration (Erstellung und Verwendung) mit ActiveMQ
  • JBoss und ActiveMQ auf ihren eigenen (CentOS 5.6 Final) virtuellen Quad-Core-Servern, jeder virtuelle ist auf einem anderen physischen

Ich habe ein Thread-Problem und sehe folgendes in meinem Thread-Dump:

%Vor%

Nach diesen zwei artices: ( hier und hier ), meine JBoss App hat auf Socket.read() eine Blockierung E / A-Operation, die für eine abgeschlossene Antwort von einem nachgelagerten Dienstleister wartet (in meinem Fall, ActiveMQ). Nach diesen Artikeln ist der Schuldige einer der folgenden 3 Punkte:

  • ActiveMQ befindet sich in einem fehlerhaften / instabilen Status und reagiert zu langsam, was dazu führt, dass meine Listening / Waiting / Blocking-Threads hängen bleiben; oder
  • Die ActiveMQ Instanz selbst ist in Ordnung, aber die Verarbeitung eine Operation (bis KahaDB Schreiben, etc.), die zu lang abzuschließen nehmen, wieder meine Fäden verursacht zu hängen; oder
  • Es gibt Netzwerkprobleme zwischen meiner JBoss-App (WAR) und meiner ActiveMQ-Instanz.

Ich versuche herauszufinden, welcher der drei Fälle der Fall ist. Gibt es irgendetwas in diesem Thread-Dump, um anzuzeigen, welcher es ist? Mein Verständnis (nach diesen Artikeln zu lesen) ist, dass die real hängt, ist die Tatsache, dass die Client-Seite (Blockierung) Sockel hat gerade nicht alle empfangenen Bytes es muss berücksichtigen die Antwort ist abgeschlossen; Das bedeutet, dass es keine any -Antwort von ActiveMQ erhalten hat oder keine vollständige Antwort erhalten hat.

Also frage ich:

  1. Gibt es einen klaren Hinweis darauf, welches der drei Szenarien zutrifft? Wenn ja, was / warum? Wenn nicht, was sollte mein nächster Schritt sein (ich bin auch die „admin“, die ActiveMQ so einrichten, habe ich vollen Zugriff darauf sowie JBoss und den Krieg, um es im Einsatz).
  2. Würde ein Upgrade auf einen neueren von JBoss dies beheben? Vielleicht 4.0.4GA verwendet das "alte" (blockierende) Java I / O, während neuere Versionen NIO verwenden könnten? Wahrscheinlich ein Weitwinkel, kann es aber noch nicht diskreditieren.
  3. Beiden Artikel betonen, dass die richtige Buchse-Timeout-Konfiguration implementiert werden soll, welche sehr gut all dies mildern kann (obwohl es nicht die zugrunde liegende ActiveMQ Teilnahmslosigkeit und / oder Netzwerk-Themen nicht ansprechen):
    1. Ist das ein Timeout, den ich in meinen Java-Code schreiben würde? Wenn ja wie und mit welcher API? JMS? Einige ActiveMQ clientseitige jar?
    2. Ist dies ein Timeout, den ich auf Betriebssystemebene implementiere? Wenn dem so ist, bin ich nicht sicher, wie es weitergehen soll ...
    3. Ist das ein Timeout, den ich auf der Serverseite (ActiveMQ) implementiere? Wenn ja, wie?

Ich denke, ich komme hier näher auf eine Lösung zu sprechen, aber ich stecke fest und habe Schwierigkeiten, den Wald zwischen den Bäumen zu sehen. Vielen Dank im Voraus!

    
IAmYourFaja 08.03.2013, 19:44
quelle

1 Antwort

3

Ich habe etwas Erfahrung mit JBoss (und Glassfish) und ActiveMQ, aber ich habe Camel nie zuvor benutzt (aber ich bin vertraut mit Mule, die ich lese ist ähnlich).

Ihr Stack-Trace sieht aus, als ob Camel versucht, ActiveMQ (JMS-Zeug am Ende des Trace) mit einem Web-Endpunkt (HTTP-Zeug oben auf dem Trace) zu verknüpfen.

Ich bin ein wenig verwirrt, wo Camel läuft (der CamelContext). Sie haben gesagt, dass Sie zwei virtuelle Maschinen haben, eine für JBoss und eine für ActiveMQ. In meinem Fall betreiben wir Mule ESB auf der Maschine mit unserem ActiveMQ. Wo läuft dein Kamel?

Ihr Stack-Trace erscheint am häufigsten wie Problem Nr. 1 aus dem ersten Post. Es ist, als ob der Camel-Teil den Web-Endpunkt nicht "sehen" kann. Stellen Sie sicher, dass Ihre WAR-Datei ordnungsgemäß bereitgestellt wird und dass der Webendpunkt (WSDL) von beiden virtuellen Maschinen aus sichtbar ist. Überprüfen Sie Ihre Endpunkte; vielleicht ist man auf localhost oder so eingestellt, was es nicht erlaubt, auf einen anderen Rechner zu gelangen.

Es ist ein bisschen schwierig zu sagen, ob es sich um einen unvollständigen Lesevorgang oder eine komplette Unfähigkeit zu lesen handelt. Werden irgendwelche Daten durchkommen? Es ist möglich, dass der Webserver langsam überlastet wird und nicht mit Anfragen Schritt halten kann (und einige Threads wie in Ihrem Fehler verhungern). Socket Timeouts werden wichtig, wenn Sie langsame Antworten oder viele Anfragen haben; Wenn Sie einen Test erstellen können, der einfach ist (schnell und mit wenigen Anfragen), können Sie zumindest überprüfen, ob Sie eine grundlegende Verbindung haben. Welche Dateneingabe (Test) hat diesen Fehler verursacht?

Ich werde gerne versuchen, diese Antwort mit mehr Input zu verbessern. (Es tut mir leid, dass ich versucht hätte, Ihre Frage zu kommentieren, aber ich glaube nicht, dass ich dafür noch den Vertreter habe ...)

    
SeKa 12.03.2013 10:54
quelle