2009-09-01 13 views
3

Nous sommes confrontés à un problème dans notre production env. Nous avons cherché le net haut et bas et nous n'avons pas été en mesure de trouver des réponses. Cette erreur (stacktrace ci-dessous) se produit lorsqu'une recherche ejb est effectuée à partir du serveur géré 1 vers le serveur gestionnaire 2. L'adresse IP virtuelle est utilisée pour la recherche. Il se produit par intermittence et à des intervalles aléatoires. Nous ne sommes pas en mesure d'identifier un pattern et si l'appel ejb est tenté deux ou trois fois, il réussit.erreur de recherche de contexte weblogic: java.rmi.UnmarshalException: erreur arguments unmarshalling

détails: serveur Env: weblogic 10.0 MP1 fonctionnant sur Java 1.5 os: SOLARIS

Pls se retournent d'autres détails sont nécessaires.

Source utilisée pour la recherche:

private TreControlRemote getController() throws Exception { 
    Context context = null; 
    Properties p = new Properties(); 
    TreControlHome treHome = null; 
    TreControlRemote remote = null; 
    ConfigurationLoader lAppLoader = null; 
    try { 
     mLog.debug("Entering"); 
     lAppLoader = PropertiesFileLoader.getInstance("context.properties"); 
     p.put(Context.INITIAL_CONTEXT_FACTORY, lAppLoader.getValue("INITIAL_CONTEXT_FACTORY")); 
     p.put(Context.PROVIDER_URL, lAppLoader.getValue("PROVIDER_URL")); 
     context = new InitialContext(p); 
     mLog.debug("context : " + context.getEnvironment()); 
     remote = null; 
     treHome = (TreControlHome) context.lookup("CONTROL"); 
     mLog.debug("Object --->>>>" + treHome); 
     remote = (TreControlRemote) treHome.create(); 
     mLog.debug("Leaving"); 
    } catch (Exception ex) { 
     mLog.fatal("Exception while getting remote", ex); 
     ex.printStackTrace(); 
     throw ex; 
    } finally { 
     lAppLoader = null; 
    } 
    return remote; 
} 

L'URL est une adresse IP virtuelle vers un serveur géré 2 et il contient un ejb avec jndi "CONTROL". Le problème est que son succès sur certains occassions et échoue au hasard avec l'erreur: trace

de la pile de l'erreur:

*javax.naming.CommunicationException [Root exception is java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: 
java.io.StreamCorruptedException] 
at weblogic.jndi.internal.ExceptionTranslator.toNamingException(ExceptionTranslator.java:74) 
at weblogic.jndi.internal.WLContextImpl.translateException(WLContextImpl.java:426) 
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:382) 
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:367) 
at javax.naming.InitialContext.lookup(InitialContext.java:351) 
``````````````````````````````````````````````````````````````````` 
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: 
java.io.StreamCorruptedException 
at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:221) 
at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:338) 
at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:252) 
at weblogic.jndi.internal.ServerNamingNode_1001_WLStub.lookup(Unknown Source) 
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:379) 
... 33 more 
Caused by: java.io.StreamCorruptedException 
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1332) 
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) 
at weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:195) 
at weblogic.rjvm.MsgAbbrevInputStream.readObject(MsgAbbrevInputStream.java:565) 
at weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:191) 
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:224) 
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:479) 
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:475) 
at weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:59) 
at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:1016) 
... 2 more* 

Obtenu le stacktrace mentionné ci-dessous à partir du journal weblogic. Cette erreur peut-elle être liée à notre problème mentionné ci-dessus?

*####<Aug 25, 2009 2:11:04 AM BST> <Info> <RJVM> <pkssv049> <M1AP4> <ACTIVE ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <1251162664181> <BEA-000513> <Failure in heartbeat trigger for RJVM: 5433424963141690658S:169.93.73.0:10040,10040,-1,-1,-1,-1,-1:pkssv049.***.net:10240,pkssv049.***.net:10241,pkssv050.***.net:10240,pkssv050.***.net:10241:LIQP1_LMSDomain:M1AP3 
java.io.IOException: The connection manager to ConnectionManager for: '[email protected] - id: '5433424963141690658S:169.93.73.0:10040,10040,-1,-1,-1,-1,-1:pkssv049.***.net:10240,pkssv049.***.net:10241,pkssv050.***.net:10240,pkssv050.***.net:10241:LIQP1_LMSDomain:M1AP3' connect time: 'Mon Aug 24 20:24:02 BST 2009'' has already been shut down. 
java.io.IOException: The connection manager to ConnectionManager for: '[email protected] - id: '5433424963141690658S:169.93.73.0:10040,10040,-1,-1,-1,-1,-1:pkssv049.***.net:10240,pkssv049.***.net:10241,pkssv050.***.net:10240,pkssv050.***.net:10241:LIQP1_LMSDomain:M1AP3' connect time: 'Mon Aug 24 20:24:02 BST 2009'' has already been shut down 
at weblogic.rjvm.ConnectionManager.getOutputStream(ConnectionManager.java:1686) 
at weblogic.rjvm.ConnectionManager.createHeartbeatMsg(ConnectionManager.java:1629) 
at weblogic.rjvm.ConnectionManager.sendHeartbeatMsg(ConnectionManager.java:607) 
at weblogic.rjvm.RJVMImpl$HeartbeatChecker.timerExpired(RJVMImpl.java:1540) 
at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273) 
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:464) 
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200) 
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)* 

Toute aide serait grandement appréciée.

Voici quelques informations supplémentaires ..

Est-ce le problème intermittent, ou ne reproduit à chaque fois? Si le problème est intermittent, savez-vous dans quelles conditions il se produit? Il se produit par intermittence et nous ne sommes pas en mesure d'observer aucun modèle.

Y a-t-il d'autres erreurs/avertissements enregistrés sur le serveur local ou sur le serveur distant? Nous voyons beaucoup de connexion erreurs refusées dans le journal weblogic

Les deux serveurs gérés sont-ils dans le même domaine? Oui

Répondre

-1

lorsque vous passez une instance de com.myclientcompany.server.eai.interactionspecimpl comme argument pour votre ejb. le weblogic doit désérialiser (unmarshal) l'objet sous le contexte ejb, et il a besoin de la classe requise pour unmarshalling. Par conséquent, si vous incluez la classe interactionspecimpl dans votre fichier ejb-jar, vous n'avez pas besoin d'inclure ces classes dans le chemin de classes de vos serveurs.

+0

* Que * 'com.myclientcompany.server.eai.interactionspecimpl'? Qu'est-ce que tu racontes? – EJP

-1

Ce problème peut se produire si vous avez une entrée Dupliquer pour ou en raison d'un espace vide dans entre.

Vous devez vérifier tous les fichiers de configuration, y compris JDBC, JMS et le fichier config.xml pour trouver une telle entrée et une telle entrée.

Vérifiez si vous avez laissé un espace vide lors de la saisie du nom JNDI à partir de la console.

La suppression de l'espace vide ou la suppression de l'entrée en double résout ce problème.

+0

'Entrée en double pour' * quoi *? – EJP