Sesja MVC3 .NET losowo tracąca wartość sesji i zwracana jako wartość pusta

Question

Mam problem z produkcją ze stanem sesji In-Proc.

Nasza aplikacja bazuje na platformie MVC 3 .NET i jest zintegrowana z naszą witryną z systemem Sitecore CMS.

Nasi użytkownicy mieli "Odwołanie do obiektu nie ustawione do instancji obiektu" losowo przez cały proces aplikacji.

Po obszernym rejestrowaniu i śledzeniu mogliśmy wywnioskować, że było to spowodowane tym, że obiekt sesji zwrócił wartość null.

Oto kilka szczegółów na temat tego, co znaleźliśmy i co wiemy.

1. Identyfikator sesji jest trwały dla tego samego użytkownika i poprawnie przekazał wszystkie numery do aplikacji.
2. Nie sądzę, że jest to problem związany z kodem, ponieważ dzieje się tak tylko podczas losowania, nigdy nie zdarza się to w środowisku lokalnym, deweloperskim lub w środowisku testowym.
3. Przez serwer obciążenia działa dwa serwery produkcyjne.
4. Nie jest to stały problem związany z serwerem, ponieważ przetestowaliśmy go, przesypiając jeden z serwerów i mając całą trasę ruchu do jednego serwera. Również dzięki rejestrowaniu możemy zidentyfikować, że użytkownik trafia na ten sam serwer, ale sesja stała się pusta.
5. Nie wydaje się to również problemem dla klienta, ponieważ może on pomyślnie przejść przez aplikację, nawet jeśli wcześniej napotkał błąd.
6. Nie wydaje się to problemem związanym z obciążeniem ruchem lub obciążeniem serwera, ponieważ dzieje się tak przez cały dzień w przypadkowych momentach i zdarza się przypadkowym użytkownikom podczas.
7. To nie wydaje się być spowodowane przez recykling puli aplikacji.
8. Nie wydaje się, że jest to spowodowane przekroczeniem limitu czasu sesji, ponieważ ustawiliśmy limit czasu na dwie godziny i podczas śledzenia dziennika użytkownicy mogą doświadczyć tego 5-10 minut w przepływie.

Uwaga boczna: Musimy używać stanu sesji In-Proc dzięki naszemu systemowi Sitecore CMS. Zatem zmiana projektu nie jest opcją.

Mam pewną teorię, która może mieć coś wspólnego z blokowaniem sesji lub uszkodzeniem podczas prób dostępu równoczesnego.

Kilka razy widzimy występowanie tego problemu z naszej aplikacji, gdy użytkownicy są przekierowywani przez javascript (windows.location).

W obszarach, w których wykonywane są asynchroniczne wywołania ajax.

Przez chwilę drapaliśmy się głowami, zastanawiam się, czy ktokolwiek z zewnątrz miałby jakąkolwiek wiedzę na temat problemu?

Dzięki

Dodano Uwaga:

@Mystere & & @ H27Studio, więc odkryłam też coś odnoszącego się do sessionid lub sesyjnych kwestii resetowania.W niektórych przypadkach odkrywamy, że na przekierowaniu strony wywołuje on dwa zduplikowane wywołania GETS do metody, przy pierwszym wywołaniu brakuje identyfikatora sesji i losowo zostaje przekierowany do jednego z serwerów (Dzieje się tak, ponieważ trwała sesja serwera z modułu równoważenia obciążenia jest opierać się na IP klienta, identyfikatorze sesji i innych informacjach nagłówka, aby utworzyć unikalną sesję utrzymywania klienta na jednym serwerze). Dzieje się tak za każdym razem, gdy strona przekierowania korzysta z window.location.

Spowoduje to, że problem "Brak odwołania do obiektu .." dla klienta, jeśli złe, żadne wywołanie sessionID nie trafi na ten sam serwer. (Prawdopodobnie dlatego, że pierwsze złe połączenie bez identyfikatora sesji powoduje, że aplikacja tworzy nową sesję, która przesłania obiekt oryginalnej sesji) Więc nawet przy drugim wywołaniu, w którym właściwy sessionID przechodzi do aplikacji, odkryjemy, że obiekt sesji zawiera zero .

Sądzę, że istnieje problem z duplikatem wywołania, który usuwa obiekt sesji, który nie jest pewny, dlaczego tak się dzieje.

Ktoś ma o tym pojęcia? Dzięki

Aktualizacja: Planujemy podjęcie tych kroków w celu rozwiązania tego problemu.

1. Mamy problemy w obszarach, w których zostały wykonane połączenia asynchroniczny Ajax, więc planujemy usunąć funkcję Async i niech Ajax uruchomić synchronizację.
2. Mamy problemy z przeprowadzaniem przekierowania javascript Windows.location. Stworzyliśmy alternatywną metodę wykorzystującą odświeżenie strony w nadziei na naprawienie problemu w tym obszarze.
3. Inne obszary, które nie są powiązane z jedną z powyższych kwestii, nadal są w powietrzu.

Efekt zmiany zostanie opublikowany po wdrożeniu do produkcji.

Dzięki za wszystkie komentarze.

Answer 1

Po miesiącach poszukiwań i debugowania, myślę, że w końcu doszliśmy do wniosku. Wygląda na to, że wystąpił błąd w limicie czasu sesji Sitecore Analytics dla robotów. Na początku zauważamy, że w każdym przypadku, gdy utracona sesja losowa była spowodowana przedterminowym przekroczeniem limitu czasu sesji, zauważymy, że sesja ta została ustawiona na 1min timeout zamiast 120min.

Po przeszukiwaniu wszystkich plików konfiguracyjnych zauważamy, że Sitecore Analytic.Robots.SessionTimeout było jedyną wartością limitu czasu ustawioną na 1min.

Zwiększenie tej wartości rozwiązało problem z przekroczeniem limitu czasu sesji.

Podstawowym problemem jest to, że Sitecore Analytics błędnie identyfikuje sesję odwiedzającego jako sesję robota i przypisuje czas oczekiwania do 1 minuty. Prawdopodobnie jest to błąd do zgłoszenia.

Aktualizacja: Response z Sitecore:

Sitecore CMS został zaprojektowany do użytku z technologii ASP.NET WebForms. Podczas korzystania z formularzy internetowych wykrywanie bota opiera się na kontroli na stronie. To naturalne, że nie można go używać w aplikacji ASP.NET MVC, ale istnieje proste rozwiązanie - umieść następujący kod w elemencie:

<% 
if (Context.Diagnostics.Tracing || Context.Diagnostics.Profiling) 
{ 
    Response.Write("<!-- Visitor identification is disabled because debugging is active. -->"); 
} 
else if (Tracker.IsActive && (Tracker.Visitor.VisitorClassification == 925)) 
{ 
    Response.Write("<link href=\"/layouts/System/VisitorIdentification.aspx\" rel=\"stylesheet\" type=\"text/css\" />"); 
} 
%> 

Answer 2

Myślę, że Twoim problemem mogą być wywołania Async ajax, o których mówisz. Przeczytałem niedawno artykuł Davida Haydena, który mówił o problemach ze współbieżnymi żądaniami ajaxów w tej samej sesji, powodując problemy. To jest coś, na co trzeba patrzeć. Mam nadzieję, że to pomaga.

http://davidhayden.com/blog/dave/archive/2011/02/09/SessionLessControllersMvc3.aspx

Mówi o nim w prawo na końcu postu.