回答編集履歴
2
追記が必要。最後の文を削除
test
CHANGED
@@ -27,8 +27,52 @@
|
|
27
27
|
|
28
28
|
試してみると、RPCServerは再起動するとリクエストを処理できませんでした。
|
29
29
|
|
30
|
+
---
|
31
|
+
追記 (2022-01-24)
|
32
|
+
|
33
|
+
「考えてみたいこと」は本題から外れているので無視してください。まず、RCPServerを理解するための技術的な知識を書き、次に、while(true)について意見を述べます。
|
34
|
+
|
35
|
+
【技術的な知識】
|
36
|
+
|
37
|
+
**thread**
|
38
|
+
|
39
|
+
- Javaプロセスは、スレッド(daemon以外のスレッド)が全て終了した時点で、終了する
|
40
|
+
- RabbitMQのConnection/Channelを生成すると、スレッドが起動し、Connection/Channelを閉じるとスレッドが終了する
|
41
|
+
- ExecutorServiceを利用。送受信や、ブローカーの生死確認、シャットダウンのため
|
42
|
+
- 本来の目的のChannel処理だけでなく、管理用のスレッドが起動されます
|
43
|
+
|
44
|
+
mainスレッドが終了したとき、他にスレッドが生きていればプロセスは終了しません。チュートリアルのプログラムでは、Connectionを作成して閉じなければ、スレッドが生きています。プロセスは終わらないので、CTL-Cで中断します。
|
45
|
+
|
46
|
+
**try-with-resources**
|
47
|
+
|
48
|
+
- try(<リソース設定>) {} の形式。catch, finallyはオプション
|
49
|
+
- リソース設定で宣言できる変数は、AutoCloseableインターフェイスを実装するクラス
|
50
|
+
- tryブロックを抜けると、AutoCloseableリソースを、宣言が内側のものから順に閉じる
|
51
|
+
|
52
|
+
try-with-resoucesを使ってConnection/Channelを利用すると、tryブロックを抜けた時点でConnection/Channelが閉じられ、スレッドが終わる。RPCServerプログラムは、try-with-resoucesを抜けると、mainスレッドが1つだけ生きていて、main()メソッドを抜けたところでスレッドがいなくなり、プロセスが終了する。
|
53
|
+
|
54
|
+
**notify/wait**
|
55
|
+
|
56
|
+
RPCserverでは、mainスレッドをビジーウェイトせずに無限ループさせるために使っています。目的は、try-with-resourcesブロックに留まり続けて、生成したConnection配下のChannelのスレッドで、コールバック処理を行わせるためです。
|
57
|
+
|
58
|
+
|
59
|
+
【個人的な意見】
|
60
|
+
|
61
|
+
RPCServerでwhile(true) を使う本当の理由はチュートリアル作成者に聞くしかありませんが、RPCServerのやり方が好ましいと思います。
|
62
|
+
- try-with-resourcesを使ってChannel/Connectionを明に閉じることで、リソースの利用スコープを制限することができる。
|
63
|
+
- Channelを生成すると、メッセージブローカー側にも、ピアのerlang処理が作成される
|
64
|
+
- while(true) をwhile(<サーバーの稼働条件>)とすれば、きちんとリソースを解放して、サーバーを行儀良く終了させることができる。
|
65
|
+
|
66
|
+
RabbitMQのFAQを調べてみてはいかが。
|
67
|
+
|
68
|
+
|
69
|
+
(RabbitMQについては、わからないことが多く、 調べが進めば追記するかもしれません。)
|
70
|
+
|
71
|
+
利用したjarを追記します。
|
72
|
+
|
73
|
+
```bash
|
74
|
+
CLASSPATH=$RABBITMQ_LIB/slf4j-simple-1.7.33.jar:$RABBITMQ_LIB/slf4j-api-1.7.33.jar:$RABBITMQ_LIB/amqp-client-5.14.1.jar
|
75
|
+
```
|
30
76
|
|
31
77
|
|
32
78
|
|
33
|
-
|
34
|
-
|
1
test
CHANGED
@@ -25,7 +25,7 @@
|
|
25
25
|
|
26
26
|
キューを利用するシステムは、Webサーバーのように常時動作しなくても良いのでは。もっとゆるい条件で、例えば、RPCServerを32回起動したとしても、RPCClientに正しいレスポンスを返せれば、問題ないと思われます。
|
27
27
|
|
28
|
-
試してみると、RPCServerは再起動するとリクエストを処理できませんでした。
|
28
|
+
試してみると、RPCServerは再起動するとリクエストを処理できませんでした。
|
29
29
|
|
30
30
|
|
31
31
|
|