Lorawan-stack: ईवेंट स्ट्रीम ब्लॉकिंग कंसोल जब प्रारंभ ईवेंट नहीं भेजे गए

फ़ायरफ़ॉक्स कंसोल पर हमेशा के लिए लोड हो रहा है यदि 6 खुले टैब हैं - उदाहरण के लिए काम करने वाले टैब में से एक रीफ्रेश किया गया है - लोडिंग टैब में से एक अनब्लॉक हो जाता है, लेकिन ऐसा लगता है कि कभी-कभी विफल हो जाता है।

किसी भी मामले में, मैंने प्रारंभ/समाप्ति संदेश भेजने का प्रयास किया, लेकिन इससे कुछ भी नहीं बदला - 6 टैब होने के बाद भी यह लटका हुआ है।

नोट: सभी टैब गेटवे के डेटा दृश्य पर हैं (2 अलग-अलग)

@kschiffer कोई विचार?

फ़ायरफ़ॉक्स कंसोल पर हमेशा के लिए लोड हो रहा है यदि 6 खुले टैब हैं - उदाहरण के लिए काम करने वाले टैब में से एक रीफ्रेश किया गया है - लोडिंग टैब में से एक अनब्लॉक हो जाता है, लेकिन ऐसा लगता है कि कभी-कभी विफल हो जाता है।

यह अपेक्षित है और HTTP/2 का उपयोग नहीं करते समय एक सीमा unsing ईवेंट स्ट्रीम करता है :

जब HTTP / 2 पर उपयोग नहीं किया जाता है , तो SSE खुले कनेक्शन की अधिकतम संख्या तक सीमित हो जाता है, जो कि विभिन्न टैब खोलते समय विशेष रूप से दर्दनाक हो सकता है क्योंकि सीमा _प्रति ब्राउज़र_ है और बहुत कम संख्या (6) पर सेट है। समस्या को क्रोम और फ़ायरफ़ॉक्स में "ठीक नहीं होगा" के रूप में चिह्नित किया गया है। यह सीमा प्रति ब्राउज़र + डोमेन है, इसका मतलब है कि आप www.example1.com में सभी टैब में 6 SSE कनेक्शन खोल सकते हैं और अन्य 6 SSE कनेक्शन www.example2.com. ( Stackoverflow से ) में खोल सकते हैं। HTTP / 2 का उपयोग करते समय, सर्वर और क्लाइंट के बीच एक साथ _HTTP स्ट्रीम_ की अधिकतम संख्या पर बातचीत की जाती है (डिफ़ॉल्ट रूप से 100)।

मुझे मूल समस्या को पुन: प्रस्तुत करने में समस्या है क्योंकि मेरे पास स्टेजिंग वातावरण पर केवल दो कनेक्टेड गेटवे तक पहुंच है।

मुझे संदेह है कि यह इस तथ्य के कारण होता है कि शीर्षलेख केवल स्ट्रीम पर पहले संदेश से ठीक पहले लिखे जाते हैं। यदि कोई संदेश नहीं है, तो कोई हेडर नहीं है और ब्राउज़र प्रतीक्षा करता रहता है।

मैं इसकी पुष्टि कर सकता हूं। यदि उन्हें प्रतिक्रिया शीर्षलेख नहीं मिलता है तो अनुरोध रुक जाएंगे। ऐसे छह कनेक्शन खुले होने के बाद, बाद के सभी एक्सएचआर भी ठप हो जाएंगे।

#2565 से पहले यह कोई समस्या नहीं थी क्योंकि इवेंट स्ट्रीम हमेशा "स्टार्ट स्ट्रीम संदेश" तुरंत भेजती थी, जिसके परिणामस्वरूप हेडर भेजे जाते थे।

ऐसे में, मैं इसे फ्रंटएंड मुद्दे के रूप में नहीं देखता। केवल एक चीज जो फ्रंटएंड पर बदलने के लिए समझ में आती है वह यह सुनिश्चित कर रही है कि एक निश्चित समय के बाद रुके हुए स्ट्रीम कनेक्शन मारे गए हैं।

तो समस्या तब होती है जब ईवेंट स्ट्रीम कोई डेटा नहीं भेजती हैं। इवेंट स्ट्रीम कनेक्शन करने वाला XHR केवल पहला संदेश प्राप्त होने के बाद ही हल होगा, अन्यथा, यह pending स्थिति में लटका रहेगा। एक बार उन कनेक्शनों में से 6 खोले जाने के बाद अन्य सभी कनेक्शन भी लटक जाएंगे, क्योंकि समवर्ती टीसीपी कनेक्शन की अधिकतम मात्रा तक पहुंच गई है। तो ऐसा प्रतीत होता है कि एक्सएचआर सर्वर से किसी प्रकार की पावती की अपेक्षा करता है कि धारा स्थापित हो गई है।

#2565 से पहले यह कोई समस्या नहीं थी क्योंकि इवेंट स्ट्रीम हमेशा "स्टार्ट स्ट्रीम संदेश" भेजेगी।

मैं वर्तमान में यह पता लगाने की कोशिश कर रहा हूं कि यह फ्रंटएंड पर कैसे और कैसे तय किया जा सकता है।

मेरे अनुभव में "प्रारंभिक संदेश" भेजने से इस मुद्दे में मदद नहीं मिलती है। कृपया निम्नलिखित अंतर के साथ स्वयं को आजमाएं:

diff --git a/pkg/events/grpc/grpc.go b/pkg/events/grpc/grpc.go
index 03f229ca0..5a305b5ac 100644
--- a/pkg/events/grpc/grpc.go
+++ b/pkg/events/grpc/grpc.go
@@ -119,6 +119,10 @@ func (srv *EventsServer) Stream(req *ttnpb.StreamEventsRequest, stream ttnpb.Eve
    if err := stream.SendHeader(metadata.MD{}); err != nil {
        return err
    }
+   if err := stream.Send(&ttnpb.Event{}); err != nil {
+       return err
+   }
+   defer stream.Send(&ttnpb.Event{})

    for {
        select {

यहाँ एक वीडियो है:
https://youtu.be/0Ir0lakV-Mc

मुझे फर्क नजर आता है।

अंतर के बिना master :

htdvisser % curl -v 'http://localhost:1885/api/v3/events' --compressed -H 'Authorization: Bearer MFRWG.DVTINRZNJDORITWD64NUJRIYVIXWCKJ3Q6VYLQY.E4K63GZ3WWTZGCIFMD7XLN7A7ACA35YCQSMFCBVCTEOMATCYGG6Q' -H 'Accept: text/event-stream' -H 'Content-Type: application/json' --data-raw '{"identifiers":[{"application_ids":{"application_id":"admin-app"}}]}'
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 1885 (#0)
> POST /api/v3/events HTTP/1.1
> Host: localhost:1885
> User-Agent: curl/7.64.1
> Accept-Encoding: deflate, gzip
> Authorization: Bearer MFRWG.DVTINRZNJDORITWD64NUJRIYVIXWCKJ3Q6VYLQY.E4K63GZ3WWTZGCIFMD7XLN7A7ACA35YCQSMFCBVCTEOMATCYGG6Q
> Accept: text/event-stream
> Content-Type: application/json
> Content-Length: 68
> 
* upload completely sent off: 68 out of 68 bytes
^C

अंतर के साथ master ।

htdvisser % curl -v 'http://localhost:1885/api/v3/events' --compressed -H 'Authorization: Bearer MFRWG.DVTINRZNJDORITWD64NUJRIYVIXWCKJ3Q6VYLQY.E4K63GZ3WWTZGCIFMD7XLN7A7ACA35YCQSMFCBVCTEOMATCYGG6Q' -H 'Accept: text/event-stream' -H 'Content-Type: application/json' --data-raw '{"identifiers":[{"application_ids":{"application_id":"admin-app"}}]}'
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 1885 (#0)
> POST /api/v3/events HTTP/1.1
> Host: localhost:1885
> User-Agent: curl/7.64.1
> Accept-Encoding: deflate, gzip
> Authorization: Bearer MFRWG.DVTINRZNJDORITWD64NUJRIYVIXWCKJ3Q6VYLQY.E4K63GZ3WWTZGCIFMD7XLN7A7ACA35YCQSMFCBVCTEOMATCYGG6Q
> Accept: text/event-stream
> Content-Type: application/json
> Content-Length: 68
> 
* upload completely sent off: 68 out of 68 bytes
< HTTP/1.1 200 OK
< Content-Type: text/event-stream
< Referrer-Policy: strict-origin-when-cross-origin
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Request-Id: 01EDTX9RGKRGM02YZVWNB3RXJP
< X-Xss-Protection: 1; mode=block
< Date: Wed, 22 Jul 2020 09:22:32 GMT
< Transfer-Encoding: chunked
< 
{"result":{"time":"0001-01-01T00:00:00Z"}}
^C

हमें इस मुद्दे को अलग करना होगा:

1. जब भी प्रति डोमेन और ब्राउज़र में छह टीसीपी कनेक्शन एक साथ खुले होते हैं, तो कोई भी बाद का अनुरोध लटका रहेगा। यह एक ब्राउज़र सीमा है और इससे निपटने के लिए आईएमओ के तरीकों पर किसी अन्य मुद्दे पर चर्चा की जानी चाहिए। यह वह समस्या है जो मुझे आपके वीडियो @rvolosatovs . में दिखाई दे रही है
2. जब कोई स्ट्रीम एंडपॉइंट तुरंत प्रतिक्रिया शीर्षलेख नहीं भेजता है, तो अनुरोध रुक जाएगा (जब तक कि शीर्षलेख अंततः पहले संदेश पर नहीं भेजा जाता)। इसका मतलब यह है कि हालांकि केवल एक टैब का उपयोग करते हुए, कंसोल लंबित स्ट्रीम कनेक्शन जमा करेगा, जब बार-बार स्ट्रीम कनेक्शन खोलने वाले पृष्ठों पर नेविगेट किया जाएगा। इस तरह के छह कनेक्शन खुले होने के बाद, कंसोल उसी कारण से हैंग हो जाएगा जैसे (1) में।

2 को कम करने के लिए, प्रतिक्रिया शीर्षलेख तुरंत भेजा जाना चाहिए।

यहाँ एक बात ध्यान देने योग्य है जहाँ तक कंसोल जाता है, हमें लंबित अनुरोधों को रद्द करने पर भी ध्यान देना चाहिए। वर्तमान में अनुरोध केवल स्ट्रीम कनेक्शन स्थापित होने के बाद ही रद्द किया जा सकता है।

@kschiffer क्या आप इस मुद्दे को 2 में पुन: पेश करने के लिए कदम दे सकते हैं?
मैं लगातार एक गेटवे डेटा टैब को रीफ्रेश कर रहा हूं और नवीनतम master (बिना पैच के) के साथ कोई हैंग नहीं अनुभव करता हूं

सबसे आसान तरीका यह है कि एक पूरी तरह से ताजा और असंबद्ध गेटवे बनाया जाए क्योंकि यह कोई संदेश नहीं भेजेगा। फिर इसके सिंहावलोकन पृष्ठ पर नेविगेट करना और छह बार गेटवे सूची पर वापस जाना।

यह गेटवे ईवेंट के लिए विशिष्ट समस्या नहीं है, बल्कि सभी ईवेंट स्ट्रीम होते हैं।

मुझे अनअसाइन करना क्योंकि यह कंसोल से उत्पन्न होने वाली समस्या नहीं है।

#2989 . द्वारा बंद

https://github.com/TheThingsNetwork/lorawan-stack/pull/2989 में एक अस्थायी समाधान पेश किया गया था - एक अधिक मजबूत समाधान अभी खोजा जाना बाकी है।

तो यह या तो हमारी निर्भरता में कुछ है (जीआरपीसी-गेटवे हेडर को ठीक से फ्लश नहीं कर रहा है) या हमारे साझा कोड में (शायद कुछ जीआरपीसी या http मिडलवेयर हेडर फ्लश नहीं कर रहे हैं)।

bug लेबल को हटाया जा रहा है क्योंकि यह वर्तमान में ऐसा कुछ नहीं है जो हमारे उपयोगकर्ताओं को प्रभावित करता है।

कृपया एक नया मुद्दा खोलें यदि अभी भी कुछ ऐसा है जिसे संबोधित करने की आवश्यकता है।