Jmeter的端口使用问题解析

三则时光 07-06 210

前言：

而今大家对“apachecxf2xjar”大约比较关切，我们都想要剖析一些“apachecxf2xjar”的相关内容。那么小编在网上搜集了一些关于“apachecxf2xjar””的相关知识，希望咱们能喜欢，同学们一起来了解一下吧！

Jmeter的端口是通过Java的RMI技术实现的，大家都知道默认端口是1099，用到RMI即远程方法调用(Remote Method Invocation)的特性（支持存储于不同地址空间的程序级对象之间彼此进行通信，实现远程对象之间的无缝远程调用）。Java RMI 用于不同虚拟机之间的通信，这些虚拟机可以在不同的主机上、也可以在同一个主机上；一个虚拟机中的对象调用另一个虚拟机中的对象的方法，只不过是允许被远程调用的对象要通过一些标志加以标识。

RMI的交互图：

RMI由3个部分构成，第一个是rmiregistry（JDK提供的一个可以独立运行的程序，在bin目录下），第二个是server端的程序，对外提供远程对象，第三个是client端的程序，想要调用远程对象的方法。

首先，先启动rmiregistry服务，启动时可以指定服务监听的端口，也可以使用默认的端口（1099，不做配置的话就是默认端口）。

其次，server端在本地先实例化一个提供服务的实现类，然后通过RMI提供的Naming/Context/Registry（下面实例用的Registry）等类的bind或rebind方法将刚才实例化好的实现类注册到rmiregistry上并对外暴露一个名称。

最后，client端通过本地的接口和一个已知的名称（即rmiregistry暴露出的名称）再使用RMI提供的Naming/Context/Registry等类的lookup方法从RMIService那拿到实现类。这样虽然本地没有这个类的实现类，但所有的方法都在接口里了，便可以实现远程调用对象的方法了。

方法调用从客户对象经存根（stub）、远程引用层（Remote Reference Layer）和传输层（Transport Layer）向下，传递给主机，然后再次经传输层，向上穿过远程调用层和骨干网（Skeleton），到达服务器对象。

说完这些，我们再来看看Jmeter，其实Jmeter有三个端口是我们需要关注的，一个是server_port（默认1099，还有server.rmi.port是用来覆盖server_port），这是每个压测节点（压测服务）都必须启用的端口，另一个是从节点（Slave/Server）的server.rmi.localport （默认未设置，很多人也设置成1099），还有一个是主节点（Master/Client）的client.rmi.localport （默认是随机的，设置为0或不设置就表示随机），由于后两端口都是随机的，所以我们一般不关注它们，但是如果是在防火墙下，或是Docker环境中，我们不允许端口随机，那就必须设置固定端口：

我们需要为每个从节点或者服务器打开2个端口（由主节点向从节点发送数据，所以这两端口有时候也可以同时设置成1099）。

Server_port=1099

server.rmi.localport=50000

可以在节点配置文件jmeter.properties中设置，也可以在启动节点时设置：

$JMETER_HOME/bin/jmeter-server \                        -Dserver.rmi.localport=50000 \                        -Dserver_port=1099

在客户端计算机上打开一个端口，以便从属服务器将结果发送给主服务器。

client.rmi.localport=60000

可以在主服务的配置文件jmeter.properties中设置，也可以在压测命令中配置（如果配置文件中这块也设置了端口，将以配置文件的为准）：

jmeter -n -t sample-test/sample-test.jmx -Dclient.rmi.localport=60000 -R172.17.0.5,172.17.0.6,172.17.0.7

从上面的主从关系调用来看，也能明白端口的设置关系，但是如果我们严格按照以上的方式配置了，并且相应端口在防火墙下也放行了，是否就表示没问题了，不一定，我们还要结合日志对一些异常进行分析。

情况一：RMI开启了附加端口，导致防火墙下主节点传输端口还是不通

我们在master主控端设置了client.rmi.localport=60000的端口，但实际上当我们压测时，进程会再开启另外两个端口（60001和60002）。

为了确保压测顺利，这两个端口也应该在防火墙下放行，否则可能出现压测时卡着不动，如下日志：

SLF4J: Class path contains multiple SLF4J bindings.SLF4J: Found binding in [jar:file:/root/.jmeter/apache-jmeter-5.1.1/lib/log4j-slf4j-impl-2.11.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]SLF4J: Found binding in [jar:file:/root/.jmeter/apache-jmeter-5.1.1/lib/ext/jmeter-plugins-dubbo-2.7.3-jar-with-dependencies.jar!/org/slf4j/impl/StaticLoggerBinder.class]SLF4J: See  for an explanation.SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]Creating summariser <summary>Created the tree successfully using weixin-Test.jmxConfiguring remote engine: 192.168.0.154Using local port: 1099Starting remote enginesStarting the test @ Thu Mar 25 08:52:37 CST 2021 (1616633557889)Remote engines have been startedWaiting for possible Shutdown/StopTestNow/HeapDump/ThreadDump message on port 4445

一般一直卡在Waiting中，就表示端口不通，要么是端口没完全开放（本例属于这种情况，只开放了60000，没有开放附加端口），要么是java.rmi.server.hostname没设置（在多网卡情况下，没设置hostname也可能会导致RMI连通信息被阻塞），我们可以看jmeter.log日志，发现没有异常，slave引擎正常启动：

2021-03-25 08:52:40,543 INFO o.a.j.r.RmiUtils: Disabling SSL for RMI as server.rmi.ssl.disable is set to 'true'2021-03-25 08:52:40,543 INFO o.a.j.s.BatchSampleSender: Using batching (client settings) for this run. Thresholds: num=100, time=600002021-03-25 08:52:40,543 INFO o.a.j.s.DataStrippingSampleSender: Using DataStrippingSampleSender for this run2021-03-25 08:56:55,186 INFO o.a.j.e.ClientJMeterEngine: sent test to 192.168.0.154 basedir='.'2021-03-25 08:56:55,187 INFO o.a.j.e.ClientJMeterEngine: Sending properties {}2021-03-25 08:56:55,193 INFO o.a.j.e.ClientJMeterEngine: sent run command to 192.168.0.1542021-03-25 08:56:55,193 INFO o.a.j.e.DistributedRunner: Remote engines have been started

我们再到slave端看jmeter-server.log日志，发现被主节点拒绝连接了：

2021-03-25 08:56:55,179 INFO o.a.j.e.RemoteJMeterEngineImpl: Creating JMeter engine on host 192.168.0.154 base '.'2021-03-25 08:56:55,179 INFO o.a.j.e.RemoteJMeterEngineImpl: Remote client host: 192.168.0.1822021-03-25 08:56:55,180 INFO o.a.j.e.StandardJMeterEngine: StandardJMeterEngine Start ............................ 192.168.0.1542021-03-25 08:56:55,182 INFO o.a.j.s.FileServer: Default base='/opt/apache-jmeter-5.1.1/bin'2021-03-25 08:56:55,185 INFO o.a.j.s.FileServer: Set new base='.'2021-03-25 08:56:55,189 INFO o.a.j.e.StandardJMeterEngine: Applying properties {}2021-03-25 08:56:55,190 INFO o.a.j.e.RemoteJMeterEngineImpl: Running test2021-03-25 08:56:55,193 INFO o.a.j.e.StandardJMeterEngine: Running the test!2021-03-25 08:56:55,193 INFO o.a.j.s.SampleEvent: List of sample_variables: []2021-03-25 08:56:55,197 INFO o.a.j.e.u.CompoundVariable: Note: Function class names must contain the string: '.functions.'2021-03-25 08:56:55,197 INFO o.a.j.e.u.CompoundVariable: Note: Function class names must not contain the string: '.gui.'2021-03-25 08:59:02,795 ERROR o.a.j.s.RemoteListenerWrapper: testStarted(host) on 192.168.0.154java.rmi.ConnectException: Connection refused to host: 192.168.0.182; nested exception is:         java.net.ConnectException: Connection timed out (Connection timed out)        at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619) ~[?:1.8.0_171]        at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216) ~[?:1.8.0_171]        at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202) ~[?:1.8.0_171]        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:129) ~[?:1.8.0_171]        at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227) ~[?:1.8.0_171]        at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179) ~[?:1.8.0_171]        at com.sun.proxy.$Proxy20.testStarted(Unknown Source) ~[?:?]        at org.apache.jmeter.samplers.RemoteListenerWrapper.testStarted(RemoteListenerWrapper.java:79) [ApacheJMeter_core.jar:5.1.1.20200917]        at org.apache.jmeter.engine.StandardJMeterEngine.notifyTestListenersOfStart(StandardJMeterEngine.java:210) [ApacheJMeter_core.jar:5.1.1.20200917]        at org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:387) [ApacheJMeter_core.jar:5.1.1.20200917]        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_171]Caused by: java.net.ConnectException: Connection timed out (Connection timed out)        at java.net.PlainSocketImpl.socketConnect(Native Method) ~[?:1.8.0_171]        at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[?:1.8.0_171]        at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) ~[?:1.8.0_171]        at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) ~[?:1.8.0_171]        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[?:1.8.0_171]        at java.net.Socket.connect(Socket.java:589) ~[?:1.8.0_171]        at java.net.Socket.connect(Socket.java:538) ~[?:1.8.0_171]        at java.net.Socket.<init>(Socket.java:434) ~[?:1.8.0_171]        at java.net.Socket.<init>(Socket.java:211) ~[?:1.8.0_171]        at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40) ~[?:1.8.0_171]        at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:148) ~[?:1.8.0_171]        at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613) ~[?:1.8.0_171]        ... 10 more2021-03-25 09:01:10,027 ERROR o.a.j.s.RemoteListenerWrapper: testStarted(host) on 192.168.0.154java.rmi.ConnectException: Connection refused to host: 192.168.0.182; nested exception is:         java.net.ConnectException: Connection timed out (Connection timed out)        at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619) ~[?:1.8.0_171]        at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216) ~[?:1.8.0_171]        at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202) ~[?:1.8.0_171]        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:129) ~[?:1.8.0_171]        at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227) ~[?:1.8.0_171]        at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179) ~[?:1.8.0_171]        at com.sun.proxy.$Proxy20.testStarted(Unknown Source) ~[?:?]        at org.apache.jmeter.samplers.RemoteListenerWrapper.testStarted(RemoteListenerWrapper.java:79) [ApacheJMeter_core.jar:5.1.1.20200917]        at org.apache.jmeter.engine.StandardJMeterEngine.notifyTestListenersOfStart(StandardJMeterEngine.java:210) [ApacheJMeter_core.jar:5.1.1.20200917]        at org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:387) [ApacheJMeter_core.jar:5.1.1.20200917]        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_171]Caused by: java.net.ConnectException: Connection timed out (Connection timed out)        at java.net.PlainSocketImpl.socketConnect(Native Method) ~[?:1.8.0_171]        at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[?:1.8.0_171]        at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) ~[?:1.8.0_171]        at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) ~[?:1.8.0_171]        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[?:1.8.0_171]        at java.net.Socket.connect(Socket.java:589) ~[?:1.8.0_171]        at java.net.Socket.connect(Socket.java:538) ~[?:1.8.0_171]        at java.net.Socket.<init>(Socket.java:434) ~[?:1.8.0_171]        at java.net.Socket.<init>(Socket.java:211) ~[?:1.8.0_171]

说明还是端口不通，明明我们开放了60000端口，但还是会出现拒绝连接的情况，怎么办呢？这时候只要把60001和60002端口也都同时开放，这个问题就可以解决。

以上是用我们的jmeter压测平台（基于Jmeter的性能压测平台实现_smooth-z的博客-CSDN博客_压测平台）遇到的情况，实际上用jmeter脚本命令跑测（jmeter -n -t sample-test/sample-test.jmx -Dclient.rmi.localport=60000 -R192.168.0.154），也会发现进程开启了60001和60002来个端口，但却没有60000端口，说明60001-2这两个端口才是负责进行数据交互传输，如下所示：

在脚本命令模式下，压测任务结束后，这个60001和60002端口就会被释放。如果两个脚本任务同时进行，肯定也会出现端口冲突。但是用压测平台的api进程模式，就没有这个问题，多个任务可以共享这两个端口传输，但副作用就是60000-60002这三个端口一直不会释放（即使压测任务已经结束），除非重启平台服务进程。

以上的问题是在Jmeter5.1.1版本下遇到的，其他版本没试过不知道

情况二：传输端口被占用，如命令模式下的slave多任务运行

由于我们固定了端口，带来的副作用是显而易见的，就是多个脚本同时调用不同slave节点压测时，还是会出现端口占用，一般压测时报以下错误，我们就要怀疑是否端口被占用了：

SLF4J: Class path contains multiple SLF4J bindings.SLF4J: Found binding in [jar:file:/root/.jmeter/apache-jmeter-5.1.1/lib/log4j-slf4j-impl-2.11.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]SLF4J: Found binding in [jar:file:/root/.jmeter/apache-jmeter-5.1.1/lib/ext/jmeter-plugins-dubbo-2.7.3-jar-with-dependencies.jar!/org/slf4j/impl/StaticLoggerBinder.class]SLF4J: See  for an explanation.SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]Creating summariser <summary>Created the tree successfully using weixin-Test.jmxConfiguring remote engine: 192.168.0.154Using local port: 1099Starting remote enginesStarting the test @ Thu Mar 25 08:22:59 CST 2021 (1616631779725)Error in rconfigure() method java.rmi.MarshalException: error marshalling arguments; nested exception is:         java.io.NotSerializableException: org.apache.jmeter.threads.RemoteThreadsListenerTestElementRemote engines have been startedWaiting for possible Shutdown/StopTestNow/HeapDump/ThreadDump message on port 4445

我们再看jmeter.log日志，就会发现端口占用的提示：

2021-03-25 08:23:00,023 ERROR o.a.j.e.ConvertListeners: Error replacing class org.apache.jmeter.threads.RemoteThreadsListenerTestElement by wrapper: class org.apache.jmeter.threads.RemoteThreadsListenerWrapperjava.rmi.server.ExportException: Port already in use: 60001; nested exception is:         java.net.BindException: 地址已在使用 (Bind failed)        at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:346) ~[?:1.8.0_171]        at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:254) ~[?:1.8.0_171]        at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411) ~[?:1.8.0_171]        at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) ~[?:1.8.0_171]        at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:236) ~[?:1.8.0_171]        at java.rmi.server.UnicastRemoteObject.exportObject(UnicastRemoteObject.java:383) ~[?:1.8.0_171]        at java.rmi.server.UnicastRemoteObject.exportObject(UnicastRemoteObject.java:346) ~[?:1.8.0_171]        at java.rmi.server.UnicastRemoteObject.<init>(UnicastRemoteObject.java:225) ~[?:1.8.0_171]        at org.apache.jmeter.threads.RemoteThreadsListenerImpl.<init>(RemoteThreadsListenerImpl.java:59) ~[ApacheJMeter_core.jar:5.1.1 r1855137]        at org.apache.jmeter.engine.ConvertListeners.addNode(ConvertListeners.java:64) [ApacheJMeter_core.jar:5.1.1 r1855137]        at org.apache.jorphan.collections.HashTree.traverse(HashTree.java:976) [jorphan.jar:5.1.1 r1855137]        at org.apache.jmeter.engine.ClientJMeterEngine.runTest(ClientJMeterEngine.java:137) [ApacheJMeter_core.jar:5.1.1 r1855137]        at org.apache.jmeter.engine.DistributedRunner.start(DistributedRunner.java:132) [ApacheJMeter_core.jar:5.1.1 r1855137]        at org.apache.jmeter.engine.DistributedRunner.start(DistributedRunner.java:149) [ApacheJMeter_core.jar:5.1.1 r1855137]        at org.apache.jmeter.JMeter.runNonGui(JMeter.java:1089) [ApacheJMeter_core.jar:5.1.1 r1855137]        at org.apache.jmeter.JMeter.startNonGui(JMeter.java:991) [ApacheJMeter_core.jar:5.1.1 r1855137]        at org.apache.jmeter.JMeter.start(JMeter.java:563) [ApacheJMeter_core.jar:5.1.1 r1855137]        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_171]        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_171]        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_171]        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_171]        at org.apache.jmeter.NewDriver.main(NewDriver.java:253) [ApacheJMeter.jar:5.1.1 r1855137]Caused by: java.net.BindException: 地址已在使用 (Bind failed)        at java.net.PlainSocketImpl.socketBind(Native Method) ~[?:1.8.0_171]        at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387) ~[?:1.8.0_171]        at java.net.ServerSocket.bind(ServerSocket.java:375) ~[?:1.8.0_171]        at java.net.ServerSocket.<init>(ServerSocket.java:237) ~[?:1.8.0_171]        at java.net.ServerSocket.<init>(ServerSocket.java:128) ~[?:1.8.0_171]        at sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMIDirectSocketFactory.java:45) ~[?:1.8.0_171]        at sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMIMasterSocketFactory.java:345) ~[?:1.8.0_171]        at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666) ~[?:1.8.0_171]        at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335) ~[?:1.8.0_171]

非常不幸呀，60001端口被占用，说明已经有别的压测任务在使用这个端口，这就是最大的矛盾点，在防火墙或docker下，我们要固定端口，可是固定了端口，就避免不了冲突，所以在这种情况下，我们就老老实实等前面的任务结束了，再去跑第二个压测任务。当然还有别的办法，每启一个压测任务就换一个端口（在防火墙下比较麻烦），或是采用jmeter的api模式压测，也就是我们的jmeter性能压测平台，当然更好的方式就是抛弃RMI方式，别用jmeter-server了（毕竟用jmeter slave服务总是避免不了要面对端口独占的问题），可以用MeterSphere模式（关于MeterSphere的架构理解，可以参考我的另一篇文章关于MeterSphere的性能测试架构理解_smooth-z的博客-CSDN博客_metersphere）

情况三：Slave压测引擎忙（多任务争用同一个节点）

这种情况很普遍，其实就是RMI的特性，1099端口毕竟是一个jmeter-server进程独占的，如果一个host只启一个jmeter-server，一个任务占用了一个hostname:1099，另一个任务如果也调用，就冲突了，slave端的jmeter-server.log日志能看出拒绝连接：

Using local port: 1099Created remote object: UnicastServerRef2 [liveRef: [endpoint:[192.168.0.154:1099](local),objID:[10d35633:17857843dfe:-7fff, -8945685160021410107]]]Starting the test on host 192.168.0.154:1099 @ Mon Mar 22 09:22:36 CST 2021 (1616376156692)java.rmi.ConnectException: Connection refused to host: 192.168.0.182; nested exception is:         java.net.ConnectException: 连接超时 (Connection timed out)        at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)        at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)        at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:129)        at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)        at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)        at com.sun.proxy.$Proxy20.threadStarted(Unknown Source)        at org.apache.jmeter.threads.JMeterThread.threadStarted(JMeterThread.java:727)        at org.apache.jmeter.threads.JMeterThread.initRun(JMeterThread.java:719)        at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:250)        at java.lang.Thread.run(Thread.java:748)

压测客户端master的jmeter.log日志能看出压测引擎忙的报错：

2021-03-25 08:42:27,462 INFO o.a.j.s.DataStrippingSampleSender: Using DataStrippingSampleSender for this run2021-03-25 08:46:41,936 ERROR o.a.j.e.ClientJMeterEngine: Error in rconfigure() method java.lang.IllegalStateException: Engine is busy - please try later        at org.apache.jmeter.engine.RemoteJMeterEngineImpl.rconfigure(RemoteJMeterEngineImpl.java:145) ~[ApacheJMeter_core.jar:5.1.1 r1855137]        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_171]        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_171]        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_171]        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_171]        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357) ~[?:1.8.0_171]        at sun.rmi.transport.Transport$1.run(Transport.java:200) ~[?:1.8.0_171]        at sun.rmi.transport.Transport$1.run(Transport.java:197) ~[?:1.8.0_171]        at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_171]        at sun.rmi.transport.Transport.serviceCall(Transport.java:196) ~[?:1.8.0_171]        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573) ~[?:1.8.0_171]        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835) ~[?:1.8.0_171]        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688) ~[?:1.8.0_171]        at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_171]        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687) ~[?:1.8.0_171]        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_171]        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_171]        at java.lang.Thread.run(Thread.java:748) ~[?:1.8.0_171]        at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283) ~[?:1.8.0_171]        at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260) ~[?:1.8.0_171]        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161) ~[?:1.8.0_171]        at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227) ~[?:1.8.0_171]        at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179) ~[?:1.8.0_171]        at com.sun.proxy.$Proxy19.rconfigure(Unknown Source) ~[?:?]        at org.apache.jmeter.engine.ClientJMeterEngine.runTest(ClientJMeterEngine.java:153) [ApacheJMeter_core.jar:5.1.1 r1855137]        at org.apache.jmeter.engine.DistributedRunner.start(DistributedRunner.java:132) [ApacheJMeter_core.jar:5.1.1 r1855137]        at org.apache.jmeter.engine.DistributedRunner.start(DistributedRunner.java:149) [ApacheJMeter_core.jar:5.1.1 r1855137]        at org.apache.jmeter.JMeter.runNonGui(JMeter.java:1089) [ApacheJMeter_core.jar:5.1.1 r1855137]        at org.apache.jmeter.JMeter.startNonGui(JMeter.java:991) [ApacheJMeter_core.jar:5.1.1 r1855137]        at org.apache.jmeter.JMeter.start(JMeter.java:563) [ApacheJMeter_core.jar:5.1.1 r1855137]        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_171]        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_171]        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_171]        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_171]        at org.apache.jmeter.NewDriver.main(NewDriver.java:253) [ApacheJMeter.jar:5.1.1 r1855137]

这个问题也是jmeter的通病（比如压测任务非正常停止，引擎就不会正常释放，再次调用就忙），但还好jmeter在大多情况下已经能够满足我们的需要，分布式节点就只做分布式压测的事（遇到异常就通通杀进程），多任务测试的事可以交给master/client自己来做，如果还想要做分布式+多任务的活，那就得抛弃目前这种RMI的client-server模式，采用MeterSphere那种模式（参考关于MeterSphere的性能测试架构理解_smooth-z的博客-CSDN博客_metersphere）。

基本上我们搞懂了Jmeter的分布式压测原理，再结合以上的日志分析方法，Jmeter的端口问题就可以很好的解决和回避，不再为这种小事而抓狂了。

本文部分参考如下文章：

本文地址：http://www.longkongtuishu.com/caf54BAFsBlYBDFE.html

标签： #apachecxf2xjar