C#, Webservice, XL API, Access Violation

[yakhub]

Mam aplikację, która udostępnia webservice WCF.

Webservice udostępnia metody do tworzenia i edytowania dokumentami XLa przez API.

Wszystko było stabilne jak skała, i potrafiło działać miesiącami bez ingerencji, aż do upgradu XLa do wersji 2016.

Na początku aplikacja wysypywała się od razu - dopisałem:

Kod: Zaznacz cały

        [DllImport("ClaRUN.dll")]
        public static extern void AttachThreadToClarion(int x);

A potem: AttachThreadToClarion(1); przed każdym wywołaniem funkcji API. Zdawało mi się, że pomogło. Miałem rację - zdawało mi się.

Teraz aplikacja działa przez kilkanaście godzin, w międzyczasie wystawiane są dokumenty, wszystko działa - aż nagle, zupełnie bez powodu, wszystko wylatuje w powietrze (zazwyczaj w środku nocy, gdy na magazynie pracuje 3 zmiana):
https://www.dropbox.com/s/x2zidq54lk18u ... 1.jpg?dl=0


Błąd występuje w zupełnie losowych momentach. Nie jest przechwytywany przez bloki try/catch. Już zupełnie nie wiem, co z tym zrobić.

Ktoś ma jakieś pomysły, co jeszcze można z tym zrobić?

[rafalW]

Przejrzyj stare tematy, juz pisalem parokrotnie, api jest jednowatkowe, webserwis nie. Wywolywanie AttachThreadToClarion w kazdej metodzie nic nie da bo liczy sie watek w ktorym zrobiles logowanie
Musisz przerobic aplikacje, napisac serwis windowsowy, w jednym watku obsluga api, w drugim komunikacja z webserwisem, miedzy nimi kolejka fifo.

[yakhub]

Taka informacja, dla osób, które będą się w przyszłości zmagać z problemem: To nie jest tak wprost, że API jest jednowątkowe.

Kolejne wywołania funkcji API mogą pochodzić z różnych wątków, i będzie to działać. Warunek jednak jest taki, że przez cały czas musi być aktywny wątek, w którym miało miejsce logowanie.

Stąd też wynika pozornie nieprzewidywalne zachowanie webservice'ów - podczas kolejnych wywołań metod mogą (choć nie muszą) być tworzone nowe wątki, a stare mogą (choć nie muszą) być zwalniane, lub używane ponownie. Na mechanizm, który tym zarządza mamy niewielki wpływ, a działa on niedeterministycznie. To, jak to będzie działać, zależy od tego, kiedy zostanie zwolniony wątek, w którym nastąpiło logowanie. Praktycznie nie sposób przewidzieć, kiedy to nastąpi, ale - jeżeli logowanie nastąpiło w wyniku requestu - mamy praktycznie pewność, że prędzej, czy później nastąpi.

[elmiq]

Czyli, dla uproszczenia, jest jednowątkowe, bo musisz się trzymać wątku w którym poszło logowanie. Najprościej to porównać do uruchomionego modułu XL. Jeśli masz włączoną sprzedaż (w danej bazie), to wywołasz sobie różne listy/okna, nawet wielokrotnie (powiedzmy metody), ale samej sprzedaży dla tej bazy drugi raz nie włączysz (czyli wątku logowania). Dlatego też chyba najprościej i najbardziej Comarcho-odpornie skorzystać z rady Rafała.

Pozdrawiam,
Mateusz

[rafalW]

To nie jest tak wprost, że API jest jednowątkowe.

Klocic sie nie chce, tym bardziej ze na dowod mam tylko wlasne obserwacje, faktem jest jednak ze jak robilem testy wielowatkowe (utworz dokument, dodaj kilka towarow, zamknij dokument), to np 100 watkow puszczone na zywiol zawsze konczylo sie spektakularnym wybuchem. Dopiero po dolozeniu semafora zaczynalo dzialac tak jak powinno
Sam tez przyznales ze kolejne wywolania AttachThreadToClarion nic nie daja, dla mnie to kolejny dowod ze api ma jeden watek na klienta i oczekuje ze klient tez bedzie jednowatkowy. A to ze pozwala na wywolania z innych watkow dopoki watek logowania zyje? W sumie cholera wie jak ten caly Clarion dziala, mozemy gdybac do rana

Mateusz juz napisal, ja powtorze. Zrobienie obslugi api w jednym watku jest Comarcho-odporne i na dluzsza mete zwyczajnie sie oplaca. We wczesniejszych wersjach webserwisu jeszcze dla XLa ze starym interfejsem, obsluge api mialem w webserwisie. Kazde wywolanie to nowa sesja, nowy watek. I dzialalo, ale nie w 100% skutecznie. Raz na jakis czas w logach pojawialy sie przypadkowe bledy, nigdy powtarzalne. Niby nic, klient dostawal blad, probowal jeszcze raz i nie bylo sprawy. Ale niesmak pozostal...
Po przerzuceniu api do serwisu windowsowego jak reka odjal, logi czysciutkie, hula normalnie jak nie Comarch

[aczapnik]

Szukając więcej informacji o AttachThreadToClarion znalazłem transmisję z Clarion Live Open Webinar http://www.clarionlivemedia.com/webinar ... -11-11.wmv
W trakcie pojawia się temat API i pokazany jest fragment dokumentacji - dołączam zrzut ekranu - może komuś się przyda kilka zdań więcej na temat funkcji AttachThreadToClarion()

[PlacekJ]

To nie jest tak wprost, że API jest jednowątkowe.

Po przerzuceniu api do serwisu windowsowego jak reka odjal, logi czysciutkie, hula normalnie jak nie Comarch

Odgrzebuję bo właśnie z tym walczę.
Próbowałem uruchomić web api na Self-Host uruchomionej jako Win Service z logowaniem w klasie serwisu ale jakoś bez rezultatów.

Mam pytanka.
Jak technicznie realizujesz te kolejkę FIFO z web api do win service?
Potrzebuję aby web api ostatecznie zwracało do klienta numer utworzonego dokumentu w XL lub opis błędu. W twoim rozwiązaniu z win service da się to zrobić?
Twój win service loguje się do XL-a przy uruchomieniu i trzyma sesję czy logowanie jest dla każdego elementu z FIFO?

Pozdrawiam.

[john_doe]

rafalW daj info jak to jest infrastrukturalnie u Ciebie.

Czy my tutaj nie mówimy o:
1. Servis Windowsowy pracujący tylko z XL, sprawdzający co chwilę czy coś jest do roboty wg jakiejś daty? Jeśli tak to robi = loguje się. dodaje dokument, modyfikuje, etc...
2. Jakiś REST`ik obsługujący calle http, zapis do db, do koleki tego co w pkt 1

?

[havoc]

Ad 1. Tak tez robię podobnie u siebie. Kolejkuję w bazie danych i odczytuje albo z win service albo z aplikacji wywołanej z harmonogramu zadań. Działa bez problemów. Minusem jest opóźnienie w wykonaniu zadania (service czy aplikacja odpytuje co jakiś czas bazę po prostu). W przyszłości spróbuję przetestować jakiegoś Rabbita czy Kafkę.
Ad 2. Nie udało mi się zbyt skutecznie odpalić się jednowątkowo w ASP.NET MVC i ASP.NET Web API (co wcale nie znaczy ze nie jest to możliwe). Zapytania 'RESTowe' do XL API obsługuję ciągle w ASP.NET Web Forms (AspCompat="true").

[rafalW]

Czesc
Przepraszam ze tak po roku, nie zagladam tu zbyt czesto

Jak technicznie realizujesz te kolejkę FIFO z web api do win service?

1. Servis Windowsowy pracujący tylko z XL, sprawdzający co chwilę czy coś jest do roboty wg jakiejś daty? Jeśli tak to robi = loguje się. dodaje dokument, modyfikuje, etc...
2. Jakiś REST`ik obsługujący calle http, zapis do db, do koleki tego co w pkt 1 ?

Mniej wiecej tak jak piszesz, z tym ze bez udzialu bazy. Komunikacja miedzy web a win serwisem opiera sie u mnie na socketach tcp/ip. Winserwis jest serwerem, a webserwis klientem. Webserwis SOAP na IIS (pisalem to ladnych kilka lat temu, REST nie byl wtedy jeszcze popularny). Po wywolaniu metody w websvc tworze komunikat z unikalnym id i wysylam go do winsvc. Serwer tcp jest wielowatkowy, wiec po odebraniu komunikatu w winsvc umieszczam go w kolejce (System.Collections.Queue)
W watku api sprawdzam cyklicznie kolejke, jesli cos jest to wykonuje odpowiednia akcje api, a nastepnie tworze komunikat zwrotny ktory trafia do websvc

Twój win service loguje się do XL-a przy uruchomieniu i trzyma sesję czy logowanie jest dla każdego elementu z FIFO?

Loguje sie raz i trzyma sesje aby uniknac sytuacji ze zabraknie licencji