JMS Performance Problem

Pauer76

Mitglied
Hallo,
ich habe ein Perfomance Problem mit meiner JMS Queue. Ich setzte den JBoss 4.2.1 ein. Meine Applicationssturktur sind folgendermaßen aus. Ich habe mir selbst einen TCP Service geschrieben der TCP/IP Messages empfängt. Dieser Service wandelt die Message in ein JMS Object um und schreibt diese dann in eine Queue. Am anderen ende der Queue lauscht ein Dispatcher der die Nachrichten, dann weiter an verschiedene Klassen verteilt. Das alles läuft innerhalb des JBoss ab. Die Klassen, die die Nachrichten verabreiten sind alles Managed Beans. Ich habe jetzt festgestellt, dass es vorkommen kann, dass eine Nachricht manchmal bis zu 2 Sekunden in der Queue verschwindet. Das heißt ich habe mir eine Logausgabe mit Zeitstempel gemacht. Genauwenn der TCP Service ein send macht, sprich die Nachricht also in die Queue schreibt. Und dann habe ich mir einen Zeitstempel gemacht in dem moment in der die onMessage Methode von meinem Dispatcher aufgerufen wird. Was passiert da. Wo ist die Nachricht in den 2 Sekunden. 2 Sekunden sind in meinem Fall eine Welt. Ich muss eine Responsezeit von 200 ms gewährleisten. Zu viele Nachrichten können eigentlich auch nicht in der Queue sein. Ich habe mal nachgeschaut. Es kommen ca. 30 Messages pro Sekunde.
Vielen Dank.
 
Hallo,

anstatt managed Beans meinst du wohl Message Driven Beans.
Hört sich fast so an als ob bei der Queue Konfiguration etwas nicht ganz in Ordnung ist.
Wird die JMS Queue noch von einer anderen Anwendung benutzt? Wird hier eine In-Memory basierte oder eine Datenbankbasierte Queue verwendet? Kann es sein, dass die Nachrichten die so lange brauchen redelivered wurden? -> RedeliveryDelay zu hoch? Hat die Queue eine größen Beschränkung? Hat die Queue einen oder mehrere Consumer (in dem Fall MDB's)?

Gruß Tom
 
Hallo,
Managed Beans war schon richtig. Noch ein paar Details zum Dispatcher. Den Dispatcher habe ich mir selbst geschrieben. Ich habe mir eine ganz normale Klasse erstellt. Diese Klasse Implementiert das Interface "javax.jms.MessageListener". Hier erzeuge ich mir dann selbst den InitialContext, QueueSession usw. Das mache ich deshalb, weil ich ein dynamiches System habe, dass fast ganz über XML Dateien konfigueriert werden soll. Bei MessageDrivenBeans kann ich das so einfach nicht machen.
So nun weiter zum Dispatcher. Da ich ja das Interface MessageListener implementiere brauche ich dann nur noch die onMessage Methode zu überschreiben. In dieser Methode wird dann also die erhaltene Message an eine Managed Bean übergeben. Dies mache ich weil ich mir eigentlich keinen eigenen Thread schreiben möchte. Das will ich eigentlich dem JBoss überlassen.
Weiter zu Deinen Fragen:
Die Queue wird von keiner anderen Anwendung genutzt. Was meinst Du mit In-Memory oder Datenbank-Queue. Die konfiguration meiner Queue ist Standart JBoss. Das einzige was ich geändert habe, ist dass am JBoss keine Hypersonic Datenbank mehr hängt. Ich habe dem JBoss eine Postgres Datenbank zugewiesen.
Hier ein Bsp. für die Konfiguration einer Queue in der jbossmq-destinations-service.xml

<mbean code="org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=DemoQueue">
<depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
</mbean>
Gruß
Timo
 
Hallo,

hast du auch die Datenbankkonfiguration des JMS- Persistence Services geändert?
Wenn ja, werden die persistenten JMS Nachrichten wenn sie in die Queue geschrieben werden in die Datenbank geschrieben und entsprechend wieder herausgeladen.

Wenn die Datenbank unter Last steht und / oder falsch Konfiguriert wordnen ist, kann das dauern

Gruß Tom
 
Hallo,

Siehe ungefähr hier:
D:\stuff\jboss\4.2.0GA\jboss-4.2.0.GA\server\default\deploy\jms
hsqldb-jdbc2-service.xml
bzw.:
hsqldb-jdbc-state-service.xml
Standardmäßig wird dort die DefaultDS benutzt. Wenn du die DefaultDS von HSQL auf Postgresql umgestellt hast könnte das die Ursache für die langsamen Queue Interaktion sein.

Gruß Tom
 
Vielleicht noch nützlicher Hinweis: Wenn ich mein Programm ca. 10 Minuten laufen lasse. Erhalte ich ca. 2200 Requests über die Queue. Davon brauchen ca. 60 über 500 ms und ca 10 über 1200ms. Aber wie gesagt muss über 200 ms die 0 stehen.
Gruß
Timo
 
Hallo,

brauchst du überhaupt persistente Messages / Queues? Wenn nicht würde ich das einfach zu einer non persistent Queue umkonfigurieren. Dann kannst du x mal so viele Messages pro Sekunde verarbeiten. Wenn der Server allerdings dann mal abstürtzt sind alle Messages die in der Queue sind verloren. Wenn du damit leben kannst dann alé hopp.

Gruß Tom
 
Damit kann ich sehr gut leben, weil mein System bei starten sowie so ein abgleich mit anderen Komponenten machen muss. Wie kann ich die Queues denn umkonfigurieren? Und muss ich da auf was achten.
 
Zurück