InitialContext.lookup удаленных EJB сбой после удаленного перезапуска сервера

Question

У нас есть настройка, в которой EJB A работает на сервере A, а другой EJB B работает на сервере B. EJB A подключается к EJB B через IIOP. Обычно эта настройка работает, но если сервер B перезагружен, EJB A завершится с ошибкой до перезапуска сервера A.

Проблема заключается в том, что при перезапуске сервера B все вызовы InitialContext.lookup с помощью EJB A завершаются с исключением «java.io.IOException: End-of-stream» до перезапуска сервера A. Мне не удалось найти информацию о том, делает ли наш сервер приложений (GlassFish) любое кэширование для InitialContext.lookup. Существуют ли какие-либо другие причины, по которым поисковые запросы терпят неудачу, пока сервер не перезапустится? Если InitialContext.lookup выполняет кэширование соединений, как мне обойти это?

Наши серверы управляют сервером приложений Sun 9.1. Поиск выполняется на основе org.springframework.jndi.JndiTemplate, но трассировка стека говорит, что JndiTemplate вызывает InitialContext.lookup().

Спасибо за понимание.

P.S. Я должен уточнить, что я пытаюсь выяснить, возможно ли избежать перезапуска сервера A при каждом перезапуске сервера B.

Определение JndiTemplate (с текстом затемненном с «крестиками и„#“с)

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

и стек трассировки (с одной стороны заменены„[методы применения]“):

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

По трассе стека я могу заключить, что сама Spring Framework не кэширует - на самом деле она вызывает InitialContext.lookup(). Тем не менее, трассировка стека и код ошибки означают, что есть разрыв соединения.

У WebSphere раньше были похожие ошибки, которые были исправлены с тех пор. Оказалось, что это проблема кэширования, выполняемая самим сервером приложений. Я подозреваю, что SunAS имеет аналогичную ошибку в 9.1 ...

Исаак

Answer 2

Метод syncChanges() периодически работает для Synchonization цели. Основная идея заключается в закрытии контекста, если возникает ошибка (после перезапуска сервера для exsample) и повторной инициализации. После закрытия контекста с помощью метода context.close() вы должны указать его значение.