‫داستان بی‌سوادی ما – ۶: Application Pool

یکی از مشکلات عجیب و غریب ما این بود که یکی از پروژه‌های ما مشکلات عجیبی با IIS داشت. این پروژه (الف) از پروژه‌ی دیگری (ب) مشتق شده بود. یعنی هر آن چه که در پروژه‌ی «ب» موجود بود در پروژه‌ی «الف» هم بود. پروژه‌ی «ب» هیچ مشکلی نه در ASP.NET Development Server و نه در IIS نداشت. اما پروژه‌ی «الف» در ASP.NET Development Server درست کار می‌کرد ولی در IIS نه.

این موضوع باعث اختلاف نظرهای زیادی شده بود. تا این که یک روز فهمیدم مشکل پروژه‌ی «الف» کجاست. علت، مقایسه‌ی آبجکت‌ها در حافظه بدون استفاده از ID آنها بود. این مقایسه در ASP.NET Development Server درست کار می‌کرد ولی در IIS درست کار نمی‌کرد. بعد از رفع مشکل هنوز این سوال برایم وجود داشت که چرا پروژه‌ی «ب» دچار چنین مشکلی نشده بود؟

یک روز که دنبال چیز دیگری در IIS بودم متوجه شدم که هر کدام از این پروژه‌ها از یک Application Pool مختلف برای کار خود استفاده می‌کنند. پروژه‌ی «ب» از Classic .NET AppPool استفاده می‌کرد ولی پروژه‌ی «الف» از DefaultAppPool. فرق این دو هم فقط در Pipline بود. اولی Classic بود و دومی Integrated. محض امتحان یک بار Application Pool پروژه‌ی «الف» را به Classic عوض کردم و آن مقایسه‌ای آبجکتی را دوباره به حالت بدون ID برگرداندم. در کمال ناباوری مشکل اولیه‌ی پروژه‌ی «الف» حل شد!

در واقع مشکل پروژه‌ی «الف» را می‌شد با درک بهتری از Pipeline زودتر کشف کرد که به علت بی‌سوادی و بی‌اطلاعی این موضوع اتفاق نیفتاده بود. البته الان می‌دانم علت خرابی کار Pipeline بوده ولی هنوز هم درک نمی‌کنم چرا.

Comments

  1. Afshar Mohebbi

    ‫می‌خواهم عصبانیت خودم را از دست خودم نشان دهم که چرا چنین چیزی را زودتر از این نفهمیده بودم. ضمناً فکر می‌کنم یک جورایی علت این مشکل خود ما برنامه‌نویس‌ها هستیم که با بی‌تفاوتی از کنار بعضی چیزهای مهم می‌گذریم.

  2. ناشناس

    برای مسائل امنیتی، بهینه سازی و … بهتره به ازاء هر وب سایت یک‫ ‫Application Pool جدا داشته باشید.
    این کار درستی نیست که همه وبسایتهای روی یک IIS را بر روی یک‫ Application Pool آن هم‫ Classic بگذارید.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *