之前總結了 jmeter 分布式測試的過程，在部署過程中提到，要在 system.properties
中配置自己的 IP。

至於為什麽要這麽做，源於這一次 debug 的過程。

運行環境

mint, ubuntu 兩臺主機作為 master 節點，一臺 win server 作為 slave 節點，采用分布式的方式，
對 target 進行測試。

問題

問題很奇怪，以 mint 系統作為 master，調度分布式測試沒有問題，

$ jmeter -n -t ./test.jmx -R 10.27.2.210 -l test.jtl -e -o report_test
Creating summariser <summary>
Created the tree successfully using ./888.jmx
Configuring remote engine: 10.27.2.210
Starting remote engines
Starting the test @ Wed May 16 10:09:24 CST 2018 (1526436564379)
Remote engines have been started
Waiting for possible Shutdown/StopTestNow/Heapdump message on port 4445
summary =      1 in 00:00:00 =    3.5/s Avg:    20 Min:    20 Max:    20 Err:     0 (0.00%)
Tidying up remote @ Wed May 16 10:09:26 CST 2018 (1526436566910)
... end of run
 

而使用另一臺 ubuntu 主機作為 master，調度測試，則卡在 waiting 這一行，

$ jmeter -n -t ./test.jmx -R 10.27.2.210 -l test.jtl -e -o report_test
Creating summariser <summary>
Created the tree successfully using ./888.jmx
Configuring remote engine: 10.27.2.210
Starting remote engines
Starting the test @ Wed May 16 10:09:24 CST 2018 (1526436564379)
Remote engines have been started
Waiting for possible Shutdown/StopTestNow/Heapdump message on port 4445
 

嘗試1：防火墻幹擾

第一種猜測，應該是 ubuntu 系統的防火墻幹擾，阻止了 4445 端口的數據。

先關閉防火墻

$ sudo service ufw stop

再次運行測試，依舊卡在 waiting 那一行，看來問題沒有那麽簡單。

嘗試2：關閉監聽功能

以 Waiting for possible Shutdown/StopTestNow/Heapdump message on port 4445
信息在網上查找，有人建議修改 jmeter 設置，不監聽 shutdown 信息，相應的也就不會開啟 4445 端口，
理論上就不會卡在 waiting 那裏，而是直接跳過。

在 ubuntu 主機，修改 jmeter.properties 文件，

#jmeterengine.nongui.maxport=4455 修改為
jmeterengine.nongui.maxport=0

但是依舊不能工作。

嘗試3：端口沒有開啟

在 mint 作為 master，成功調度分布式測試的過程中，mint 主機自身打開了 4445 udp 端口，
用 netstat 可以查看的到。

但是，在 ubuntu 調度的時候，用 netstat 也可以查看到 4445 udp 端口已經打開。
而且用 netcat 測試 udp 端口也是可用的。

$ nc -vz -u 10.27.2.13 4445
Connection to 10.27.2.13 4445 port [udp/*] succeeded!

看來也不是端口未開放的問題。

嘗試4：信息被阻塞

猜測是不是在哪個環節，shutdown message 被阻攔，導致收不過消息，而一直卡在那裏。

於是在 mint 主機運行測試的時候，用 wireshark 監聽所有發送與 4445 udp 的信息，然而！什麽都沒有！

這樣看來，之前對問題的判斷是不準確的。一直以為和 shutdown message 有關，其實正常運行一次測試，根本不必要有 shutdown message。

嘗試5：在日誌中尋找

之前一直被表面現象迷惑，認為是 master 的問題，直到進入 slave 節點查看日誌 jmeter-server.log。
發現這樣的錯誤輸出，

2018-05-14 18:29:56,240 ERROR o.a.j.s.BatchSampleSender: testEnded(host)
java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is: 
    java.net.ConnectException: Connection refused: connect
    at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source) ~[?:1.8.0_162]
    at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown Source) ~[?:1.8.0_162]
    at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown Source) ~[?:1.8.0_162]
    at sun.rmi.server.UnicastRef.invoke(Unknown Source) ~[?:1.8.0_162]
    at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(Unknown Source) ~[?:1.8.0_162]
    at java.rmi.server.RemoteObjectInvocationHandler.invoke(Unknown Source) ~[?:1.8.0_162]
    at com.sun.proxy.$Proxy20.testEnded(Unknown Source) ~[?:?]
    at org.apache.jmeter.samplers.BatchSampleSender.testEnded(BatchSampleSender.java:127) [ApacheJMeter_core.jar:4.0 r1823414]
    at org.apache.jmeter.samplers.DataStrippingSampleSender.testEnded(DataStrippingSampleSender.java:86) [ApacheJMeter_core.jar:4.0 r1823414]
    at org.apache.jmeter.samplers.RemoteListenerWrapper.testEnded(RemoteListenerWrapper.java:90) [ApacheJMeter_core.jar:4.0 r1823414]
    at org.apache.jmeter.engine.StandardJMeterEngine.notifyTestListenersOfEnd(StandardJMeterEngine.java:229) [ApacheJMeter_core.jar:4.0 r1823414]
    at org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:495) [ApacheJMeter_core.jar:4.0 r1823414]
    at java.lang.Thread.run(Unknown Source) [?:1.8.0_162]
Caused by: java.net.ConnectException: Connection refused: connect
    at java.net.DualStackPlainSocketImpl.connect0(Native Method) ~[?:1.8.0_162]
    at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source) ~[?:1.8.0_162]
    at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source) ~[?:1.8.0_162]
    at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source) ~[?:1.8.0_162]
    at java.net.AbstractPlainSocketImpl.connect(Unknown Source) ~[?:1.8.0_162]
    at java.net.PlainSocketImpl.connect(Unknown Source) ~[?:1.8.0_162]
    at java.net.SocksSocketImpl.connect(Unknown Source) ~[?:1.8.0_162]
    at java.net.Socket.connect(Unknown Source) ~[?:1.8.0_162]
    at java.net.Socket.connect(Unknown Source) ~[?:1.8.0_162]
    at java.net.Socket.<init>(Unknown Source) ~[?:1.8.0_162]
    at java.net.Socket.<init>(Unknown Source) ~[?:1.8.0_162]
    at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(Unknown Source) ~[?:1.8.0_162]
    at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(Unknown Source) ~[?:1.8.0_162]
    ... 13 more

為什麽地址是 127.0.1.1 ？為什麽要向這個地址通信？

根據對 jmeter master/slave 通信機制的理解，不僅 master 主動向 slave 通信， slave 也向 master 主動通信，自然要知道彼此的地址。

由此聯想到，在 slave 節點多網卡的時候，一般都設置 hostname，猜測 master 也需要進行同樣的設置，告知 slave 自己的通信地址。

於是在 ubuntu master 主機的 system.properties 最後一行添加，

java.rmi.server.hostname=10.27.2.13

測試終於正常運行了。

寫在最後

推而廣之，在 jmeter 的所有節點，無論 master/slave，都顯示設置自己的 IP 地址。

system.properties 最後一行添加

java.rmi.server.hostname=<IP addr>

為什麽 jmeter 分布式測試，一定要設置 java.rmi.server.hostname