Spring WebSocketsとUndertowで16kBを超えるWebSocketメッセージを受け取る方法

Question

Spring Boot、Spring WebSocket、Undertowを使用して大規模なサブプロトコルメッセージを受信する際に問題が発生します。メッセージは16kB後に切断されます。いくつかの掘削を行った後、私は私がやりたいように思われる次の構成プロパティが見つかりました：

server.undertow.buffer-size=32768 

は、この構成プロパティは、/ configpropsアクチュエータエンドポイントをチェックする際に適切に取り上げているようです。残念ながら、これは16kBを超えるメッセージを受信するのに役立たないようです。

Iはまた、アンダートウドキュメント（強調鉱山）からこの不吉なラインにつまずいた：これは通常て書き込むことができるデータの最大量であるように、サーバのための理想的なサイズは、一般的に16Kである

write（）操作を介して（オペレーティングシステムのネットワーク設定に応じて）。

これは、server.undertow.buffer-sizeの設定がOSレベルの設定によって制限されているため、何も起こっていないことを確認します。私はUbuntu Linuxを使用しているので、私はnet.core.rmem_*とnet.core.wmem_*の設定で回り込んでいますが、これらはいずれの効果もないようです。この問題をmacOSで再現することはできません。

これらのメッセージをサポートするためにUndertow、Spring Boot、および/またはSpring WebSocketを設定する方法を知っている人はいますか？

Answer 1

私は直接上記の質問に直接答えました。私が春のブートで提案した設定はの仕事をする！私たちが持っていた問題は、ロードバランサは、私たちの場合、ハプロキシで、その前に16kB後のメッセージを切断したことでした。より大きなメッセージが問題を解決できるように、haproxyをチューニングします。その間、我々はより効率的であるために我々が使用していたプロトコルを微調整して、これらの大きなメッセージをもはや必要としないようにして、我々のハプロキシソリューションは生産中（YMMV）でテストされなかった。

開発者はすべてmacOSとWindowsで作業していたため、Ubuntuを実行した受諾環境と本番環境でのみ問題が発生したため、これが原因であると誤って判断しました。

レッスンは、（これらはすべて本当にばかと基本的なものですが、我々はとにかくこれらのミスを犯した）学んだ：

• は、すべての仮定を検証してください！もしUbuntuが問題だと思えば、以前にテストでUbuntuを選んでいたはずです。たとえば、UbuntuでVMを使用して、quarantaineでの前提条件を検証します。
• 開発環境が本番環境に一致していることを確認してください。私たちの開発環境では、我々はhaproxyを実行していませんでした。 「高水準」の開発者は、商品インフラストラクチャとしてロードバランサとWebサーバーを別々に置く傾向がありますが、この例では、これらの「商品」がアプリケーションの作業に非常に直接影響することが示されています。