Kann nicht von org.omg.CORBA.TRANSIENT wiederhergestellt werden (wird permanent)

9

Ich möchte sicherstellen, dass mein CORBA-Client gegen Ausfälle resistent ist. Ich lasse den Client arbeiten und teste die Ausfallsicherheit, indem ich ihn über den Netzwerkadapter in Windows deaktiviere. Die CORBA-Verbindung schlägt offensichtlich fehl, und die Funktionalität ist nicht verfügbar, aber sie wird nicht wiederhergestellt, wenn der Adapter erneut aktiviert wird. ORB.init wird erneut aufgerufen, aber ich bekomme weiterhin die gleichen Fehler.

Es scheint so, als ob nach org.omg.CORBA.TRANSIENT ein statischer Zustand beibehalten wird, der dazu führt, dass der Client ein Netzwerkverbindungstimeout meldet, selbst wenn das Problem vollständig gelöst ist. Nur ein Neustart des Prozesses (ein lauffähiges JAR) ermöglicht dem Client, erneut zu arbeiten.

Dies ist der Code, der den ORB startet:

%Vor%

Das Problem tritt auch dann auf, wenn die Anwendung ORB.init bei jedem Versuch zur Ausführung der Operation aufruft (d. h. wenn ORB-Pooling ausgeschaltet ist).

Zu den Fehlern, die vom Client im Ausfallfall ausgelöst werden, gehören:

%Vor%

In mindestens einem (möglicherweise allen) Fällen gab es kein org.omg.CORBA.TIMEOUT, bevor org.omg.CORBA.TRANSIENT dauerhaft wurde (d. h. TIMEOUT kann logisches Rauschen sein).

Offensichtlich ist der Client auch ein Server, den wir nicht nach jedem Ausfall neu starten müssen (und das passiert besonders in der Entwicklungsumgebung).

Die Implementierung ist JACORB (org.jacorb.orb.ORB / org.jacorb.orb.ORBSingleton) Version 2.2.4.

    
Simon Gibbs 29.01.2014, 16:52
quelle

2 Antworten

0
  1. Fange die CORBA-Ausnahmen und analysiere (Zeitlimit? Unbekannt??)
  2. Versuchen Sie es später oder nie (aber sterben Sie nicht)

Hinweis: Es ist allgemein üblich, die CORBA-Ausnahme in einer Anwendung zu erfassen. Vor allem rund um Netzwerkanrufe.

Windows entfernt die Netzwerkschnittstelle, wenn das Netzwerkkabel nicht angeschlossen ist. Sie! müssen sich von diesen Ausfällen erholen. Das Entfernen eines Netzwerkkabels unterscheidet sich von einem allgemeinen Netzwerkausfall, z. B. keine Verbindung auf Layer 3!

    
tuergeist 07.02.2014 12:43
quelle
0

Es erscheint etwas peinlich, dass dies wirklich ein Problem mit dem Pool war, dokumentiert hier: Ссылка

Ich dachte Ich hatte experimentell verifiziert, dass Pooling kein Problem war, bevor ich die Frage posten konnte, und ich habe es aus Gründen der Kürze weggelassen. Es wäre aber interessant zu wissen, warum die Frage 7 Upvotes bekommen hat? Vielleicht gibt es eine andere Ursache?

    
Simon Gibbs 28.04.2014 10:27
quelle

Tags und Links