Czy są jakieś nieoczywiste niebezpieczeństwa w używaniu wątków w ASP.NET?

Question

To jest coś z rodzeństwa pytanie do this programmers question.

Krótko mówiąc, zamierzamy popchnąć trochę pracy, która była "prosięta" na żądania użytkowników w tle "prawidłowo". Połączone pytanie dało mi mnóstwo pomysłów, jeśli pójdziemy drogą serwisową, ale tak naprawdę nie dostarczyliśmy żadnych przekonujących argumentów na temat tego, dlaczego właśnie powinniśmy.

Muszę przyznać, że dla mnie, umiejętność zrobić moralnym odpowiednikiem

WorkQueue.Push(delegate(object context) { ... }); 

jest bardzo atrakcyjne, więc jeśli jej tylko trochę trudne (raczej niż nieodłącznie niewykonalne) jestem skłonny iść z podejściem wątku tła.

Tak, problemy z tła wątków Jestem świadomy (w kontekście AppPool):

• mogą umrzeć w każdej chwili ze względu na AppPool zawraca
  • Rozwiązanie: śledzić, gdy zadanie jest wykonywane, więc można go ponownie uruchomić * nowy wątek powinien być potrzebne
• The ThreadPool służy do odpowiedzi na przychodzących zapytań HTTP, więc użycie może głodować IIS
  • Rozwiązanie: zbuduj własną pulę wątków, ograniczając również liczbę wątków.

Moje pytanie brzmi, co mi brakuje, czy coś? Co jeszcze może pójść nie tak z wątkami tła w ASP.NET?

_{* Zadania, o których mowa, są już bezpieczne do ponownego uruchomienia, więc nie stanowi to problemu.
ǂ Załóżmy, że nie robimy niczego naprawdę głupiego, na przykład rzucania wyjątków w wątkach tła.}

Answer 1

Jednym z niebezpieczeństw, na które osobiście natrafiłem, jest kontekst połączenia. Użyliśmy CallContext do ustawienia danych tożsamości użytkownika, ponieważ ten sam kod został udostępniony w naszej aplikacji internetowej i naszych usługach aplikacji opartych na .NET Remoting (który jest zaprojektowany do używania CallContext do przechowywania danych specyficznych dla połączenia) - więc nie używaliśmy HttpContext.

Zauważyliśmy, że czasami nowe żądanie kończy się na niezerowej tożsamości w CallContext. Innymi słowy, ASP.NET nie zerwał danych przechowywanych w wywołaniu połączenia między żądaniami ... i w ten sposób nieuwierzytelniony użytkownik mógł uzyskać dostęp do aplikacji, gdyby wybrał wątek, który nadal zawierałby kod połączenia z potwierdzonymi danymi tożsamości użytkownika.

Answer 2

Opowiem ci o zakaz oczywistego niebezpieczeństwa :)

użyłem wątki zebrać Aktualizacja karmi niektórzy RSS do mojej bazy danych na stronie internetowej byłem hosting z GoDaddy. Wątki działały poprawnie (jeśli zostały przerwane, zostałyby automatycznie uruchomione ponownie z powodu pewnych kontroli, które zbudowałem na niektórych stronach internetowych).

To działało znakomicie i byłem bardzo szczęśliwy, dopóki GoDaddy (mój gospodarz wtedy) nie zaczął zabijać wątków, a następnie zablokował je całkowicie. Moja aplikacja po prostu umarła!

Jeśli to nie było oczywiste, co to jest?

Answer 3

Można być nadmiernie komplikującym architekturę bez żadnych korzyści.

Program będzie droższy w pisaniu, droższy w utrzymaniu i ma większe szanse na błędy.

Answer 4

Będę z dala od uruchamiania wątków z przy pomocy twojego AppDomain IIS dla StackOverflow. Nie mam żadnych mocnych dowodów na poparcie tego, co mam zamiar powiedzieć, ale pracując z IIS przez 10 lat, wiem, że działa najlepiej, gdy jest to jedyna gra w mieście.

Istnieje również alternatywa, wiem, że będzie to pewnego rodzaju wątek programistów w postaci take off on my answer. Ale jak rozumiem, masz już rozwiązanie, które działa na zasadzie piggy-backing pracy nad żądaniami użytkowników. Dlaczego nie używać tego kodu, ale uruchamiać go tylko wtedy, gdy wywoływany jest specjalny wewnętrzny API. Następnie użyj komendy Task Scheduler, aby wywołać komendę CURL, która wywołuje ten interfejs API co 30 sekund w celu uruchomienia zadań. W ten sposób pozwalasz programowi IIS obsługiwać wątki, a Twój kod obsługuje coś, co już jest łatwe.