Weblogic EJB Anrufe starten unter mäßiger Belastung mit OptionalDataException zum Scheitern verurteilt

Question

Unser System-Setup besteht aus zwei Weblogic 10.3 Server: ein Rechner der Präsentationsschicht und den anderen Hosts die EJBs. Das System läuft gut unter mäßiger Belastung für einige Zeit (ein bis mehrere Tage), nach der EJB Methodenaufrufe vom Präsentationsserver auf den EJB-Server mit dem folgenden Fehler fehlschlagen starten:

java.rmi.RemoteException: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.io.OptionalDataException

Stack-Trace:

java.io.OptionalDataException
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1349)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
    at weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:197)
    at weblogic.rjvm.MsgAbbrevInputStream.readObject(MsgAbbrevInputStream.java:564)
    at weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:193)
    at weblogic.jndi.internal.RootNamingNode_WLSkel.invoke(Unknown Source)
    at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:589)
    at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:230)
    at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:477)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
    at weblogic.security.service.SecurityManager.runAs(Unknown Source)
    at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:473)
    at weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118)

Sobald die erste OptionalDataException angetroffen wird alle nachfolgenden Anrufe nicht mit dem gleichen Ergebnis. Einige Quellen deuten darauf hin, dass dies in Zusammenhang stehen könnte Multicast-Port Cluster falsch konfiguriert werden. Allerdings haben diese Server nicht, gehören in einem Cluster.

Booting des EJB-Server immer löst das Problem vorübergehend, aber das Problem scheint nach einiger Zeit wieder auftreten.

Update : es scheint, dass das Problem ist, nicht im Zusammenhang mit einem Überlauf in der Anzahl der Socket-Verbindungen nach allen (siehe meine eigenen Antwort unten). Nach disallowing Netzwerk Classloading liefen wir eine Woche lang sehr stetig, nach dem wir wieder OptionalDataExceptions auf dem Präsentationsserver empfängt (Stack-Trace unten) gestartet. Es ist sehr merkwürdig, dass das System gut für eine Woche arbeitet und beginnt dann zu versagen.

javax.naming.CommunicationException [Root exception is java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
    java.io.OptionalDataException]
    at weblogic.jndi.internal.ExceptionTranslator.toNamingException(ExceptionTranslator.java:74)
    at weblogic.jndi.internal.WLContextImpl.translateException(WLContextImpl.java:439)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:395)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:380)
    at javax.naming.InitialContext.lookup(InitialContext.java:392)
    ...
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:

    java.io.OptionalDataException
    at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:234)
    at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:348)
    at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:259)
    at weblogic.jndi.internal.ServerNamingNode_1030_WLStub.lookup(Unknown Source)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:392)  
    ... 38 more
Caused by: java.io.OptionalDataException
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1349)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
    at     
    weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:197)
    at weblogic.rjvm.MsgAbbrevInputStream.readObject(MsgAbbrevInputStream.java:564)
    at     
weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:193)
    at weblogic.jndi.internal.RootNamingNode_WLSkel.invoke(Unknown Source)
    at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:589)
    at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:230)
    at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:477)
    at        
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
    at weblogic.security.service.SecurityManager.runAs(Unknown Source)
    at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:473)
    at weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118)
    ... 2 more

Wir erhalten den Ausgangskontext ganz die Standardmethode:

Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
p.put(Context.PROVIDER_URL, serverPath);
Context context = new InitialContext(p);

ruft auch für alle erhaltenen Referenzen mit einem ähnlichen OptionalDataException scheitern. Booten der Präsentationsserver allein wird das Problem behoben vorübergehend.

Answer 1

Schließlich werden die OptionalDataExceptions sind Geschichte. Kurz gesagt, hat in unserem Anwendungscode ein komplexer Wert Objekt (verwendet als Rückgabewert für die Fernmethodenaufrufe) eine HashMap Datenstruktur als internes Feld. den Typ dieses Feldes SynchronizedMap Nach dem Wechsel der OptionalDataExceptions gestoppt auftritt. Es scheint, dass irgendwo in dem Legacy-Code diese Karte in nicht Thread-sicheren Art und Weise behandelt wird.

Was seltsam ist, dass diese mit WLS keine Probleme verursacht 8.1, aber irgendwie verursacht WLS 10 in einen Zustand eintreten, in der alle nachfolgenden entfernten Methodenaufrufe (einschließlich JNDI-Lookups) gestartet fehlschlagen.

Answer 2

Schließlich fanden wir die Lösung dieses (Edit: später fanden wir heraus, dass dies nicht die Ursache des Problems war, sondern ein eigenständiges ernstes Problem für die endgültige Lösung finden Sie in der Antwort weiter unten.). Sobald wir begannen die folgende Ausnahme erhalten wir auf den Spuren der Ursache bekommen:

<BEA-000403> <IOException occurred on socket: Socket[addr=/x.x.x.x,port=3266,localport=7001]
 java.net.SocketException: Connection refused.
java.net.SocketException: Connection refused
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:887)
at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:859)
at weblogic.socket.DevPollSocketMuxer.processSockets(DevPollSocketMuxer.java:120)
at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:29)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:42)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:145)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)

Auf dem Präsentationsserver, der auf einem anderen Host als den EJB-Server ausgeführt wir hatten die Möglichkeit,

-Dweblogic.NetworkClassLoadingEnabled=true

zu offensichtlich Laden von Klassen aus dem EJB-Server aktivieren. Was wir nicht wissen ist, dass diese Option in einer große Anzahl von Netzwerk-Sockets zur Folge haben kann geöffnet werden. Mit netstat wir in der Lage waren, um das herauszufinden entweder mehr tausend Steckdosen waren in CLOSE_WAIT oder FIN_WAIT_2 Zustand. Es scheint, dass alle Elemente in dem Web-UI von dem EJB-Server zusätzlich zu den Klassen trotz der Tatsache, geladen wurden, dass die Krieg Datei auf dem Präsentationsserver alle diese enthielt. Die riesige Menge an Steckdosen führte nicht „zu viele Dateien“ Fehlermeldungen seit Weblogic die ulimit für Dateien in seinem Startskript entfernt. Mit einem Test-Server haben wir herausgefunden, dass ein einzelner Klick auf der Web-Oberfläche durch den Benutzer um 30 Buchsen zwischen den beiden Servern geöffnet.

Wir entfernt diese Option und neu verpackt, den Krieg auf dem Präsentationsserver alle benötigten Klassen enthalten somit die Notwendigkeit für Netzwerk Classloading entfernen. Dies führte zu einer Verringerung der Anzahl von Socket-Verbindungen zwischen den beiden Servern von Tausenden auf 1.

In einer Zusammenfassung, vermeidet Netzklasse Laden in Weblogic, wenn überhaupt möglich.