Pracuję z JMS i kolejkami (kolejki Azure) po raz pierwszy. Muszę utworzyć kolejkę, w której serwer Rubi zapisałby niektóre dane, a Java odczytałaby je z kolejki i wykonałaby dalsze operacje. Ten proces działa poprawnie lokalnie na moim komputerze. Utworzyłem punkt końcowy REST, który zapisuje dane w kolejce, a gdy dane zostaną zapisane w kolejce, odbiornik przejmie dane i odczyta je i wykona. Po wdrożeniu go na platformie Azure pojawia się błąd w dziennikach, który uniemożliwia uruchomienie kolejek
Setup of JMS message listener invoker failed for destination 'queue' - trying to recover. Cause: Identifier contains invalid JMS identifier character '-': 'x-request-id'
Zipkin jest również obecny na serwerze Azure jako rozproszony system śledzenia i myślę, że x-request-id
jest to związane z Zipkinem, który tworzy problem. Szukałem problemu w Google, ale nie mogłem zrozumieć, dlaczego tak się dzieje.
Poniżej znajduje się szczegółowy komunikat o błędzie:
[36mc.m.s.l.NextGenRequestLoggingFilter [0;39m [2m:[0;39m
Before request [uri=/services/deal-service/api/v2/deals/ack;headers=
[x-request-id:"2d8d86d7-4fbf-9db6-8e95-28813f21a85c",
x-envoy-internal:"true", x-b3-parentspanid:"a209cdc649b0b890", content-
length:"575", x-forwarded-proto:"http", postman-token:"ad074595-
76a5-474b-9711-7e071b12b3b0", x-b3-sampled:"1", x-forwarded-
for:"10.244.2.1", accept:"*/*",
authorization: "some-token-YJc4tg--34jPRziJNSACqNQ", x-b3-
traceid:"6b40ff22781be67ba209cdc649b0b890", x-b3-
spanid:"702684ddb62cfe6b",
host:"portal-gateway.52.228.65.225.nip.io",
cache-control:"no-cache", accept-encoding:"gzip, deflate, br",
user-agent:"PostmanRuntime/7.22.0",
Content-Type:"application/xml;charset=UTF-8"]]
2020-02-18T15:19:34.197666458Z [2m2020-02-18 15:19:34.197[0;39m .
[32mDEBUG
[,6b40ff22781be67ba209cdc649b0b890,702684ddb62cfe6b,true][0;39m .
[35m9[0;39m [2m---[0;39m [2m[ XNIO-1 task-15][0;39m
Odpowiedzi:
Z komunikatu o błędzie wynika, że używasz klienta Qpid JMS do komunikacji przez kolejki. Klient qpid nie zezwala na żadne klucze, które naruszają konwencję nazewnictwa zmiennych java, np. nie będziesz mógł wysłać x-request-id w nagłówku kolejki, który klient qpid jms zużywa, ponieważ spowoduje to błąd. Musisz zadbać o istio / zipkin, aby nie dodawać niektórych nagłówków (jeśli nie potrzebujesz ich tak naprawdę) do kolejki podczas próby komunikacji w lazurowej magistrali. Musisz więc wyłączyć biblioteki istio / zipkin, aby przechwycić żądanie kolejki, aby żądanie do / z kolejki mogło być wykonane bez nagłówków. To rozwiąże problem.
źródło
Sekcja 3.5.1 specyfikacji JMS 2 mówi o właściwościach komunikatu:
W odniesieniu do identyfikatorów sekcja 3.8.1.1 stanowi częściowo:
Jeśli przekażesz znak
-
do któregokolwiek z nichCharacter.isJavaIdentifierStart
lubCharacter.isJavaIdentifierPart
zwrócona wartość tofalse
. Innymi słowy, znaków w nazwie właściwości wiadomości jest niezgodny ze specyfikacją JMS , a tym samym spowoduje błąd.-
źródło
Bardzo przydatne byłyby tutaj szczegóły błędu (śledzenie stosu Java).
Zakładam, że komunikat o błędzie używa qpid klienta JMS , który wykonuje sprawdzenie nazw właściwości komunikatu. Nazwy te mogą zawierać tylko znaki, które są poprawnymi znakami identyfikacyjnymi Java .
W ciągu „nazwa kolejki” znajduje się znak „-”, który nie jest identyfikatorem Java. Aby to naprawić, musisz zmienić „nazwa kolejki” na coś z prawidłowymi znakami, na przykład „nazwa kolejki” (z podkreśleniem) lub „nazwa kolejki” (wielkość liter).
źródło