Lorawan-stack: وحدة تحكم تدفقات الأحداث عند عدم إرسال أحداث البدء

يتم تحميل وحدة التحكم في Firefox إلى الأبد إذا كانت هناك 6 علامات تبويب مفتوحة - إذا تم تحديث إحدى علامات تبويب العمل على سبيل المثال - يتم إلغاء حظر إحدى علامات تبويب التحميل ، ولكن يبدو أن ذلك يفشل في بعض الأحيان.

على أي حال ، حاولت إرسال رسائل البداية / النهاية ، لكن ذلك لم يغير شيئًا - لا يزال معلقًا بعد وجود 6 علامات تبويب.

ملاحظة: جميع علامات التبويب موجودة في عرض البيانات الخاص بالبوابة (علامتان مختلفتان)

kschiffer أي أفكار؟

يتم تحميل وحدة التحكم في Firefox إلى الأبد إذا كانت هناك 6 علامات تبويب مفتوحة - إذا تم تحديث إحدى علامات تبويب العمل على سبيل المثال - يتم إلغاء حظر إحدى علامات تبويب التحميل ، ولكن يبدو أن ذلك يفشل في بعض الأحيان.

هذا أمر متوقع وهناك قيد لا يلزم تدفقات الأحداث أثناء عدم استخدام HTTP / 2 :

عند عدم استخدامه عبر HTTP / 2 ، فإن SSE يعاني من قيود على الحد الأقصى لعدد الاتصالات المفتوحة ، والتي يمكن أن تكون مؤلمة بشكل خاص عند فتح علامات تبويب مختلفة حيث أن الحد _ لكل متصفح_ ويتم ضبطه على رقم منخفض جدًا (6). تم وضع علامة على المشكلة على أنها "لن يتم إصلاحها" في Chrome و Firefox . هذا الحد لكل متصفح + مجال ، وهذا يعني أنه يمكنك فتح 6 اتصالات SSE عبر جميع علامات التبويب إلى www.example1.com و 6 اتصالات SSE أخرى بـ www.example2.com. (من Stackoverflow ). عند استخدام HTTP / 2 ، يتم التفاوض على الحد الأقصى لعدد تدفقات HTTP المتزامنة بين الخادم والعميل (الافتراضي هو 100).

أواجه مشكلة في إعادة إنتاج المشكلة الأصلية نظرًا لأنه لا يمكنني الوصول إلا إلى بوابتين متصلتين في بيئة التدريج.

أظن أن السبب في ذلك هو حقيقة أن الرؤوس تتم كتابتها فقط قبل الرسالة الأولى في البث. إذا لم تكن هناك رسالة ، فلا يوجد عنوان ويظل المتصفح في الانتظار.

أستطيع أن أؤكد هذا. ستتوقف الطلبات إذا لم تحصل على رأس استجابة. بعد فتح ستة اتصالات من هذا القبيل ، ستتوقف جميع XHRs اللاحقة أيضًا.

قبل 2565 # لم تكن هذه مشكلة لأن دفق الحدث كان يرسل دائمًا "رسالة بدء البث" على الفور ، مما أدى إلى إرسال الرؤوس.

على هذا النحو ، لا أرى أنها مشكلة أمامية. الشيء الوحيد الذي من المنطقي تغييره في الواجهة الأمامية هو التأكد من أن اتصالات الدفق المتوقفة قد توقفت بعد وقت معين.

لذلك تحدث المشكلة عندما لا ترسل تدفقات الأحداث أي بيانات. لن يتم حل XHR الذي يقوم بإجراء اتصال تيار الحدث إلا بعد استلام الرسالة الأولى ، وإلا فسيتم تعليقه في حالة pending . بمجرد فتح 6 من هذه الاتصالات ، ستتوقف جميع التوصيلات الأخرى أيضًا ، حيث تم الوصول إلى الحد الأقصى من اتصالات TCP المتزامنة. لذلك يبدو أن XHR تتوقع نوعًا من الإقرار من الخادم بأنه تم إنشاء الدفق.

قبل 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. كلما كان هناك ستة اتصالات TCP مفتوحة بشكل متزامن لكل مجال ومتصفح ، سيتم تعليق أي طلب لاحق. هذا هو قيود المتصفح ويجب مناقشة طرق IMO للتعامل مع هذا في قضية أخرى. هذه هي المشكلة التي أراها في الفيديو الخاص بكrvolosatovs
2. عندما لا ترسل نقطة نهاية الدفق رأس استجابة على الفور ، سيتوقف الطلب (حتى يتم إرسال الرأس في النهاية في الرسالة الأولى). هذا يعني أنه على الرغم من استخدام علامة تبويب واحدة فقط ، ستجمع وحدة التحكم اتصالات الدفق المعلقة عند التنقل المتكرر إلى الصفحات التي تفتح اتصالات الدفق. بعد فتح ستة اتصالات من هذا القبيل ، ستتوقف وحدة التحكم لنفس السبب كما في (1).

لتقليل 2 ، يجب إرسال رأس الاستجابة على الفور.

هناك شيء واحد يجب ملاحظته هنا فيما يتعلق بوحدة التحكم ، يجب أن ننظر أيضًا في إلغاء الطلبات المعلقة. لا يمكن حاليًا إلغاء الطلبات إلا بعد إنشاء اتصال البث.

kschiffer هل يمكنك إعطاء خطوات لإعادة
أقوم باستمرار بتحديث علامة تبويب بيانات بوابة واحدة ولا أجرب أي توقف مع أحدث master (بدون تصحيح)

أسهل طريقة هي إنشاء بوابة جديدة تمامًا وغير متصلة لأنها لن ترسل أي رسائل. ثم انتقل إلى صفحة النظرة العامة الخاصة به والعودة إلى قائمة البوابة ست مرات.

هذه ليست مشكلة خاصة بأحداث البوابة ولكن بالمناسبة كل تدفقات الأحداث.

إلغاء تعييني لأن هذه ليست مشكلة ناشئة عن وحدة التحكم.

مغلق برقم 2989

تم تقديم حل مؤقت في https://github.com/TheThingsNetwork/lorawan-stack/pull/2989 - لم يتم العثور على حل أكثر قوة بعد.

إذن هذا إما شيء في تبعياتنا (بوابة grpc لا تقوم بمسح الرؤوس بشكل صحيح) أو في الكود المشترك (ربما لا تقوم بعض البرامج الوسيطة grpc أو http بمسح الرؤوس).

إزالة التصنيف bug لأنه ليس شيئًا يؤثر على مستخدمينا في الوقت الحالي.

الرجاء فتح مشكلة جديدة إذا كان لا يزال هناك شيء يحتاج إلى معالجة.