Miks SockJS-i puhverserveri tõrge võib ilmneda alles varuplaanile lülitumise järel
WebSocketi tee ja XHR-i varuplaan võivad kasutada erinevaid HTTP-kliente. Enne puhverserveri seadete muutmist tehke kindlaks, milline transport ebaõnnestub.
Kui WebSocket töötab ühes võrgus, aga SockJS ebaõnnestub teises, võis teine võrk käivitada XHR-i varuplaani. See võib muuta HTTP-teostust, mis päringuid teeb — ja seega ka kasutatavat puhverserveri konfiguratsiooni.
Leidke esimene ebaõnnestunud URL ja selle valitud transport. SockJS võib enne transpordi valimist teha HTTP-teabepäringu; WebSocketi käepigistus ja järgnevad küsitluspäringud on eraldi toimingud. Töötav käepigistuse konfiguratsioon ei tõesta igaühe jaoks kasutatavat teed.
Springi Java-kliendis võtab RestTemplateXhrTransport vastu konfigureeritud RestTemplate'i. Selle päringutehas ja aluseks olev HTTP-klient pakuvad varuplaanile toetatud puhverserveri marsruudi ja autentimise. Spring 6 ja HttpClient 5 puhul konfigureerige selle RestTemplate'i tegelik päringutehas. Kui see teostus kasutab Apache HTTP komponente, peab selle põlvkond integreerimisega sobima.
WebSocketi kliendil on oma dokumenteeritud ühendusseaded. JVM-i puhverserveri omadused mõjutavad teed ainult siis, kui selle konkreetne klient neid loeb. Võrrelge töötavat ja ebaõnnestuvat keskkonda transpordi, kliendi teostuse, valitud puhverserveri ja esimese vea järgi. Kui ebaõnnestub ainult XHR, järgige selle marsruuti, autentimist ja pikaajalisi vastuseid, selle asemel et korduvalt muuta töötava WebSocketi kliendi seadeid.