代码之家 › 专栏 › 技术社区 › Michael Borgwardt

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

iiop corba ejb-3.0 glassfish

1

Michael Borgwardt · 技术社区 · 14 年前

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

我的问题是,当被调用的EJB异常中止时,调用方不会收到异常的消息,而是报告一个内部错误,这对诊断该问题根本没有帮助。结果似乎是:

在运输层,a 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 回复 | 直到 14 年前

1

vkraemer 14 年前

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

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

总的来说,黑客会在拥有失败EJB的项目中创建一组自定义异常类。您将使它们非常细粒度地覆盖问题的可能原因,并在它们的名称中提供足够的细节,以标识问题的实际位置。令人讨厌的…但在提交问题并分发修复程序之前,这可能是唯一的选择。

2

1

Brett Kail 14 年前

我能在这里做些什么吗保留有关实际问题的原因?

不幸的是,没有。ORB没有对系统异常(例如,org.omg.corba.*)使用正常的对象序列化,这意味着原因会丢失。正如@vkraemer所说,您需要依赖服务器日志。

3

0

Michael Borgwardt 14 年前

我终于明白了这一点:实际上,Glassfish通过iiop非常正确地传输异常,并且一切都可以正常工作…除非你做这种傻事:

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

是的,正是我们自己的该死的代码接受了异常,并试图在一个分布式事务中调用一个需要EJB方法的事务,该事务由于异常而被回滚。