2016-02-16 20 views
10

Ustawiłem program RabbitMQ w celu przeanalizowania około 20 000 żądań z zewnętrznego interfejsu API, ale po upływie kilku minut utrzymuje on limit czasu. Pozwala poprawnie przeanalizować około 2000 z łącznej liczby 20 000 zapytań.Limit czasu błędu RabbitMQ

Plik dziennika mówi:

=INFO REPORT==== 16-Feb-2016::17:02:50 === 
accepting AMQP connection <0.1648.0> (127.0.0.1:33091 -> 127.0.0.1:5672) 

=ERROR REPORT==== 16-Feb-2016::17:03:21 === 
closing AMQP connection <0.1648.0> (127.0.0.1:33091 -> 127.0.0.1:5672): 
{writer,send_failed,{error,timeout}} 

Już zwiększyła wartość pulsu, ale nie mogę zrozumieć, dlaczego to jest limit czasu. Konfiguracja: Ubuntu 14.04, NGINX 1.8.1, RabbitMQ 3.6.0

Byłbym wdzięczny za poświęcony czas i uwagę!

+0

Brakuje niektórych szczegółów tutaj: Co robi "parsowanie"? Skąd pochodzi ta wiadomość dziennika? Czy zdarza się limit czasu podczas publikowania wiadomości * na * RabbitMQ lub podczas ich konsumowania * od * it? Twoje tagi wspominają o PHP, więc czy istnieje jakiś odpowiedni kod PHP, który możesz nam pokazać? – IMSoP

+0

Dziękujemy za odpowiedź! Rzeczywiście, konsument napisany w PHP analizuje niektóre dane JSON z zewnętrznego API. Komunikaty dziennika zostały pobrane z głównego pliku dziennika RabbitMQ: /var/log/rabbitmq/[email protected] Nie powiedziałbym, że kod PHP jest istotny dla błędu, ale zapisuje krótkie wyjście do pliku .txt. – user927901

+0

Może warto opublikować (lub utworzyć [mcve]) swojego kodu PHP, na wypadek, gdyby coś, co robisz, mogło spowodować przekroczenie limitu czasu. W tej chwili nie mamy wiele do roboty poza "gdzieś jest błąd limitu czasu". Podobnie, jakikolwiek kod związany ze sposobem publikowania komunikatów (przypuszczalnie jest coś, co zbiera elementy z API i jakoś je umieszcza w Rabbit?) – IMSoP

Odpowiedz

18

Właśnie rozwiązałem podobny problem w Pythonie. W moim przypadku został rozwiązany przez zmniejszenie liczby preselekcji na konsumenta, tak aby miał mniej wiadomości w kolejce w swoim buforze odbiorczym.

Moja teoria mówi, że bufor odbiorczy na kliencie jest pełny, a następnie RMQ próbuje napisać inny komunikat do gniazda konsumenta i nie może to być spowodowane pełnym gniazdem konsumenta. RMQ blokuje na tym gnieździe, a ostatecznie limity czasu i po prostu zamyka połączenie z konsumentem. Posiadanie mniejszej kolejki do wstępnego pobierania oznacza, że ​​bufor odbiorczy gniazda nie jest zapełniany, a RMQ jest w stanie zapisać wszystkie wiadomości księgowe, które próbowały wykonać, a więc nie kończy czasu na zapisach, ani nie zamyka połączenia.

To tylko jedna z teorii, ale wydaje się, że trzymam ją w testach.

+0

Brzmi logicznie. Sprawdzę to na pewno, dziękuję! – user927901

+0

subChannel.basicQos (10); Zmniejszenie liczby preselekcji konsumenta eliminuje tę liczbę –

9

Dodaj więcej do odpowiedzi @ tul.

subChannel.basicQos(10); 

Zmniejszanie liczby preselekcji konsumenta eliminuje wyjątek dotyczący limitu czasu.
Domyślna liczba preselekcji jest nieograniczona.

+0

Dzięki za udostępnienie fragmentu kodu zaoszczędziło mi to dzisiaj –