сообщение об исключении теряется в IIOP между доменами glassfish - PullRequest
Новая
       91

сообщение об исключении теряется в IIOP между доменами glassfish

1 голос
/ 25 мая 2010

Я управляю двумя доменами glassfish v2, содержащими EJB сессий без сохранения состояния. В некоторых случаях EJB в одном домене должен вызывать один в другом.

Моя проблема в том, что когда вызываемый EJB прерывает работу с исключением, вызывающая сторона не получает сообщение об исключении и вместо этого сообщает о внутренней ошибке, которая вообще не помогает в диагностике проблемы. Кажется, что происходит так:

  • На транспортном уровне создается org.omg.CORBA.portable.ApplicationException, который уже теряет всю подробную информацию об исключении, кроме его класса.

  • Внутри com.sun.jts.CosTransactions.TopCoordinator.get_txcontext(), состояние отката задницы транзакции вызывает выброс org.omg.CosTransactions.Unavailable, который оборачивается и передается несколько раз и в конечном итоге приводит к отображению этой ошибки пользователю: 

    org.omg.CORBA.INVALID_TRANSACTION:   vmcid: 0x0  minor code: 0  completed: No
at com.sun.jts.CosTransactions.CurrentTransaction.sendingRequest(CurrentTransaction.java:807)
at com.sun.jts.CosTransactions.SenderReceiver.sending_request(SenderReceiver.java:139)
at com.sun.jts.pi.InterceptorImpl.send_request(InterceptorImpl.java:344)
at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeClientInterceptorStartingPoint(InterceptorInvoker.java:271)
at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeClientPIStartingPoint(PIHandlerImpl.java:348)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:284)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:184)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:186)
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)

Могу ли я здесь что-нибудь сделать, чтобы сохранить информацию о действительной причине проблемы?

Ответы [ 3 ]

1 голос
/ 28 мая 2010

Есть ли что-нибудь, что я могу сделать здесь, чтобы сохранить информацию о фактическом причина проблемы?

К сожалению, нет. ORB не использует обычную сериализацию объектов для системных исключений (то есть org.omg.CORBA. *), Что означает, что причины потеряны. Как сказал @vkraemer, вам нужно полагаться на логи сервера.

1 голос
/ 27 мая 2010

Причина проблемы должна быть доступна в журнале сервера доменов, на которых размещен EJB, в котором возникла проблема.

Похоже, получение дополнительной информации с другого конца может быть затруднено ... Я не знаю, какой из средств отслеживания проблем будет правильным для информации, потерянной при создании / отбрасывании ApplicationException.

Хаком было бы создание набора пользовательских классов исключений в проекте, в котором был неудачный ejb. Вы могли бы сделать их очень мелкозернистыми, чтобы охватить вероятные причины проблемы и предоставить достаточно подробных сведений в их названии, чтобы также определить фактическое местонахождение проблемы. Гадкий ... но это может быть единственный выбор, пока проблема не будет подана и исправление не будет распространено.

0 голосов
/ 24 июня 2010

Я наконец дошел до сути: на самом деле Glassfish передает исключения через IIOP довольно корректно, и все работает как надо ... если вы не сделаете что-то идиотское вроде этого: 

try{
    ejb.getFoo();
}catch (Exception e){
    // try again
    ejb.getFoo();
}

Да, это был наш собственный проклятый код, который поглотил исключение и попытался вызвать требующий транзакции метод EJB в распределенной транзакции, откат которой произошел из-за исключения.

...