INALITYCONTEXT.LOKUUP удаленного EJB не удается после перезапуска удаленного сервера
https://stackoverflow.com/questions/3936739
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
У нас есть настройка, в которой EJB A работает на сервере A, а другой EJB B работает на сервере B. EJB A подключается к EJB B через IIOP. Эта настройка нормально работает, но если сервер B перезапускается, EJB A не удается до тех пор, пока сервер A не будет перезапущен.
Вопрос в том, что если сервер B перезапускается, все вызовы на INALITCONText.lookup по ejb a сбоя с исключением "java.io.ioeexception: java.io.ioeexception: End-Stream", пока сервер A не перезапущен. Я не смог найти информацию о том, является ли наш сервер приложений (Glassfish) какой-либо кэширование для INALITYCONTEXT. LOOKUUP. Есть ли другие причины, по которым поиск потерпит неудачу до перезагрузки сервера? Если InationalContext.lookup делает Cache Connections, как бы я обошел это?
Наши серверы управляют сервером приложений SUN 9.1. Просмотр на самом деле сделан через org.springframework.jndi.jnditemplate, но трассировка стека говорит, что jnditemplate вызывает initivencontext.lookup ().
Спасибо за любое понимание.
PS Я должен уточнить, что я пытаюсь выяснить, можно ли избегать необходимости перезапустить сервер A каждый временной сервер B перезапущен.
Определение jnditemplate (с помощью некоторого текста отброшенного с помощью 'x's и'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>
И трассировка стека (с одной частью заменена «методами приложения]»):
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
Решение
По трассировке стека я могу заключить, что сама весенние рамки не кеша - это на самом деле вызывает InitialContext.lookup(). Отказ Тем не менее, трассировка стека и код ошибки подразумевает, что есть поломки подключения.
WebSphere использовал, чтобы иметь аналогичную ошибку в те дни, что было исправлено с тех пор. Оказалось, что проблема кэширования, выполненная самим сервером приложений. Я подозреваю, что Sunas подобная ошибка в 9.1 ...
Исаак
Другие советы
Метод SyncChanges () периодически бегает для целей синхонизации. Основная идея заключается в том, чтобы закрыть контекст, если возникает ошибка (после перезапуска сервера для exsample) и повторно повторно повторно. После закрытия контекста с помощью метода Context.close () вы должны ноль его значение.
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;
}
}
}
