1

このシステム セットアップは、2 つの Weblogic 10.3 サーバーで構成されています。1 つはプレゼンテーション層をホストし、もう 1 つは EJB をホストします。システムは中程度の負荷の下でしばらく (1 日から数日) 正常に動作します。その後、プレゼンテーション サーバーから EJB サーバーへの EJB メソッド呼び出しが次のエラーで失敗し始めます。

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 サーバーを起動すると、問題は常に一時的に解決されますが、しばらくすると問題が再発するようです。

更新:結局、問題はソケット接続数のオーバーフローとは関係がないようです (以下の私自身の回答を参照してください)。ネットワーク クラスローディングを禁止した後、1 週間非常に安定して動作し、その後、プレゼンテーション サーバーで再び OptionalDataExceptions を受け取り始めました (以下のスタック トレース)。システムが 1 週間は問題なく動作していたのに、その後失敗し始めるというのは非常に奇妙です。

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 で失敗します。プレゼンテーション サーバーを単独で起動すると、一時的に問題が解決します。

4

2 に答える 2

1

最後に、これに対する解決策を見つけました（編集：後で、これが問題の根本的な原因ではなく、別の重大な問題であることがわかりました。最終的な解決策については、以下の回答を参照してください）。次の例外を受け取り始めたら、原因を突き止めました。

<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状態にあることを確認できました。プレゼンテーションサーバー上のwarファイルにこれらすべてが含まれているにもかかわらず、WebUIのすべての要素がクラスに加えてEJBサーバーからロードされたようです。Weblogicは起動スクリプト内のファイルのulimitを削除するため、大量のソケットによって「ファイルが多すぎます」というエラーメッセージが表示されることはありませんでした。テストサーバーを使用して、ユーザーがWeb UIを1回クリックすると、2つのサーバー間で約30個のソケットが開かれることがわかりました。

このオプションを削除し、プレゼンテーションサーバーでwarを再パッケージ化して、必要なすべてのクラスを含め、ネットワーククラスローディングの必要性を排除しました。これにより、2台のサーバー間のソケット接続数が数千から1に減少しました。

要約すると、可能な限りWeblogicでのネットワーククラスのロードは避けてください。

于 2010-03-31T07:22:56.800 に答える
1

最後に、OptionalDataExceptions は履歴です。つまり、アプリケーション コードでは、複合値オブジェクト (リモート メソッド呼び出しの戻り値として使用される) は、内部フィールドとして HashMap データ構造を持っていました。このフィールドのタイプを SynchronizedMap に変更した後、OptionalDataExceptions は発生しなくなりました。レガシー コードのどこかで、この Map は非スレッド セーフな方法で処理されているようです。

奇妙なことに、これは WLS 8.1 では問題を引き起こしませんでしたが、どういうわけか、WLS 10 が後続のすべてのリモート メソッド呼び出し (JNDI ルックアップを含む) が失敗し始める状態になりました。

于 2010-08-02T07:36:00.677 に答える