FlowLimit jest zaimplementowany w taki sposób, że po jego przekroczeniu wyłączany jest starter (onStop) aż do momentu, kiedy zwolnią się wszystkie wątki obsługujące proces startera. Jeśli FlowLimit wynosi 20 a podłączonych jest 30 klientów, którzy ciągle wywołują jednowątkowo usługę SOAP over HTTP, to 10 klientów będzie obserwowało długi czas połączenia, odmowę połączenia (connection refused) lub błąd HTTP 503 Service Unavailable. Czekanie na zwolnienie wszystkich wątków wykonawczych jak i różne zachowania przy odrzucaniu żądania (w dodatku bez jakiegokolwiek śladu w logach BW!) budzą zastrzeżenia. Proces obsługi żądania powinien sprawdzać stan nasycenia puli wykonawczej i jeśli nie jest ona pełna pozwalać na stworzenie eventu BW i w rezultacie wykonanie procesu. Jeśli kolejka oczekujących żądań jest zbyt długa i nie maleje, to wykraczający poza limit komunikat powinien być szybko odrzucany. Oryginalna implementacja Tibco tak ładnie się nie zachowuje, wyraźnie widoczna jest czkawka. Całe szczęście własny Java Event Starter pozwala na stworzenie własnych bardziej deterministycznych lekkich usług, w których dbamy o opóźnienia, przepustowość i niezawodność.
0 komentarze:
Prześlij komentarz