glassfish域之间的IIOP中丢失异常消息

我正在运行两个包含无状态会话EJB的glassfish v2域。在少数情况下，一个域中的EJB必须调用另一个域中的EJB

我的问题是，当被调用的EJB因异常而中止时，调用方不会收到异常消息，而是报告一个内部错误，这对诊断问题毫无帮助。发生的事情似乎是这样的：

• 在传输层，创建了一个

  org.omg.CORBA.portable.ApplicationException

  ，它已经丢失了除了类之外的所有关于异常的详细信息
• 在

  com.sun.jts.cotransactions.TopCoordinator.get_txcontext（）

  内部，回滚的事务状态会导致抛出

  org.omg.cotransactions.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)
  

---

我可以在这里做些什么来保存有关问题实际原因的信息吗？

问题的原因应该可以在承载有问题的EJB的域的服务器日志中找到

听起来从另一端获取更多信息可能很困难。。。我不知道在创建/抛出ApplicationException时，哪个问题跟踪器将是丢失信息的正确跟踪器

一个彻底的技巧是在包含失败ejb的项目中创建一组自定义异常类。您将使它们非常细粒度，以涵盖问题的可能原因，并以它们的名义提供足够的详细信息，以确定问题的实际位置。恶心。。。但这可能是唯一的选择，直到一个问题被提交和修复被分发

有什么我可以做的吗 保留有关实际事件的信息 问题的原因是什么

---

不幸的是，没有。ORB不对系统异常（即org.omg.CORBA.*）使用普通对象序列化，这意味着原因丢失。正如@vkraemer所说，您需要依赖服务器日志。

我终于弄清了这一点：事实上，Glassfish通过IIOP传输异常非常正确，一切正常。。。除非你做了这样愚蠢的事：

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

是的，是我们自己的该死的代码吞下了异常，并试图在由于异常而回滚的分布式事务中调用需要EJB方法的事务