Lorawan-stack: Aliran Acara Memblokir Konsol Saat Mulai Acara Tidak Terkirim

Di konsol Firefox sedang memuat selamanya jika ada 6 tab yang terbuka - jika misalnya salah satu tab yang berfungsi di-refresh - salah satu tab yang memuat membuka blokir, tetapi kadang-kadang tampaknya gagal.

Bagaimanapun, saya mencoba mengirim pesan awal/akhir, tetapi itu tidak mengubah apa pun - masih hang setelah ada 6 tab.

Catatan: semua tab berada pada tampilan data gateway (2 yang berbeda)

@kschiffer ada ide?

Di konsol Firefox sedang memuat selamanya jika ada 6 tab yang terbuka - jika misalnya salah satu tab yang berfungsi di-refresh - salah satu tab yang memuat membuka blokir, tetapi kadang-kadang tampaknya gagal.

Itu yang diharapkan dan batasan aliran acara yang tidak diputar saat tidak menggunakan HTTP/2 :

Saat tidak digunakan melalui HTTP/2 , SSE mengalami batasan jumlah maksimum koneksi terbuka, yang bisa sangat menyakitkan saat membuka berbagai tab karena batasannya adalah _per browser_ dan disetel ke angka yang sangat rendah (6). Masalah telah ditandai sebagai "Tidak akan diperbaiki" di Chrome dan Firefox . Batas ini per browser + domain, sehingga Anda dapat membuka 6 koneksi SSE di semua tab ke www.example1.com dan 6 koneksi SSE lainnya ke www.example2.com. (dari Stackoverflow ). Saat menggunakan HTTP/2, jumlah maksimum _HTTP stream_ simultan dinegosiasikan antara server dan klien (defaultnya adalah 100).

Saya mengalami kesulitan mereproduksi masalah asli karena saya hanya memiliki akses ke dua gerbang yang terhubung di lingkungan pementasan.

Saya menduga ini disebabkan oleh fakta bahwa tajuk hanya ditulis tepat sebelum pesan pertama di aliran. Jika tidak ada pesan, tidak ada header dan browser terus menunggu.

Saya dapat mengkonfirmasi ini. Permintaan akan terhenti jika tidak mendapatkan header respons. Setelah enam koneksi seperti itu terbuka, semua XHR berikutnya juga akan terhenti.

Sebelum #2565, ini bukan masalah karena aliran acara akan selalu mengirim "pesan mulai streaming" segera, yang mengakibatkan header dikirim.

Karena itu, saya tidak melihatnya sebagai masalah frontend. Satu-satunya hal yang masuk akal untuk diubah di frontend adalah memastikan bahwa koneksi aliran yang terhenti dimatikan setelah waktu tertentu.

Jadi masalah terjadi ketika aliran acara tidak mengirim data apa pun. XHR yang melakukan koneksi aliran acara hanya akan diselesaikan setelah pesan pertama diterima, jika tidak, akan hang dalam status pending . Setelah 6 koneksi tersebut dibuka, semua koneksi lainnya juga akan hang, karena jumlah maksimum koneksi TCP bersamaan telah tercapai. Jadi sepertinya XHR mengharapkan semacam pengakuan dari server bahwa aliran dibuat.

Sebelum #2565, ini tidak menjadi masalah karena aliran acara akan selalu mengirimkan "pesan aliran awal".

Saat ini saya sedang mencoba mencari tahu apakah dan bagaimana ini dapat diperbaiki di sisi frontend.

Dalam pengalaman saya mengirim "pesan awal" tidak membantu dengan masalah ini. Silakan coba sendiri dengan diff berikut:

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 {

Berikut videonya:
https://youtu.be/0Ir0lakV-Mc

Saya melihat perbedaan.

Pada master TANPA perbedaan:

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

Pada master DENGAN perbedaan.

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

Kita harus membedakan masalah ini:

1. Setiap kali ada enam koneksi TCP terbuka secara bersamaan per domain dan browser, permintaan berikutnya akan hang. Ini adalah batasan browser dan cara IMO untuk mengatasinya harus dibahas dalam edisi lain. Ini adalah masalah yang saya lihat di video Anda @rvolosatovs
2. Ketika titik akhir aliran tidak segera mengirim tajuk respons, permintaan akan terhenti (sampai tajuk akhirnya dikirim pada pesan pertama). Ini berarti bahwa meskipun hanya menggunakan satu tab, konsol akan mengakumulasikan koneksi aliran yang tertunda saat menavigasi berulang kali ke halaman yang membuka koneksi aliran. Setelah enam koneksi tersebut terbuka, konsol akan hang, untuk alasan yang sama seperti pada (1).

Untuk mengurangi 2, header respons harus segera dikirim.

Satu hal yang perlu diperhatikan di sini sejauh konsol berjalan, kita harus melihat juga membatalkan permintaan yang tertunda. Saat ini permintaan hanya dapat dibatalkan setelah koneksi streaming dibuat.

@kschiffer dapatkah Anda memberikan langkah-langkah untuk mereproduksi masalah di 2. ?
Saya terus-menerus menyegarkan satu tab data gateway dan tidak mengalami hang dengan master (tanpa tambalan)

Cara termudah adalah membuat gateway yang benar-benar baru dan tidak terhubung karena tidak akan mengirim pesan apa pun. Kemudian menavigasi ke halaman ikhtisarnya dan kembali ke daftar gateway enam kali.

Ini bukan masalah khusus untuk acara gateway tetapi semua aliran acara.

Membatalkan penetapan saya karena ini bukan masalah yang berasal dari Konsol.

Ditutup oleh #2989

Solusi sementara diperkenalkan di https://github.com/TheThingsNetwork/lorawan-stack/pull/2989 - solusi yang lebih kuat belum ditemukan.

Jadi ini adalah sesuatu dalam dependensi kami (grpc-gateway tidak mem-flush header dengan benar) atau dalam kode bersama kami (mungkin beberapa grpc atau http middleware tidak mem-flush header).

Menghapus label bug karena saat ini bukan sesuatu yang memengaruhi pengguna kami.

Silakan buka edisi baru jika masih ada yang perlu dibenahi.