[
https://issues.apache.org/jira/browse/HADOOP-17728?focusedWorklogId=603378&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-603378
]
ASF GitHub Bot logged work on HADOOP-17728:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 28/May/21 02:34
Start Date: 28/May/21 02:34
Worklog Time Spent: 10m
Work Description: yikf edited a comment on pull request #3042:
URL: https://github.com/apache/hadoop/pull/3042#issuecomment-850066415
> anything under a few seconds is potentially taking work from others, and,
as discussed, once the thread is woken up it's going to be able to run through
the entire queue. Which will only happen after a GC event.
>
> So we are worrying about
>
> 1. How long it takes after a GC event for the thread to wake up and
process data
> 2. What is the cost to the rest of the system with the thread waking up
and going back to sleep.
>
> I'm happy with something like a 10s delay from GC to thread live. Make it
a constant, with javadoc etc so everyone understands what and why....
gentle ping @steveloughran @liuml07 Thanks for review
OK, Will we use **10s** as the delay？
If so, I'll update later. I am not familiar with the object that needs to be
collected, we need to consider the rate at which the object will be collected
and then choose an appropriate value
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 603378)
Time Spent: 4h (was: 3h 50m)
> Deadlock in FileSystem StatisticsDataReferenceCleaner cleanUp
> -------------------------------------------------------------
>
> Key: HADOOP-17728
> URL: https://issues.apache.org/jira/browse/HADOOP-17728
> Project: Hadoop Common
> Issue Type: Bug
> Components: fs
> Affects Versions: 3.2.1
> Reporter: yikf
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 4h
> Remaining Estimate: 0h
>
> Cleaner thread will be blocked if we remove reference from ReferenceQueue
> unless the `queue.enqueue` called.
> ----
> As shown below, We call ReferenceQueue.remove() now while cleanUp, Call
> chain as follow：
> *StatisticsDataReferenceCleaner#queue.remove() ->
> ReferenceQueue.remove(0) -> lock.wait(0)*
> But, lock.notifyAll is called when queue.enqueue only, so Cleaner thread
> will be blocked.
>
> ThreadDump:
> {code:java}
> "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f7afc088800
> nid=0x2119 in Object.wait() [0x00007f7b00230000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000c00c2f58> (a java.lang.ref.Reference$Lock)
> at java.lang.Object.wait(Object.java:502)
> at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
> - locked <0x00000000c00c2f58> (a java.lang.ref.Reference$Lock)
> at
> java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
