Вызовы Weblogic EJB начинают давать сбой при умеренной нагрузке с помощью OptionalDataException

Question

Настройка нашей системы состоит из двух серверов Weblogic 10.3: один размещает уровень представления, а другой - EJB. Система работает нормально при умеренной нагрузке в течение некоторого времени (от одного до нескольких дней), после чего вызовы метода 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 всегда временно решает проблему, но, похоже, проблема снова возникает через некоторое время.

Обновление : похоже, проблема в , а не , связана с переполнением количества соединений сокетов после всех (см. Мой собственный ответ ниже). После запрета загрузки сетевых классов мы работали очень стабильно в течение недели, после чего мы снова начали получать 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. Одна только загрузка сервера презентаций временно решает проблему.

Answer 1

Наконец, OptionalDataException являются историей. Вкратце, в нашем коде приложения объект со сложным значением (используемый в качестве возвращаемого значения для удаленных вызовов методов) имел структуру данных HashMap в качестве внутреннего поля. После изменения типа этого поля на SynchronizedMap перестали возникать исключения OptionalDataExceptions. Кажется, что где-то в унаследованном коде эта карта обрабатывается не потокобезопасным способом.

Странно то, что это не вызвало проблем с WLS 8.1, но каким-то образом заставило WLS 10 войти в состояние, в котором все последующие удаленные вызовы методов (включая поиск JNDI) начали давать сбой.

Answer 2

Наконец-то мы нашли решение этой проблемы (Edit: позже мы узнали, что это была не основная причина проблемы, а отдельная серьезная проблема. Окончательное решение см. В ответе ниже). Как только мы начали получать следующее исключение, мы попали на след причины:

<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. Кажется, что все элементы веб-интерфейса были загружены с сервера EJB в дополнение к классам, несмотря на то, что файл war на сервере представления содержал все это. Огромное количество сокетов не приводило к сообщениям об ошибках «слишком много файлов», поскольку Weblogic удаляет ограничение для файлов в своем скрипте запуска. Используя тестовый сервер, мы обнаружили, что один клик пользователя по веб-интерфейсу открыл около 30 сокетов между двумя серверами.

Мы удалили эту опцию и переупаковали войну на сервере презентаций, чтобы она содержала все необходимые классы, таким образом устраняя необходимость загрузки сетевых классов. Это привело к уменьшению количества сокетных соединений между двумя серверами с тысяч до 1.

В заключение, по возможности избегайте загрузки сетевых классов в Weblogic.