ហេតុអ្វីបានជាការបរាជ័យរបស់ប្រូកស៊ី SockJS អាចលេចឡើងតែបន្ទាប់ពីការត្រឡប់

នៅពេល WebSocket ដំណើរការលើបណ្តាញមួយ ប៉ុន្តែ SockJS បរាជ័យលើបណ្តាញមួយទៀត បណ្តាញទីពីរអាចបានបើកការត្រឡប់ XHR។ នេះអាចផ្លាស់ប្តូរការអនុវត្ត HTTP ដែលធ្វើសំណើ — ហើយដូច្នេះការកំណត់ប្រូកស៊ីដែលប្រើ។

រកឃើញ URL ដែលបរាជ័យដំបូង និងការដឹកជញ្ជូនដែលវាបានជ្រើស។ SockJS អាចធ្វើសំណើព័ត៌មាន HTTP មុនពេលជ្រើសការដឹកជញ្ជូន។ ការចាប់ដៃ WebSocket និងសំណើស្ទង់មតិបន្ទាប់គឺជាប្រតិបត្តិការដាច់ដោយឡែក។ ការកំណត់ការចាប់ដៃដែលដំណើរការមិនបញ្ជាក់ផ្លូវដែលប្រើសម្រាប់ពួកវានីមួយៗទេ។

នៅក្នុងអតិថិជន Java របស់ Spring RestTemplateXhrTransport ទទួលយក RestTemplate ដែលបានកំណត់។ រោងចក្រសំណើ និងអតិថិជន HTTP មូលដ្ឋានរបស់វា ផ្តល់ផ្លូវប្រូកស៊ី និងការផ្ទៀងផ្ទាត់ដែលគាំទ្រដោយការត្រឡប់។ សម្រាប់ Spring 6 ជាមួយ HttpClient 5 កំណត់រោងចក្រសំណើពិតប្រាកដរបស់ RestTemplate នោះ។ ប្រសិនបើការអនុវត្តនោះប្រើសមាសធាតុ Apache HTTP ជំនាន់របស់វាត្រូវតែត្រូវគ្នានឹងការរួមបញ្ចូល។

អតិថិជន WebSocket មានការកំណត់ការតភ្ជាប់ដែលបានចងក្រងដោយខ្លួនឯង។ លក្ខណៈសម្បត្តិប្រូកស៊ី JVM ប៉ះពាល់ផ្លូវតែនៅពេលអតិថិជនជាក់លាក់របស់វាអានពួកវា។ ប្រៀបធៀបបរិស្ថានដែលដំណើរការ និងបរាជ័យ តាមការដឹកជញ្ជូន ការអនុវត្តអតិថិជន ប្រូកស៊ីដែលបានជ្រើស និងកំហុសដំបូង។ ប្រសិនបើមានតែ XHR បរាជ័យ សូមដើរតាមផ្លូវ ការផ្ទៀងផ្ទាត់ និងការឆ្លើយតបរយៈពេលយូររបស់វា ជំនួសឱ្យការផ្លាស់ប្តូរការកំណត់អតិថិជន WebSocket ដែលដំណើរការម្តងហើយម្តងទៀត។