4. CORBA, GIOP, IIOP: Ich weiss nicht mehr weiter

CORBA, GIOP, IIOP: Ich weiss nicht mehr weiter

  • M

    Ein Client/Server-System soll Online via Browser gestellt werden. Dazu werden JAVA-Servlets via Apache/Tomcat mittels CORBA an die Server-Programme angebunden. Zusätzlich existiert ein Rich-Client (C++), der ebenfalls via CORBA auf die Server-Programme zugreift.

    Die Anbindung des Rich-Clients funktioniert absolut reibungslos. Die Anbindung der JAVA-Servlets zunächst erst einmal auch. Als jedoch mehr als 1 KB Daten an den Server gesendet wurde, reagierte Sun mit dem Fehler 208 und nix ging mehr.

    Die Internet-Recherche ergab zunächst einen Konflikt zwischen dem VisiBroker und der neuen GIOP-Version. VisiBroker definiert einen Buffer für den Transfer von 4 KB, während GIOP 1.2 einen Buffer von 1 KB definiert. Also: Alles klar, SUN ist schuld! Buffer auf 4 KB geändert. Alles in Ordnung.

    Bis zu dem Zeitpunkt, als mehr als 4 KB vom Client zum Server gingen. Identische Fehlermeldung! 😮

    Dann das erste größere Paket (mit bis zu 10 KB gab es bislang keine Probleme) vom Server an den Client. Der soll jetzt 32 KB an ein Servlet übertragen. SUN erzählt mir jetzt was von Geburten (Native) und Beschwörungen (Invocation). 😮 😮

    Hier der Fehlercode:

    unknown exeption >> java.lang.reflect.InvocationTargetException >> java.lang.reflect.InvocationTargetException  	
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  	
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)  	
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)  	
at java.lang.reflect.Method.invoke(Method.java:324)  	
at com.i7business.IIJTOOLS.IIUnitLogicBase.dispatchEvent(IIUnitLogicBase.java:289)  	
at com.i7business.IIJTOOLS.IIUnitLogicBase.showUnit(IIUnitLogicBase.java:136)
at com.i7business.IISVRHELPER.IISession.unitCall(IISession.java:686)  
at com.i7business.IIModule1500.CMDInterpreter.callCalc(CMDInterpreter.java:1550)  	
at com.i7business.IIModule1500.CMDInterpreter.callCalc(CMDInterpreter.java:1511)  	
at com.i7business.IIModule1500.CMDInterpreter.callCalc(CMDInterpreter.java:1511)  	
at com.i7business.IIModule1500.CMDInterpreter.callCalc(CMDInterpreter.java:1511)  	
at com.i7business.IIModule1500.CMDInterpreter.handleCalcButton(CMDInterpreter.java:1433)  	
at com.i7business.IIModule1500.IIUnitLogic1500_unit_ICFDyn.IIBAO1500_unit_ICFDyn_PB_ERGEBNISSE_SELECT(IIUnitLogic1500_unit_ICFDyn.java:299)  	
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  	
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)  	
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)  	
at java.lang.reflect.Method.invoke(Method.java:324)  	
at com.i7business.IIJTOOLS.IIUnitLogicBase.dispatchEvent(IIUnitLogicBase.java:289)  	
at com.i7business.IIModule1500.IIUnitLogic1500_unit_ICFDyn.dispatchEvent(IIUnitLogic1500_unit_ICFDyn.java:201)  	
at com.i7business.IIJTOOLS.IIUnitLogicBase.handleEvent(IIUnitLogicBase.java:215)  	
...

    Schätze, der Rest ist weniger interessant. Interessant ist jedoch, dass die eigentliche Funktion, in welcher der Fehler tatsächlich ausgelöst wird, trotz try und catch gar nicht aufgeführt wird.

    Die Recherchen im Internet brachten eine Menge Fragen zu diesem Thema, jedoch ohne keine einzige Antwort.

    Beim Debuggen auf der Server-Seite sehe ich noch, wie die Ergebnisstruktur in eine GIOP-Struktur (am Anfang steht GIOP mit anschließender binärer 1) umgewandelt wird und mit dem Versand begonnen wird. Im Assembler-Bereich kann ich auch noch nachvollziehen, dass SUN die Exception wirft, während der Server noch Daten überträgt.

    Ich hoffe, dass dazu hier irgend jemand eine Idee hat.

    0
Anmelden zum Antworten