これはメッセージパッシングに関する質問です。これは特に、C#で記述された社内アプリケーションに関連しています。しかし、erlangに似た自家製の「メッセージパッシング」システムがあります。
さて、私たちは、erlangの人々やドキュメントから学び、メッセージパッシングのいくつかの課題に対するエレガントな解決策を見つけることができるようになることを願っています。しかし残念ながら、オンラインやフォーラムでerlangのドキュメントを読んだ後、これらのトピックは取り上げられていないようです。
したがって、問題は次のとおりです。erlangでは、プロセスにメッセージを送信するためのキューがいっぱいになるのはいつですか?そして、erlangはキューがいっぱいの状況を処理しますか?それとも、erlangでメッセージを渡すためのキューは無限ですか?それはシステムメモリによってのみ制限されますか?
私たちのシステムでは、ディスクから数十億の情報のタプルが読み取られる可能性のある金融データのストリームを処理する必要があります。金融情報の各タプルは、金融の世界では「ダニ」と呼ばれます。
そのため、システム内の各「プロセス」のキューサイズに制限を設定する必要がありました。各キューで最大1000アイテムを任意に選択しました。これで、これらのキューはすぐにティックメッセージで完全にいっぱいになります。
問題は、プロセスがティックだけでなく他のタイプのメッセージも相互に送信する必要があるが、ティックがキューをいっぱいにして、他のタイプのメッセージが渡されないようにすることです。
「バンドエイド」ソリューション(面倒です)として、メッセージタイプごとにプロセスごとに複数のキューを許可します。したがって、プロセスにはティックキュー、コマンドキュー、フィルキューなどがあります。
しかし、erlangは、異なるメッセージタイプを運ぶ各「プロセス」への単一のキューを持つことにより、非常にクリーンに見えます。しかし、繰り返しになりますが、メッセージタイプの1つだけのフラッドによってキューが占有されるのをどのように処理しますか?
おそらくこれはerlangの内部についての質問です。erlangには、キュー内のメッセージタイプに内部的に個別の制限がありますか?または、メッセージの種類ごとに内部に個別のキューがありますか?
いずれにせよ、キューがいっぱいで特定の種類のメッセージを受信できない場合、送信プロセスはどのように認識しますか?送信は失敗しますか?それは、送信できないためにerlangでエラー処理が必要になることを意味しますか?
私たちのシステムでは、キューがいっぱいになると追跡し、キューがいっぱいになるまでキューに追加しようとするプロセスが実行されないようにします。これにより、プロセスが呼び出されると、1つのメッセージを送信する余地があることが保証されるため、厄介なエラー処理ロジックが回避されます。
しかし、繰り返しになりますが、同じキューに複数の種類のメッセージを配置するとします。通過する必要のある他の種類のメッセージはブロックされます。
erlangはこの状況を処理するように設計されていないので、キューが単一のメッセージタイプのフラッドでいっぱいになるという問題に対処していないというのは、おそらく誤った印象になりました。
しかし、誰かがこの特定のシナリオをカバーする良い参考情報や本にこの点に答える方法を知っていることを願っています。