ما الذي يمكن أن يتسبب في إعادة تدوير العملية المنفذة لـ ASP.NET؟

Question

وهنا سؤالي الحالي:

أعتقد أن مشكلتي (الموصوفة أدناه) ناتجة عن إعادة تدوير العمليات العاملة لـ ASP.NET، وفقًا للإجابات أدناه - أنا أستخدم تخزين جلسات InProc ولا أرى فرصة كبيرة للابتعاد، بسبب التقييد بالنسبة لأنواع التخزين الأخرى، تكون جميع كائنات الجلسة قابلة للتسلسل.ومع ذلك، لا يمكنني معرفة ما الذي يجعل العملية المنفذة يتم إعادة تدويرها بقدر ما أراها - لم يكن هناك أي تغيير في الملفات الموجودة في دليل التطبيق على حد علمي، ويبدو أن الخيارات الموجودة في IIS للإشارة إلى أنه سيتم إعادة تدوير العملية فقط كل 1740 دقيقة، وهو أقل تكرارًا بكثير من الخسارة الفعلية للجلسة.لذا، سؤالي الآن هو، ما هي الحالات المختلفة التي يمكن أن تتسبب في إعادة تدوير العملية المنفذة لـ ASP.NET؟

هنا سؤالي الأصلي:

أواجه مشكلة صعوبة إعادة الإنتاج التي تحدث في تطبيق الويب ASP.NET الخاص بي.يحتوي التطبيق على صفحة .aspx رئيسية واحدة يتم تحميلها وتهيئة عدد من متغيرات جلسة العمل.تستخدم هذه الصفحة ASP.NET Ajax Sys.Net.WebRequest فئة للوصول بشكل متكرر إلى صفحة .aspx أخرى، والتي تستخدم متغيرات الجلسة لإجراء استعلامات قاعدة البيانات وتحديث الصفحة الرئيسية (لا تتم إعادة طلب الصفحة الرئيسية أبدًا).

في بعض الأحيان، بعد فترة من الوقت من استخدام الصفحة، مما يتسبب في نجاح طلبات HTTP حيث تنتقل الجلسة التي تم إنشاؤها في الصفحة الرئيسية بشكل صحيح إلى الصفحة الفرعية، يبدو أن أحد الطلبات يتسبب في إنشاء جلسة ASP.NET جديدة - الجلسة بأكملها يتم فقدان المتغيرات (مما يتسبب في ظهور استثناء في الكود الخاص بي)، ويتم الإبلاغ عن معرف جلسة جديد في الصفحة المطلوبة ديناميكيًا.وهذا يعني أنه فجأة يتم قطع اتصال الصفحة الرئيسية بالخادم - وبقدر ما يتعلق الأمر بالخادم، لم يعد المستخدم مسجلاً للدخول.

أنا متأكد تقريبًا من أنها ليست مهلة جلسة - تم ضبط وقت المهلة على شيء مثير للسخرية، ومقدار الوقت المستغرق لتحقيق ذلك متغير ولكنه ليس طويلًا بما يكفي للتسبب في انتهاء مهلة الجلسة، و ثابت Sys.Net.WebRequests يجب تحديث مؤقت الجلسة.

إذًا، ما الذي قد يحدث أيضًا والذي قد يتسبب في فقدان طلبات HTTP للاتصال بجلسة ASP.NET؟لسوء الحظ، لم أتعرف على حركة مرور الشبكة عندما حدث هذا لي، أو كنت سأتحقق مما إذا كان ملف تعريف الارتباط لجلسة ASP.NET عالقًا أم لا.

Answer 1

أحد الحلول هو استخدام StateServer، بدلاً من إدارة جلسة InProc.

يمكن أن تتسبب الكثير من الأشياء في فقدان حالة الجلسة:

1. تحرير Web.Config
2. إعادة تعيين IIS
3. إلخ.

إذا كانت حالة الجلسة مهمة لتطبيقك، فاستخدم إما إدارة حالة SQL أو خادم الحالة الذي يأتي مع ASP.شبكة.

هتافات،

ر.ب.

Answer 2

واجهنا مشاكل في الجلسة عندما قمنا بترحيل تطبيق Ankerex إلى الخادم الجديد.كان لدى الخادم الجديد Microsoft Windows Server 2008 كنظام تشغيل وخدمات معلومات الإنترنت Microsoft 7.كما تم تثبيت الخادم .NET Framework للإصدارات 1.0.3705 و 1.1.4322 و 2.0.50727 و 3.0 و 3.5.لحل هذه المشكلة ، قمت بتمكين المراقبة الصحية للأحداث المتعلقة بعمر التطبيق في ASP.NET 2.0.لقد أضفت إلى web.config:

...
...
<system.web>
...
...
    <healthMonitoring>
      <rules>
        <add name="Application Events"
            eventName="Application Lifetime Events"
            provider="EventLogProvider"
            profile="Default"
            minInterval="00:01:00" />
      </rules>
    </healthMonitoring>
...
...

من المفيد لنا التحقق من عمليات إعادة تدوير AppDomain.يمكننا رؤيته في عارض الأحداث لدينا.الرابط للمزيد من التفاصيل هو http://blogs.msdn.com/rahulso/archive/2006/04/13/575715.aspx

بعد أن انتهيت من الإضافة إلى web.config ، أوضح لي عارض الحدث أن طلبي يعيد تشغيله في كل مرة عندما أقوم بنقر على أي رابط تقريبًا في طلبي.من مقال http://blogs.msdn.com/toddca/archive/2005/12/01/499144.aspx اكتشفت أن ASP.NET لديه السلوك الجديد - إذا كنا سنقوم بحذف ، على سبيل المثال دليل فرعي لدليل الجذر للتطبيق ، فإن ASP.NET 2.0 سيفعل AppDomain إعادة التشغيل.

كانت المشكلة في أنني تلقيت التعليمات في web.config:

...
<compilation debug="true" tempDirectory="c:\AnkerEx\Temporary ASP.NET files">
...

أي.قام ASP.NET بتجميع صفحات aspx في مجلد جذر التطبيق الخاص بي.أعتقد أنه أنشأ مجلدات، وربما قام بإزالة بعضها أيضًا.لقد أزلت تعليمات TempDirectory وبدأ التطبيق في العمل.

Answer 3

من المحتمل أن تكون عملية العامل هي ركوب الدراجات.http://www.lattimore.id.au/2006/06/03/iis-dropping-sessions/

Answer 4

يمكن أن يكون سبب ذلك استثناءً لم تتم معالجته في سلسلة محادثات في الخلفية.يمكن أن يتسبب في إنهاء عملية عامل ASP.NET الخاصة بك.تبدأ عملية جديدة بسرعة كبيرة بحيث لا تلاحظها فعليًا ولكن يتم فقدان جميع جلساتك.

إليك مقال يشرح ذلك أفضل بكثير مما أستطيع: مشكلات الاستثناء غير المعالجة لـ ASP.NET 2.0

يقتبس:

عادةً ما يؤدي الاستثناء غير المعالج في تطبيق ASP.NET 2.0 قيد التشغيل إلى إنهاء عملية W3WP.exe، ويترك لك إدخال سجل الأحداث المشفر للغاية مثل هذا:

"EventType clr20r3، P1 w3wp.exe، P2 6.0.3790.1830، P3 42435be1، P4 app_web_ncsnb2-n، P5 0.0.0.0، P6 440a4082، P7 5، P8 1، P9 system.nullreferenceexception، P10 NIL."

إليك مقالة Microsoft KB التي تشرح نفس المشكلة: KB911816 تؤدي الاستثناءات غير المعالجة إلى إنهاء التطبيقات المستندة إلى ASP.NET بشكل غير متوقع في .NET Framework 2.0

Answer 5

تخميني سيكون استهلاك الذاكرة - ولكن، إعداد IIS لتسجيل عمليات إعادة التدوير وسوف تعرف على وجه اليقين.