InitialContext.lookup d'EJB distant échoue après le redémarrage du serveur distant

Question

Nous avons une configuration dans laquelle EJB A est en cours d'exécution sur le serveur A, et un autre EJB B est en cours d'exécution sur le serveur B. EJB A se connecte à EJB B via IIOP. Cette configuration fonctionne normalement, mais si le serveur B est redémarré, EJB A échouera le serveur A redémarre aussi.

Le problème est que si le serveur B est redémarré, tous les appels à initialContext.lookup par EJB A échoue avec: exception jusqu'à ce que le serveur A redémarrage « java.io.IOException fin du cours d'eau ». Je n'ai pas pu trouver des informations sur si notre serveur d'applications (GlassFish) ne importe quel type de mise en cache pour initialContext.lookup. Y at-il d'autres raisons pour lesquelles les recherches ne manqueront pas jusqu'à ce qu'un redémarrage du serveur? Si initialContext.lookup ne connexions cache, comment pourrais-je contourner cela?

Nos serveurs Sun Run Application Server 9.1. La recherche se fait réellement par org.springframework.jndi.JndiTemplate, mais la trace de la pile indique que le JndiTemplate appelle initialContext.lookup ().

Merci pour toute perspicacité.

P.S. Je dois préciser que je suis en train de déterminer s'il est possible d'éviter d'avoir à redémarrer le serveur A chaque serveur de temps B est redémarré.

Définition de JndiTemplate (avec un texte noirci avec « X 'et '#' s)

<bean id="xxxxxxxxxx"  class="org.springframework.jndi.JndiTemplate">
  <property name="environment">
   <props>
    <prop key="java.naming.factory.url.pkgs">com.sun.enterprise.naming</prop>
    <prop key="java.naming.factory.initial">com.sun.enterprise.naming.SerialInitContextFactory</prop>
    <prop key="java.naming.provider.url">iiop://xxxxxxxxxx:####</prop>
    <prop key="java.naming.factory.state">com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl</prop>
    <prop key="org.omg.CORBA.ORBInitialHost">xxxxxxxxxx</prop>
    <prop key="org.omg.CORBA.ORBInitialPort">####</prop>
   </props>
  </property>
 </bean> 

Et la trace de pile (avec une partie remplacée par '[méthodes d'application]'):

NAM0004: Exception during name lookup : {0}
java.rmi.MarshalException: CORBA COMM_FAILURE 1398079696 Maybe; nested exception is: 
 org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 208 completed: Maybe
 at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:271)
 at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:205)
 at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
 at com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:225)
 at com.sun.enterprise.naming._SerialContextProvider_DynamicStub.lookup(com/sun/enterprise/naming/_SerialContextProvider_DynamicStub.java)
 at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:398)
 at javax.naming.InitialContext.lookup(InitialContext.java:351)
 at org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:155)
 at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:88)
 at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:153)
 at [application methods]
 at org.springframework.web.servlet.mvc.SimpleFormController.processFormSubmission(SimpleFormController.java:267)
 at org.springframework.web.servlet.mvc.AbstractFormController.handleRequestInternal(AbstractFormController.java:265)
 at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
 at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
 at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
 at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
 at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
 at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:738)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
 at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:299)
 at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
 at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
 at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
 at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
 at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
 at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
 at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
 at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
 at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
 at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
 at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
 at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
 at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
 at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
 at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
 at com.sun.enterprise.web.connector.grizzly.ssl.SSLReadTask.process(SSLReadTask.java:440)
 at com.sun.enterprise.web.connector.grizzly.ssl.SSLReadTask.doTask(SSLReadTask.java:228)
 at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
 at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Caused by: org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 208 completed: Maybe
 at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectionAbort(ORBUtilSystemException.java:2862)
 at com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectionAbort(ORBUtilSystemException.java:2880)
 at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doOptimizedReadStrategy(SocketOrChannelConnectionImpl.java:1788)
 at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1263)
 at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
Caused by: org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 211  completed: No
 at com.sun.corba.ee.impl.logging.ORBUtilSystemException.ioexceptionWhenReadingConnection(ORBUtilSystemException.java:2946)
 at com.sun.corba.ee.impl.logging.ORBUtilSystemException.ioexceptionWhenReadingConnection(ORBUtilSystemException.java:2965)
 at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.nonBlockingRead(SocketOrChannelConnectionImpl.java:2000)
 at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doOptimizedReadStrategy(SocketOrChannelConnectionImpl.java:1713)
 ... 2 more
Caused by: java.io.IOException: End-of-stream
 at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.nonBlockingRead(SocketOrChannelConnectionImpl.java:1989)
 ... 3 more

Answer 1

Par la trace de la pile, je peux conclure que Spring Framework lui-même ne cache pas - il invoque en fait InitialContext.lookup(). Pourtant, la trace de la pile et le code d'erreur impliquent qu'il y a une rupture de la connexion.

WebSphere utilisé pour un retour de bug similaire dans les jours qui a été fixé depuis. Se est avéré être un problème de mise en cache fait par le serveur d'application lui-même. Je soupçonne que sunas a un bug similaire dans 9.1 ...

Isaac

Answer 2

Méthode syncChanges () est exécuté périodiquement à des fins de synchonisation. L'idée principale est de contexte proche en cas d'erreur (après le redémarrage de serveur pour exsample) et le réinitialiser. Après contexte de clôture avec la méthode context.close (), vous devez null valeur de ce.

public class SyncOperationsService {
    private InitialContext context;
    private SyncOperationsRemote syncOperationsRemote = null; //RemoteBean

    public String syncChanges() {
        try {
            if (context == null) {
                context = new InitialContext(properties);
            }

            if (context != null) {
                syncOperationsRemote = (SyncOperationsRemote) context.lookup("PathToYourRemoteBean");
            }

            result = syncOperationsRemote.syncChanges(dbImportList);  //Try execute remote bean

        } catch (Exception e) {
            log.error(e.getMessage());

            try {
                context.close();
            } catch (Exception e2) {
                log.error(e2.getMessage());
            }
            context = null;
        }
    }
}