llamadas WebLogic EJB empiezan a fallar bajo carga moderada con OptionalDataException

Question

Nuestra configuración del sistema se compone de dos servidores Weblogic 10.3: uno acoge la capa de presentación y los otros anfitriones del EJB. El sistema funciona muy bien bajo carga moderada durante algún tiempo (de uno a varios días) después de lo cual método EJB llama desde el servidor de presentación al inicio del servidor EJB a fallar con el siguiente error:

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

Seguimiento de la pila:

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)

Una vez que la primera OptionalDataException se encontró con todas las llamadas posteriores fallan con el mismo resultado. Algunas fuentes sugieren que esto podría estar relacionado a agruparse puerto de multidifusión está mal configurado. Sin embargo, estos servidores no pertenecen a un grupo.

Arranque del servidor EJB siempre se resuelve el problema temporalmente, pero el problema parece ocurrir de nuevo después de algún tiempo.

Actualizar : parece que el problema es no en relación con un desbordamiento en el número de conexiones de socket después de todo (ver mi propia respuesta a continuación). Después de no permitir la carga de clase de la red nos encontramos muy constante durante una semana después de lo cual empezamos a recibir OptionalDataExceptions en el servidor de presentación de nuevo (Seguimiento de la pila a continuación). Es muy raro que el sistema funciona bien para una semana y luego empieza a fallar.

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

Obtenemos el contexto inicial bastante la forma estándar:

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

Pide también a las referencias obtenidas fallan con un OptionalDataException similar. Arrancar el servidor de presentación solo resuelve el problema temporalmente.

Answer 1

Finalmente los OptionalDataExceptions son historia. En resumen, en nuestro código de la aplicación de un valor de objeto complejo (se utiliza como valor de retorno para la invocación de métodos remotos) tenía una estructura de datos HashMap como un campo interno. Después de cambiar el tipo de este campo para SynchronizedMap los OptionalDataExceptions detuvo ocurra. Parece que en algún lugar del código heredado este mapa se maneja de forma no segura para los subprocesos.

Lo que es extraño es que no se produjeron problemas con WLS 8.1, pero de alguna manera causó WLS 10 entran en un estado donde todas las invocaciones de métodos remotos posteriores (incluyendo búsquedas JNDI) comenzaron a fallar.

Answer 2

Finalmente, encontramos la solución a este (Edit: más tarde descubrimos que esta no fue la causa raíz del problema, pero un problema grave separado para la solución final, por favor ver la respuesta a continuación.). Una vez que empezamos a recibir la siguiente excepción que nos dieron en las pistas de la causa:

<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)

En el servidor de presentación, que se ejecuta en un host diferente que el servidor EJB que teníamos la opción

-Dweblogic.NetworkClassLoadingEnabled=true

para permitir la carga de clases, obviamente, desde el servidor EJB. Lo que no sabíamos es que el uso de esta opción puede resultar en que se abre un gran número de conectores de red. El uso de netstat hemos sido capaces de descubrir que eran varios miles de tomas ya sea en CLOSE_WAIT o FIN_WAIT_2 estado. Parece que todos los elementos de la interfaz de usuario web se cargan desde el servidor EJB, además de las clases a pesar del hecho de que el archivo de la guerra en el servidor de presentación contenía todos estos. La enorme cantidad de enchufes no dio lugar a "demasiados archivos" mensajes de error desde Weblogic elimina la ulimit para los archivos de script de inicio. El uso de un servidor de prueba nos encontramos con que un solo clic en la interfaz de usuario web por parte del usuario abre alrededor de 30 tomas entre los dos servidores.

Hemos eliminado esta opción y empaquetado de nuevo la guerra en el servidor de presentación para contener todas las clases necesarias eliminando así la necesidad de que la carga de clase de red. Esto resultó en una disminución en el número de conexiones de socket entre los dos servidores de miles a 1.

En un resumen, evitar la carga de clases de red en Weblogic, si es posible.