You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ratis.apache.org by "Mario Georgiev (Jira)" <ji...@apache.org> on 2021/03/05 18:32:00 UTC
[jira] [Comment Edited] (RATIS-1329) Doing RaftServer.close() hangs
up the process
[ https://issues.apache.org/jira/browse/RATIS-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17296261#comment-17296261 ]
Mario Georgiev edited comment on RATIS-1329 at 3/5/21, 6:31 PM:
----------------------------------------------------------------
This is from the GRPC example.
A little more on this:
There are 2 non daemon threads (Other than DestroyJavaVM) that are waiting, apparently forever in this case:
{code:java}
java.util.concurrent.ThreadPoolExecutor$Worker@2d7a4ed[State = -1, empty queue]@4731STATE :WAITING
stackTrace:
java.lang.Thread.State: WAITING
at jdk.internal.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1661)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1182)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1056)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1116)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.lang.Thread.run(Thread.java:832)
{code}
{code:java}
"s3@group-D578C33A89C8-SegmentedRaftLogWorker@5147" prio=5 tid=0x183 nid=NA waiting"s3@group-D578C33A89C8-SegmentedRaftLogWorker@5147" prio=5 tid=0x183 nid=NA waiting java.lang.Thread.State: WAITING at jdk.internal.misc.Unsafe.park(Unsafe.java:-1) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1661) at org.apache.ratis.util.DataBlockingQueue.poll(DataBlockingQueue.java:137) at org.apache.ratis.server.raftlog.segmented.SegmentedRaftLogWorker.run(SegmentedRaftLogWorker.java:293) at java.lang.Thread.run(Thread.java:832)
{code}
was (Author: despondency):
A little more on this:
There are 2 non daemon threads (Other than DestroyJavaVM) that are waiting, apparently forever in this case:
{code:java}
java.util.concurrent.ThreadPoolExecutor$Worker@2d7a4ed[State = -1, empty queue]@4731STATE :WAITING
stackTrace:
java.lang.Thread.State: WAITING
at jdk.internal.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1661)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1182)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1056)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1116)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.lang.Thread.run(Thread.java:832)
{code}
{code:java}
"s3@group-D578C33A89C8-SegmentedRaftLogWorker@5147" prio=5 tid=0x183 nid=NA waiting"s3@group-D578C33A89C8-SegmentedRaftLogWorker@5147" prio=5 tid=0x183 nid=NA waiting java.lang.Thread.State: WAITING at jdk.internal.misc.Unsafe.park(Unsafe.java:-1) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1661) at org.apache.ratis.util.DataBlockingQueue.poll(DataBlockingQueue.java:137) at org.apache.ratis.server.raftlog.segmented.SegmentedRaftLogWorker.run(SegmentedRaftLogWorker.java:293) at java.lang.Thread.run(Thread.java:832)
{code}
> Doing RaftServer.close() hangs up the process
> ---------------------------------------------
>
> Key: RATIS-1329
> URL: https://issues.apache.org/jira/browse/RATIS-1329
> Project: Ratis
> Issue Type: Bug
> Affects Versions: 1.0.0
> Reporter: Mario Georgiev
> Priority: Major
> Attachments: ratis-grpc-hangup-on-close-grpc-jstack.txt, ratis-grpc-hangup-on-close.zip, ratis-netty-hangup-on-close-netty-jstack.txt, ratis-netty-hangup-on-close.zip
>
>
> Build the jar with
> {code:java}
> ./gradlew uber
> navigate to the build/libs/ and run the uber java -jar <jar-name-uber>
> {code}
> Initially thought it only happens on Netty, but switched to GRPC and same thing.
> Issue is both on Netty && GRPC, you might have to run the jar a few times to get the hang up. (attached jstack for both of the reproducible test cases)
> Am i doing something incorrect in the code, or its just a bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)