WeblogicのEJB呼び出しはOptionalDataExceptionと適度な負荷で失敗し始めます
-
20-09-2019 - |
質問
私たちのシステムのセットアップは、2台のWebLogic 10.3のサーバで構成されています。一つは、プレゼンテーション層と他のホストEJBを開催しています。システムは、EJBメソッドは、次のエラーで失敗するEJBサーバの起動にプレゼンテーションサーバから呼び出す後しばらく(数日に1)のために、中程度の負荷で正常に動作ます:
java.rmi.RemoteException: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.io.OptionalDataException
スタックトレースます:
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)
最初OptionalDataExceptionに遭遇したら、すべての後続の呼び出しは、同じ結果で失敗。いくつかのソースは、これはマルチキャストポートが誤って設定されているクラスタに関連するかもしれないことを示唆しています。しかし、これらのサーバは、クラスタに属していない。
常にEJBサーバを起動すると、一時的に問題を解決しますが、問題はいくつかの時間後に再び発生するようです。
のアップデートの:(下の私自身の答えを参照してください)のないのすべての後のソケット接続の数のオーバーフローに関連する問題があるようです。ネットワーククラスロードを禁止した後、我々は、我々は再びプレゼンテーションサーバ上のOptionalDataExceptionsの受信を開始した後の週のために非常に着実に実行しました(下のスタックトレース)。システムが週に正常に動作して、失敗し始めていることは非常に奇妙である。
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
私たちは、初期コンテキストにかなり標準的な方法を取得します:
Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
p.put(Context.PROVIDER_URL, serverPath);
Context context = new InitialContext(p);
また、同様のOptionalDataExceptionで失敗あらゆる得参照に呼び出します。単独のプレゼンテーションサーバを起動すると、一時的に問題を解決します。
解決
最後にOptionalDataExceptionsは歴史があります。要するに、我々のアプリケーションコードで(リモートメソッド呼び出しの戻り値として使用される)複素値オブジェクトは、内部フィールドとしてハッシュマップのデータ構造を有していました。 SynchronizedMapこのフィールドの種類を変更した後OptionalDataExceptionsが発生して停止しました。それはどこかのレガシーコードでこの地図は、非スレッドセーフな方法で処理されているようです。
どのような奇妙なことは、これはWLS 8.1で問題が発生することはありませんが、何とかWLS 10は、(JNDIルックアップを含む)すべての後続のリモートメソッドの呼び出しが失敗し始めた状態に入る原因ということです。
他のヒント
最後に、私たちはこれに解決策を見つけました。
:我々は次の例外を受け取るために始めたら、私たちは、原因のトラックに乗りました<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)
私たちはオプションを持っていたEJBサーバーとは異なるホスト上で実行されているプレゼンテーションサーバ、オン
-Dweblogic.NetworkClassLoadingEnabled=true
、明らかにEJBサーバからのクラスのロードを有効にします。私たちが知らなかったことは、このオプションを使用すると、開いているネットワークソケットの膨大な数になることができるということです。 netstatコマンドを使用して、我々は数千ソケットがCLOSE_WAITまたはFIN_WAIT_2の状態でいずれかであったことを見つけることができました。 Web UIのすべての要素は、プレゼンテーションサーバ上のwarファイルは、これらすべてが含まれているという事実にもかかわらず、授業に加えて、EJBサーバからロードされたようです。 WebLogicはその起動スクリプト内のファイルのulimitのを取り除くため、ソケットの膨大な量「とは、あまりにも多くのファイル」エラーメッセージにはなりませんでした。私たちは、ユーザがウェブUIをシングルクリックが2つのサーバー間で約30ソケットを開いたことが分かったテストサーバーを使用します。
私たちは、このオプションを削除したため、ネットワーククラスロードの必要性を取り除く必要なすべてのクラスが含まれているために、プレゼンテーションサーバ上の戦争を再パッケージ化。これは、数千から1への2つのサーバー間のソケット接続の数の減少をもたらします。
要約すると、Weblogicのネットワーククラスのロードを避ける場合は可能な限ります。