Irgendein Grund, warum ich nicht eine Nachricht mit Tibco Rendezvous bestätigen könnte?

Question

Ich habe ein Setup, in dem einige Anwendungen über Tibco Rendezvous miteinander kommunizieren. Die Anwendungen kommunizieren mithilfe von zertifiziertem Messaging. Mein Problem ist, dass zwei meiner Empfänger vor kurzem angefangen haben, das Verhalten zu zeigen, dass sie eine Error 27, nicht erlaubt erhalten, wenn sie eine Nachricht bestätigen wollen (die erste Nachricht in einem zertifizierten Nachrichtenaustausch ist nicht zertifiziert, wir haben dies berücksichtigt) Das).

Ich habe im Internet gesucht, um Leute mit dem gleichen Fehler zu finden, und ich habe viele gefunden, aber alle bekommen den Fehler, wenn sie versuchen, den tibco-Transport zu erstellen. Ich kann den Transport problemlos erstellen, aber ich kann keine Nachrichten darüber bestätigen.

Unsere Umgebung verwendet tibco 7.X und 8.X, einige Male vermischt. Dieses Problem tritt auf, wenn die Peers dieselbe tibco-Version verwenden und wenn sie unterschiedliche Versionen verwenden. Es wird nicht für alle Anwendungen angezeigt, aber wenn es für eine Anwendung angezeigt wird, bleibt es "kaputt". Das Verwerfen der Ledger-Dateien für Sender und Empfänger tut nichts. Wir bekommen immer noch den Fehler. Sowohl der Absender als auch der Empfänger verfügen über die entsprechenden Berechtigungen zum Schreiben (und Erstellen) der Hauptbuchdateien. Wir verbinden uns mit permanent laufenden rvds. Sender und Empfänger befinden sich auf verschiedenen Rechnern. Die Kommunikation hat in der Vergangenheit einwandfrei funktioniert, aber irgendwann hörte es auf. Die Anwendung ist in Java und wir verwenden die auto-native Bibliotheken tibrvj.jar.

Der Fehler ist

 
... 
Caused by: TibrvException[error=27,message=Not permitted] 
    at com.tibco.tibrv.TibrvImplCmTPortC.natConfirmMsg(Native Method) 
    at com.tibco.tibrv.TibrvImplCmTPortC.confirmMsg(TibrvImplCmTPortC.java:304) 
    at com.tibco.tibrv.TibrvCmListener.confirmMsg(TibrvCmListener.java:88) 
.... 

Ich weiß, du wirst mich fragen: „Was haben Sie getan, um es los zu machen beginnen“, und meine Antwort ist: „Ich weiß nicht“.

Jede Eingabe wäre willkommen.

Danke.

Answer 1

Wie sich herausstellte, war es ein Fehler auf der Anwendungsebene. Aufgrund von herumliegenden alten Codes waren wir nach der Aktualisierung einer Abhängigkeit (unserer Messaging-Schicht) von einer Bestätigung auf Anwendungsebene zu einer Bestätigung auf Containerebene gewechselt, aber wir hatten vergessen, eine explizite Bestätigungsmeldung im Anwendungscode zu entfernen.

Zusammenfassend: Wir haben versucht, die Nachricht zweimal zu bestätigen, und beim zweiten Mal hat diese Ausnahme ausgelöst.

Answer 2

Es ist möglich, dass TCP-Verbindungen zwischen den beiden RVD-Servern nicht möglich sind. Können Sie überprüfen, ob Sie sich von einem zum anderen verbinden können (Verbindung vom Abonnenten-Host zurück zum Publisher)? Nach meiner Erfahrung werden CM-Bestätigungen über TCP gehandhabt (bitte nehmen Sie dies mit einer Prise Salz, da ich eher ein Endbenutzer als ein Middleware-Support-Typ bin).

Answer 3

Ich vor kurzem stieß auf die gleiche Ausnahme - Anwendung hatte seit Monaten gearbeitet, war plötzlich Ausnahme werfen. In meinem Fall wurde auf dem Windows-Server, auf dem die Anwendung ausgeführt wurde und auf dem Verzeichnisse als schreibgeschützt markiert waren, Wartungsarbeiten durchgeführt. Sobald das erledigt war, ging die Ausnahme weg.

Entdeckt dies nach der Störungssuche im Wert von anderen möglichen Ursachen.

Answer 4

Nur meine zwei Cent: Diese Ausnahme tritt auch auf, wenn Sie versuchen, die Nachricht auf Nicht-CM-Transport explizit zu bestätigen.