jeromq
jeromq copied to clipboard
Why "reaper-1" Thread keeps occupying highly CPU ?
My zmq application's "reaper-1" thread cost most cpu, so it makes the work thread send messages very slowly.
jeromq version: 0.43
java version: 1.8.0_112

java version: 1.8.0_112.
That's Old. Do you have failling network connections ? With a lot of new TCP connexions created and closed ? That might happens when using Curve security
Hi ZMQ team we encounter the same issuse, and use "jstack" command repeatly, can get the following two stack info :
"reaper-1" #12741 daemon prio=5 os_prio=0 tid=0x00007f38580c0000 nid=0x5fb5 runnable [0x00007f37a90e3000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.FileDispatcherImpl.read(FileDispatcherImpl.java:46)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:197)
at sun.nio.ch.SourceChannelImpl.read(SourceChannelImpl.java:167)
- locked <0x00000000d305be20> (a java.lang.Object)
at zmq.Signaler.recv(Signaler.java:165)
at zmq.Mailbox.recv(Mailbox.java:97)
at zmq.SocketBase.processCommands(SocketBase.java:937)
at zmq.SocketBase.inEvent(SocketBase.java:1065)
at zmq.poll.Poller.run(Poller.java:273)
at java.lang.Thread.run(Thread.java:748)
and
"reaper-1" #12741 daemon prio=5 os_prio=0 tid=0x00007f38580c0000 nid=0x5fb5 runnable [0x00007f37a90e3000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.NativeThread.current(Native Method)
at sun.nio.ch.SourceChannelImpl.read(SourceChannelImpl.java:165)
- locked <0x00000000d305be20> (a java.lang.Object)
at zmq.Signaler.recv(Signaler.java:165)
at zmq.Mailbox.recv(Mailbox.java:97)
at zmq.SocketBase.processCommands(SocketBase.java:937)
at zmq.SocketBase.inEvent(SocketBase.java:1065)
at zmq.poll.Poller.run(Poller.java:273)
at java.lang.Thread.run(Thread.java:748)
and I do find the “while(true)” in Reaper.inEvent() method, but I don't know why it happened? and I found the similar issue: https://github.com/zeromq/jeromq/issues/172; but no resolve
我也遇到这个情况,并且解决了,原因是ZMQ.socket被多线程操作了,你检查一下是否有类似使用场景。 I also encountered this situation and solved it because ZMQ.socket is operated by multiple threads. Check whether there are similar scenarios.
我也遇到这个情况,并且解决了,原因是ZMQ.socket被多线程操作了,你检查一下是否有类似使用场景。 I also encountered this situation and solved it because ZMQ.socket is operated by multiple threads. Check whether there are similar scenarios.
内部hashmap多线程死循环了?? HashMap in multithread access causes infinite loop?
What do you espect us to do with comments not written in english ?