المكالمات يبلوغيتش EJB تبدأ بالفشل تحت الحمل المعتدل مع OptionalDataException

Question

وإعداد النظام لدينا يتكون من اثنين من يبلوغيتش 10.3 خوادم: واحد المضيفين طبقة العرض وغيرها من المضيفين ولل EJBs. النظام يعمل غرامة بموجب حمولة المعتدل لبعض الوقت (واحد إلى عدة أيام) وبعد ذلك استدعاءات الأسلوب EJB من خادم عرضها على خادم EJB تبدأ فشل مع الخطأ التالي:

java.rmi.RemoteException: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.io.OptionalDataException

وتتبع المكدس:

java.io.OptionalDataException
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1349)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
    at weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:197)
    at weblogic.rjvm.MsgAbbrevInputStream.readObject(MsgAbbrevInputStream.java:564)
    at weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:193)
    at weblogic.jndi.internal.RootNamingNode_WLSkel.invoke(Unknown Source)
    at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:589)
    at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:230)
    at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:477)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
    at weblogic.security.service.SecurityManager.runAs(Unknown Source)
    at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:473)
    at weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118)

وبمجرد واجه OptionalDataException أولا تفشل كافة المكالمات اللاحقة مع نفس النتيجة. وتشير بعض المصادر إلى أن هذا قد يكون المتصلة بالمجموعة ميناء المتعدد يجري تهيئتها بطريقة خاطئة. ومع ذلك، هذه الملقمات لا تنتمي إلى كتلة.

والركل خادم EJB دائما يحل مؤقتا هذه القضية، ولكن يبدو أن المشكلة تحدث مرة أخرى بعد مرور بعض الوقت.

تحديث : يبدو أن المشكلة هي <م> لا تتعلق حدث تجاوز في عدد الاتصالات مأخذ بعد كل شيء (انظر جوابي الخاصة أدناه). بعد تنكر classloading شبكة ركضنا نحو مطرد جدا لمدة أسبوع وبعد ذلك بدأنا تلقي OptionalDataExceptions على خادم العرض مرة أخرى (تتبع مكدس أدناه). فمن الغريب جدا أن النظام يعمل بشكل جيد لمدة أسبوع ثم يبدأ الفشل.

javax.naming.CommunicationException [Root exception is java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
    java.io.OptionalDataException]
    at weblogic.jndi.internal.ExceptionTranslator.toNamingException(ExceptionTranslator.java:74)
    at weblogic.jndi.internal.WLContextImpl.translateException(WLContextImpl.java:439)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:395)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:380)
    at javax.naming.InitialContext.lookup(InitialContext.java:392)
    ...
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:

    java.io.OptionalDataException
    at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:234)
    at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:348)
    at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:259)
    at weblogic.jndi.internal.ServerNamingNode_1030_WLStub.lookup(Unknown Source)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:392)  
    ... 38 more
Caused by: java.io.OptionalDataException
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1349)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
    at     
    weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:197)
    at weblogic.rjvm.MsgAbbrevInputStream.readObject(MsgAbbrevInputStream.java:564)
    at     
weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:193)
    at weblogic.jndi.internal.RootNamingNode_WLSkel.invoke(Unknown Source)
    at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:589)
    at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:230)
    at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:477)
    at        
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
    at weblogic.security.service.SecurityManager.runAs(Unknown Source)
    at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:473)
    at weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118)
    ... 2 more

ونحصل على سياق الأولي تماما الطريقة القياسية:

Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
p.put(Context.PROVIDER_URL, serverPath);
Context context = new InitialContext(p);

ويدعو أيضا إلى أي المراجع التي تم الحصول عليها تفشل مع OptionalDataException ما شابه ذلك. تمهيد خادم العرض وحدها على حل المشكلة مؤقتا.

Answer 1

وأخيرا OptionalDataExceptions جزءا من التاريخ. باختصار، في رمز التطبيق لدينا زيارتها كائن معقد القيمة (التي تستخدم كقيمة مقابل الدعاء طريقة عن بعد) لبنية بيانات HashMap كحقل الداخلي. بعد تغيير نوع هذا الحقل لSynchronizedMap توقف OptionalDataExceptions الحدوث. يبدو أنه في مكان ما في قانون الإرث تتم معالجة هذه الخريطة في الطريق غير آمن موضوع.

والغريب هو أن هذا تسبب أي مشاكل مع WLS 8.1، ولكنه تسبب بطريقة أو بأخرى ولس 10 الدخول في حالة حيث كل الدعاء طريقة النائية لاحقة (بما في ذلك عمليات البحث JNDI) بدأت تفشل.

Answer 2

وأخيرا وجدنا الحل لهذه (تحرير: بعد وجدنا أن هذا لم يكن السبب الجذري لهذه المسألة، ولكن مسألة خطيرة منفصلة على الحل النهائي، الرجاء مراجعة الإجابة أدناه). عندما بدأنا في الحصول على الاستثناء التالي وصلنا على المسارين للقضية:

<BEA-000403> <IOException occurred on socket: Socket[addr=/x.x.x.x,port=3266,localport=7001]
 java.net.SocketException: Connection refused.
java.net.SocketException: Connection refused
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:887)
at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:859)
at weblogic.socket.DevPollSocketMuxer.processSockets(DevPollSocketMuxer.java:120)
at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:29)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:42)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:145)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)

في الخادم العرض، الذي يعمل على مجموعة مختلفة من خادم EJB كان لدينا خيار

-Dweblogic.NetworkClassLoadingEnabled=true

ولتمكين الواضح تحميل الطبقة من خادم EJB. ما لم نكن نعرفه هو أن استخدام هذا الخيار يمكن أن يؤدي إلى عدد كبير من مآخذ شبكة يتم فتح. استخدام NETSTAT تمكنا من معرفة أن عدة آلاف من مآخذ كانت إما في CLOSE_WAIT أو حالة FIN_WAIT_2. ويبدو أن جميع العناصر في واجهة المستخدم على شبكة الإنترنت تم تحميل من خادم EJB بالإضافة إلى الطبقات على الرغم من أن ملف الحرب على خادم العرض يتضمن كل هذه. لم كمية هائلة من مآخذ لا يؤدي إلى "العديد من الملفات" رسائل خطأ منذ يبلوغيتش يزيل ulimit عن الملفات في البرنامج النصي بدء التشغيل الخاص به. باستخدام خادم اختبار وجدنا أن بنقرة واحدة على واجهة المستخدم على شبكة الإنترنت من قبل المستخدم فتح حوالي 30 مآخذ بين ملقمات اثنين.

وأزلنا هذا الخيار وإعادة تجميعها الحرب على خادم العرض لاحتواء جميع الطبقات المطلوبة وبالتالي إزالة الحاجة إلى classloading الشبكة. وأدى ذلك إلى انخفاض في عدد الاتصالات مأخذ توصيل بين ملقمات اثنين من آلاف إلى 1.

في ملخص، تجنب شبكة الطبقة تحميل في يبلوغيتش إذا كان ذلك ممكنا.