Ausnahmemeldung in IIOP zwischen Glasfischen Domains verloren

Question

Ich bin mit zwei Glassfish v2 Domänen Stateless Session EJBs enthalten. In einigen Fällen hat ein EJB in einer Domäne eine in der anderen zu nennen.

Mein Problem ist, dass, wenn die genannte EJB Abbrüchen mit einer Ausnahme, wird der Anrufer die Nachricht nicht von der Ausnahme erhalten und stattdessen einen internen Fehler meldet, die überhaupt in der Diagnose des Problems nicht hilfreich ist. Was passiert, scheint dies zu sein:

• Auf der Transportschicht, eine org.omg.CORBA.portable.ApplicationException geschaffen, die bereits alle Informationen über die Ausnahme mit Ausnahme seiner Klasse Detail verliert.

• Innerhalb com.sun.jts.CosTransactions.TopCoordinator.get_txcontext(), der Status der Transaktion ass zurückgerollt bewirkt eine org.omg.CosTransactions.Unavailable geworfen werden, die um ein paar Mal gewickelt und übergeben wird und schließlich führt in diesen Fehler dem Benutzer angezeigt werden:

  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)
  

Gibt es etwas, was ich hier tun kann Informationen über die tatsächliche Ursache des Problems zu erhalten?

Answer 1

I finally got to the bottom of this: actually, Glassfish transmits exceptions through IIOP quite correctly and everything works as it should... unless you do something idiotic like this:

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

Yeah, it was our own damn code that swallowed the exception and tried to call a transaction-requiring EJB method within a distributed transaction that's been rolled back due to the exception.

Answer 2

Die Ursache des Problems sollte die EJB im Serverprotokoll der Domänen verfügbar sein Hosting, die ein Problem hatte.

Es klingt wie mehr Infos zurück vom anderen Ende immer schwierig sein kann ... Ich weiß nicht, welche issue tracker die richtigen für die verlorenen Informationen sein würde, wenn das Application erstellt / geworfen.

Insgesamt Hack wäre eine Reihe von benutzerdefinierten Ausnahmeklassen im Projekt zu erstellen, das die ejb hat, die versagt hat. Sie würden sie sehr feinkörnig machen die wahrscheinlichen Ursachen des Problems zu decken und detailliert genug in ihrem Namen zur Verfügung stellen den tatsächlichen Ort des Problems zu identifizieren, zu. Yucky ... aber das ist vielleicht die einzige Wahl sein, bis ein Thema eingereicht wird und das Update verteilt.

Answer 3

Is there anything I can do here to preserve information about the actual cause of the problem?

Unfortunately, no. The ORB does not use normal object serialization for system exceptions (i.e., org.omg.CORBA.*), which means that causes are lost. As @vkraemer said, you'll need to rely on server logs.