Weblogic EJB appels commencer à échouer sous charge modérée avec OptionalDataException

Question

Notre système se compose de deux serveurs Weblogic 10.3:l'un des hôtes de la couche de présentation et les autres hôtes de l'Ejb.Le système fonctionne très bien sous charge modérée pendant un certain temps (de un à plusieurs jours), après quoi les EJB les appels de méthode à partir de la présentation de serveur pour le serveur EJB commencer à échouer avec l'erreur suivante:

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

Trace de la pile:

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)

Une fois la première OptionalDataException est rencontré tous les appels ultérieurs échouer avec le même résultat.Certaines sources suggèrent que ce pourrait être liée à un cluster de multidiffusion port de mal.Cependant, ces serveurs n'appartiennent pas à un cluster.

Démarrage du serveur EJB toujours temporairement résout le problème, mais le problème semble se produire à nouveau après un certain temps.

Mise à jour:il semble que le problème est pas liés à un dépassement du nombre de connexions socket, après tout (voir ma propre réponse ci-dessous).Après interdisant réseau classloading nous avons couru très régulièrement pendant une semaine après que nous avons commencé à recevoir des OptionalDataExceptions sur le serveur de présentation de nouveau (trace de la pile ci-dessous).Il est très étrange que le système fonctionne très bien pour une semaine et commence à échouer.

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

Nous obtenons le contexte de départ tout à fait à la norme:

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

Demande également à tous obtenu des références échouer avec un semblable OptionalDataException.Démarrage du serveur de présentation seul résout le problème temporairement.

Answer 1

Enfin, le OptionalDataExceptions sont de l'histoire.En bref, dans notre code de l'application d'un complexe d'objet de valeur (utilisé comme valeur de retour de méthode à distance invocations) avait une HashMap discbased comme un champ interne.Après avoir changé le type de ce champ à SynchronizedMap la OptionalDataExceptions cessé de se produire.Il semble que, quelque part dans l'héritage de code de cette Carte est gérée non thread-safe façon.

Ce qui est étrange, c'est que cela a causé aucun problème avec WLS 8.1, mais en quelque sorte causé WLS 10 dans un état où tous les à distance des appels de méthode (y compris JNDI recherches) a commencé à échouer.

Answer 2

Enfin, nous avons trouvé la solution à ce (Edit:plus tard, nous avons découvert que ce n'était pas la cause du problème, mais un distinct problème grave.Pour la solution finale, veuillez voir la réponse ci-dessous).Une fois que nous avons commencé à recevoir de l'exception suivante nous sommes arrivés sur les pistes de la cause:

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

Sur le serveur de présentation, qui est en cours d'exécution sur une autre machine que le serveur EJB nous avons eu la possibilité

-Dweblogic.NetworkClassLoadingEnabled=true

évidemment activer le chargement de classe de l'EJB serveur.Ce que nous ne savions pas c'est que l'utilisation de cette option peut entraîner un grand nombre de sockets réseau en cours d'ouverture.À l'aide de la commande netstat, nous avons pu trouver que plusieurs milliers de douilles ont été soit dans CLOSE_WAIT ou FIN_WAIT_2 état.Il semble que tous les éléments de l'INTERFACE utilisateur web ont été chargés à partir du serveur EJB outre les classes, malgré le fait que la guerre de fichier sur le serveur de présentation contenait toutes ces.L'énorme quantité de sockets n'a pas "trop de fichiers" messages d'erreur depuis Weblogic supprime l'espace pour les fichiers dans son script de démarrage.À l'aide d'un serveur de test, nous avons constaté qu'un seul clic sur l'INTERFACE web par l'utilisateur ouvert autour de 30 sockets entre les deux serveurs.

Nous avons supprimé cette option et réemballer la guerre sur le serveur de présentation pour contenir tout le nécessaire classes éliminant ainsi la nécessité pour le réseau classloading.Il en est résulté une diminution du nombre de connexions socket entre les deux serveurs de milliers à 1.

En résumé, éviter réseau de chargement de classe dans Weblogic, si possible.