Closed NeunerGEVAS closed 2 years ago
edgebroker
commented
2 years ago Sonst bleibt uns nichts übrig das JMS zu wechseln, was super schade wäre.
Es scheint, als hätte hier jemand das Wesen von Open Source missverstanden. Ob Sie das JMS wechseln oder nicht, interessiert überhaupt keinen. Scheinbar sind Sie nicht in der Lage, Dokumentationen zu lesen bzw suchen einen Dummen, der das für Sie macht.
Aber ich will mal nicht so sein: Pub/Sub Flow Control
NeunerGEVAS
commented
2 years ago Danke für die sehr schnelle Antwort...
wollte eigentlich nett schreiben, da ich mir nicht sicher war, ob mein oben geschildertes Problem mit dem nicht konfiguriertem Flow Control zu tun haben könnte, da ich die Default Einstellungen verwendet habe. Habe nun verstanden, Flow Control ist es vermutlich und werde mich jetzt dransetzen es zu optimieren...
Hallo zusammen,
wir sind seit Jahren Nutzer von SWIFTMQ JMS. Aktuell auf aktuellem SWIFTMQ CE.
Eine Frage zu non durable Topics. Ein zentrale Komponente von uns liest aus einer Queue, verarbeitet die Daten und gibt sie dann über non durable Topics an die Clients weiter.
Wir hatten jetzt mehrmals das Phänomen, dass es Probleme beim Versenden der Daten von der zentralen Komponente an die Topics gegeben hat, d.h. der Durchsatz hat rapide abgenommen.
Durch optimieren der Logfiles konnten wir jetzt feststellen, dass bei einem Topic heute die Übergabe von 4200 Datensätze ca. 1000 Sekunden gedauert hat. In einem anderen Topic waren 588 Datensätze in 20 ms. Dieses Phänomen hat über das Wochenende angedauert.
Genaugenommen war ein Topic seit Samstagabend langsam, alle anderen Topics und auch das Lesen aus der Queue waren aber schnell. Durch einen Neustart von SWIFTMQ hat unser Betrieb das Problem (zu schnell) gelöst.
Dadurch starten aber auch alle Komponenten neu.
In den SWITMQ Logfiles ist nichts zu finden.
Jetzt meine Frage: Ist es möglich, dass ein Client, der total ausgelastet ist und an irgendwelche Ressourcenengpässe kommt dieses Problem verursachen kann und dann alle Clients davon betroffen sind, die diese Topic subskripieren?
Wenn dem so ist, gibt es eine Einstellung in SWIFTMQ, dass dann eben nur dieser eine ausgelastete Client die Daten so langsam bekommt und alle anderen schnell. Wenn der eine langsame Client dann irgendwann gar keine Daten mehr bekommt, wäre das auch ok. Problem ist. Wichtig ist, dass der Datendurchsatz hoch bleibt. Sonst bleibt uns nichts übrig das JMS zu wechseln, was super schade wäre.