Korelacja IComMethodEvents

Question

Podczas wdrażania IComMethodEvents otrzymujesz trzy zdarzenia.

1. OnMethodCall
2. OnMethodException
3. OnMethodReturn

Celem co próbuję zrobić, to zalogować razy połączeń za metody COM + komponentów.

Czas zdarzenia mogą być pobierane za pomocą lTime i lMicroTime w strukturze COMSVCSEVENTINFO więc po zalogowaniu się, że czas w obu OnMethodCall aw OnMethodReturn powinienem być w stanie obliczyć czas połączenia, ale jak mogę być pewien, że dwa wydarzenia są powiązane.

Podczas testowania wygląda na to, że powinienem móc użyć obiektu aktywowanego just-in-time (JIT) oid.

Jakiekolwiek problemy z robieniem tego w ten sposób lub czy istnieją inne sposoby?

Jednym z problemów, które mogą być, jest to, że widzę, że oid jest często ponownie wykorzystywany, więc jeśli zdarzenia z jakiegoś powodu zostaną wyrzucone z rzędu, może być nieco trudniej wprowadzić korelację.

Aktualizacja 1:

Dalsze badania pokazują, że nie jest wystarczająco oid w multi scenariusza użytkownika. Ten sam obiekt jest używany w tym samym czasie, więc korelacja musi być wykonana przy użyciu co najmniej oid i original caller. Następne pytanie brzmi: Jak uzyskać oryginalnego dzwoniącego od subskrybenta zdarzenia COM +?

Aktualizacja 2:

Wystarczy znaleźć IComMethod2Events. Różnica polega na tym, że zdarzenia mają identyfikator wątku wykonującego połączenie. Wygląda obiecująco w testach i nie mogę sobie wyobrazić scenariusza, w którym korelacja mogłaby się nie udać. Model gwintowania dla komponentów COM + to Any Apartment.

Aktualizacja 3

W tym artykule Creating COM+ PerfMon Counters to Monitor COM+ Dataoid służy. Nie sądzę, żeby to wystarczyło w wielowątkowym mieszkaniu.

_{Uwaga: W końcu zaimplementuję to w Delphi, więc dodałem tag Delphi. Dodałem również znacznik C#, ponieważ jest prawdopodobne, że język używany do implementacji interfejsu nie jest w ogóle ważny. Aktualizacja: Wstępne dodawanie tagu C++ tylko po to, aby zwrócić uwagę kogoś, kto już wcześniej używał tych rzeczy.}

Answer 1

... jeśli wydarzenia z jakiegoś powodu są wystrzeliwane z rzędu ...

nigdy nie robią. Wydawca zdarzeń systemu COM + uruchamia te zdarzenia za pomocą usługi COM + Events. Inwokacja zdarzenia jest synchroniczna z punktu widzenia wydawcy wydarzenia. Gdy wydawca uruchamia zdarzenie, nie przechodzi do następnego, dopóki wszyscy subskrybenci nie zakończą przetwarzania wypalonego zdarzenia. Naturalnie zdarzenia OnMethodReturn/OnMethodException nie są publikowane przed dopasowaniem OnMethodCall. Pamiętam, że czytałem KB dotyczące warunków wyścigu/uszkodzonych subskrypcji w wydarzeniach COM +. Wszystkie te błędy, według mojej wiedzy, zostały zaadresowane w różnych pakietach Service Pack dla Windows 2000. Chociaż, rzecz jasna, nie staram się być na bieżąco w tej dziedzinie.

Podczas realizacji IComMethod2Events subskrybujesz tę samą subskrypcję tymczasową, co w przypadku IComMethodEvents. Kolejność strzelania jest taka sama.

... więc korelacja musi być wykonane przy użyciu co najmniej oid i original caller ...

W tym momencie ja naprawdę nie wiem, czy robisz interpretować wyniki swoich badań poprawnie. Jak dokładnie testujesz?

oid powinien już zawierać wszystkie wymagane informacje, nawet w scenariuszu "wielu klientów" z JIT i łączeniem. Ostatnim razem zaimplementowałem taki detektor zdarzeń (już dawno temu), polegając na oid wypracowanym dobrze. Chociaż większość komponentów w moim środowisku została napisana w VB6 (stąd mieszka w STA). Jednak nawet przy STA możesz mieć kilka połączeń na różnych etapach wykonania przez pojedynczy wątek. Ponieważ istnieje górna granica liczby wątków w puli wątków COM + STA, możesz mieć następującą sytuację: wywołanie A rozpoczyna się na określonym wątku, wywołanie B rozpoczyna się w tym samym wątku, wywołanie B zwraca, wywołanie A zwraca. Nie pamiętam żadnych problemów z śledzeniem wywołań przez oid bez "dodatkowych informacji o dzwoniącym".

Wdrożony przez ciebie pomysł implementacji jest w dużej mierze kanoniczny. COM+ spy Próbka dołączona do zestawu SDK platformy używa argumentu oid do śledzenia pojedynczych wywołań. Źródła aplikacji można znaleźć pod adresem <Path to SDK samples>\Samples\com\administration\spy. Próbka korzysta z tej implementacji przez dłuższy czas (przynajmniej od Windows 2003). A dzisiaj jest eon po MTA, a nawet wprowadzenie COM +. W przypadku wad, próbka zostanie zaktualizowana w tym momencie. Ufnie.

Answer 2

MSDN Link "Creating COM+ PerfMon Counters to Monitor COM+ Data" wydaje się zrobić bardzo dużo, czego dążą do (chociaż w zarządzanym C++ myślę).

Właściwa część jest to, myślę:

void IComMethodEvents.OnMethodCall(ref COMSVCSEVENTINFO ei, ulong 
    lObjID, ref Guid gClsID, ref Guid gIID, uint nIndex) 
{ 
    //Make sure that monitoring is enabled and that our performance 
    //counter has been initialized. 
    if (Monitor && pcMethodDuration != null) 
    { 
    try 
    {      
     //We are going to store the initial value in a Sorted List 
     //collection. To do this we are going to need a key that 
     //represents this call. 
     string strKey = lObjID.ToString() + gClsID.ToString() + 
      gIID.ToString() + nIndex.ToString(); 

To może być rozwiązanie do rozpatrzone o OID (lObjID w swoim przykładzie). Nie wiem, czy to dotyczy scenariusza dla wielu użytkowników, musisz spróbować. Strona zawiera sporo szczegółów na ten temat, więc miejmy nadzieję, że będziecie w stanie to rozgryźć. Powodzenia.