رسالة استثناء تضيع في IIOP بين مجالات Glassfish

Question

أنا أقوم بتشغيل مجالين Glassfish V2 الذي يحتوي على جلسة EJBs عديمة الجنسية. في حالات قليلة ، يتعين على 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)
  

هل هناك أي شيء يمكنني القيام به هنا للحفاظ على المعلومات حول السبب الفعلي للمشكلة؟

Answer 1

وصلت أخيرًا إلى أسفل هذا: في الواقع ، ينقل Glassfish الاستثناءات عبر IIOP بشكل صحيح تمامًا وكل شيء يعمل كما ينبغي ... ما لم تفعل شيئًا غبيًا مثل هذا:

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

نعم ، كان رمزنا اللعين الخاص هو الذي ابتلع الاستثناء وحاول استدعاء طريقة EJB التي تتطلب المعاملة ضمن معاملة موزعة تم ترحيلها بسبب الاستثناء.

Answer 2

يجب أن يكون سبب المشكلة متاحًا في سجل خادم المجالات التي تستضيف EJB التي تعاني من مشكلة.

يبدو أن الحصول على مزيد من المعلومات من الطرف الآخر قد يكون أمرًا صعبًا ... لا أعرف أي مشكلة ، سيكون متتبعًا هو الصحيح للمعلومات المفقودة عند إنشاء/إلقاء Applicationexception.

سيكون الاختراق التام هو إنشاء مجموعة من فئات الاستثناءات المخصصة في المشروع الذي يحتوي على EJB الذي فشل. ستجعلها جيدة جدًا لتغطية الأسباب المحتملة للمشكلة وتقديم تفاصيل كافية باسمهم لتحديد الموقع الفعلي للمشكلة أيضًا. Yucky ... ولكن قد يكون هذا هو الخيار الوحيد حتى يتم تقديم مشكلة ويتم توزيع الإصلاح.

Answer 3

هل هناك أي شيء يمكنني القيام به هنا للحفاظ على المعلومات حول السبب الفعلي للمشكلة؟

للاسف لا. لا يستخدم الجرم السماوي تسلسل الكائن الطبيعي لاستثناءات النظام (أي ، org.omg.corba.*) ، مما يعني فقدان الأسباب. كما قال VKraemer ، ستحتاج إلى الاعتماد على سجلات الخادم.