Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.6.0
    • Component/s: None
    • Labels:
      None
    • Target Version/s:
    • Hadoop Flags:
      Reviewed

      Description

      The Scheduler decides which sub-queue to assign a given Call. It implements a single method getPriorityLevel(Schedulable call) which returns an integer corresponding to the subqueue the FairCallQueue should place the call in.

      The HistoryRpcScheduler is one such implementation which uses the username of each call and determines what % of calls in recent history were made by this user.

      It is configured with a historyLength (how many calls to track) and a list of integer thresholds which determine the boundaries between priority levels.

      For instance, if the scheduler has a historyLength of 8; and priority thresholds of 4,2,1; and saw calls made by these users in order:
      Alice, Bob, Alice, Alice, Bob, Jerry, Alice, Alice

      • Another call by Alice would be placed in queue 3, since she has already made >= 4 calls
      • Another call by Bob would be placed in queue 2, since he has >= 2 but less than 4 calls
      • A call by Carlos would be placed in queue 0, since he has no calls in the history

      Also, some versions of this patch include the concept of a 'service user', which is a user that is always scheduled high-priority. Currently this seems redundant and will probably be removed in later patches, since its not too useful.

      ----------------

      As of now, the current scheduler is the DecayRpcScheduler, which only keeps track of the number of each type of call and decays these counts periodically.

      1. HADOOP-10281.patch
        29 kB
        Chris Li
      2. HADOOP-10281.patch
        31 kB
        Chris Li
      3. HADOOP-10281.patch
        25 kB
        Chris Li
      4. HADOOP-10281.patch
        27 kB
        Chris Li
      5. HADOOP-10281.patch
        27 kB
        Chris Li
      6. HADOOP-10281-preview.patch
        54 kB
        Chris Li

        Issue Links

          Activity

          Hide
          Chris Li added a comment -

          The scheduler assigns schedulables a priority level based the past history of requests.

          It can be configured as follows:

          ipc.8020.history-scheduler.history-length = 1000

          The number of past requests to remember and compare

          ipc.8020.history-scheduler.thresholds = 33, 66

          Dependent on the history-length and the number of priority levels: defines the thresholds that separate each priority level. In this example, we have 3 priority levels and a history length of 100, so we assign thusly:

          • Queue 2 if count > 66
          • Queue 1 if count > 33
          • Queue 0 otherwise
          Show
          Chris Li added a comment - The scheduler assigns schedulables a priority level based the past history of requests. It can be configured as follows: ipc.8020.history-scheduler.history-length = 1000 The number of past requests to remember and compare ipc.8020.history-scheduler.thresholds = 33, 66 Dependent on the history-length and the number of priority levels: defines the thresholds that separate each priority level. In this example, we have 3 priority levels and a history length of 100, so we assign thusly: Queue 2 if count > 66 Queue 1 if count > 33 Queue 0 otherwise
          Hide
          Chris Li added a comment -

          Upload latest version for reference

          Show
          Chris Li added a comment - Upload latest version for reference
          Hide
          Chris Li added a comment -

          The previous version had issues scaling due to the use of ConcurrentLinkedQueue, which has a non-constant time size() call.

          Show
          Chris Li added a comment - The previous version had issues scaling due to the use of ConcurrentLinkedQueue, which has a non-constant time size() call.
          Hide
          Arpit Agarwal added a comment -

          Hi Chris, I assume this is also optional like FairCallQueue.

          High level concerns:

          1. Every call results in history mutation which seems to be overkill. I think we can get away with a sampling approach, where a given call is fed as input to scheduler with a small probability.
          2. Do you guys have any numbers from performance analysis at scale? It seems like the combined changes are adding a few interlocked operations in the call queue path, and indirect locks via use of ConcurrentHashMap. IIUC there are 4 synchronized state updates per call in HistoryRpcScheduler itself. two updates to callHistoryCounts and two updates to callHistory.
          3. There should be a way to age state after a period of inactivity.
          4. I also think we are providing too many configuration knobs with this feature. Hadoop performance tuning is quite complex already and additional settings add administrator and debugging overhead. Perhaps it is better to leave some of these settings non-configurable.

          What do you think?

          If this feature is optional, we can proceed and tune the implementation later if we file a Jira to address the high level issues later.

          1. This comment confused me If there is not enough traffic to flush the callHistory, sporadic users could end up with counts greater than the heartbeats. Which heartbeats does it refer to?
          2. historyLength, serviceUsernames, thresholds, numQueues can be final.
          3. Why do we support multiple identity providers if we discard all but the first?
          4. I agree that service user seems like an unnecessary complication for now. Perhaps we can add it later?
          5. #getSchedulingDecisions - curious why you make a copy of the callHistoryCounts reference.
          6. getDefaultThresholds - is there any analysis behind choosing this bisection approach?
          7. getAndIncrement - I think we do care about the return value of putIfAbsent, because we want to update the local variable value.
          8. popLast - check for return value of poll being null?
          9. Nitpick: Spaces around equals sign in i=retval.length-1. Could you also fix other instances to be inline with our coding convention e.g. (aNumQueues-1)
          Show
          Arpit Agarwal added a comment - Hi Chris, I assume this is also optional like FairCallQueue. High level concerns: Every call results in history mutation which seems to be overkill. I think we can get away with a sampling approach, where a given call is fed as input to scheduler with a small probability. Do you guys have any numbers from performance analysis at scale? It seems like the combined changes are adding a few interlocked operations in the call queue path, and indirect locks via use of ConcurrentHashMap. IIUC there are 4 synchronized state updates per call in HistoryRpcScheduler itself. two updates to callHistoryCounts and two updates to callHistory . There should be a way to age state after a period of inactivity. I also think we are providing too many configuration knobs with this feature. Hadoop performance tuning is quite complex already and additional settings add administrator and debugging overhead. Perhaps it is better to leave some of these settings non-configurable. What do you think? If this feature is optional, we can proceed and tune the implementation later if we file a Jira to address the high level issues later. This comment confused me If there is not enough traffic to flush the callHistory, sporadic users could end up with counts greater than the heartbeats . Which heartbeats does it refer to? historyLength , serviceUsernames , thresholds , numQueues can be final. Why do we support multiple identity providers if we discard all but the first? I agree that service user seems like an unnecessary complication for now. Perhaps we can add it later? #getSchedulingDecisions - curious why you make a copy of the callHistoryCounts reference. getDefaultThresholds - is there any analysis behind choosing this bisection approach? getAndIncrement - I think we do care about the return value of putIfAbsent , because we want to update the local variable value . popLast - check for return value of poll being null? Nitpick: Spaces around equals sign in i=retval.length-1 . Could you also fix other instances to be inline with our coding convention e.g. (aNumQueues-1)
          Hide
          Chris Li added a comment -

          Hi Arpit,

          I agree on #1; I've had this idea sitting around in my head for awhile too, of having just a map of counts that decays every few seconds. I will try this out and see how performance compares.

          HADOOP-10286 allows performance to be measured for different user loads in the RPCCallBenchmark, so I will use that to benchmark perf hit.

          Other:

          If there is not enough traffic to flush the callHistory, sporadic users could end up with counts greater than the heartbeats

          What can happen is, if I'm the only user on the cluster and I make a call every second, I shouldn't be punished because I'm not hitting the NN hard. However, over 1000 seconds, I will fill up the callHistory, thus being placed in low priority. Heartbeats from datanodes will be placed in a higher queue than me, and now I'm being punished.

          This issue is fixed if we add a decay constant and make it dependent on time.

          I also think we are providing too many configuration knobs with this feature. Hadoop performance tuning is quite complex already and additional settings add administrator and debugging overhead

          Agreed that this is hard to tune, it's still pretty experimental, so we want to be able to adjust these things. From what I understand, Ming Ma has modified the scheduler to make configuration extremely easy for the administrator, who specifies a target queue utilization. The scheduler and mux work together to hit this target.

          is there any analysis behind choosing this bisection approach?"

          Sampling from real-world performance in our clusters shows that the usage tiers between different users is exponential, and so the log(usage) is linear. Some of this data is on the 5th slide here: https://issues.apache.org/jira/secure/attachment/12616864/NN-denial-of-service-updated-plan.pdf (may be hard to see in pie graph form)

          However we've left this configurable since different clusters may have different usage.

          "Why do we support multiple identity providers if we discard all but the first?"

          I found a method `conf.getInstances()` but no `conf.getInstance()`, not sure if it warrants patching Configuration.java

          I've uploaded a new version of the patch with code style fixes, but I'm going to work on using a counting+decay approach for the next patch.

          Show
          Chris Li added a comment - Hi Arpit, I agree on #1; I've had this idea sitting around in my head for awhile too, of having just a map of counts that decays every few seconds. I will try this out and see how performance compares. HADOOP-10286 allows performance to be measured for different user loads in the RPCCallBenchmark, so I will use that to benchmark perf hit. Other: If there is not enough traffic to flush the callHistory, sporadic users could end up with counts greater than the heartbeats What can happen is, if I'm the only user on the cluster and I make a call every second, I shouldn't be punished because I'm not hitting the NN hard. However, over 1000 seconds, I will fill up the callHistory, thus being placed in low priority. Heartbeats from datanodes will be placed in a higher queue than me, and now I'm being punished. This issue is fixed if we add a decay constant and make it dependent on time. I also think we are providing too many configuration knobs with this feature. Hadoop performance tuning is quite complex already and additional settings add administrator and debugging overhead Agreed that this is hard to tune, it's still pretty experimental, so we want to be able to adjust these things. From what I understand, Ming Ma has modified the scheduler to make configuration extremely easy for the administrator, who specifies a target queue utilization. The scheduler and mux work together to hit this target. is there any analysis behind choosing this bisection approach?" Sampling from real-world performance in our clusters shows that the usage tiers between different users is exponential, and so the log(usage) is linear. Some of this data is on the 5th slide here: https://issues.apache.org/jira/secure/attachment/12616864/NN-denial-of-service-updated-plan.pdf (may be hard to see in pie graph form) However we've left this configurable since different clusters may have different usage. "Why do we support multiple identity providers if we discard all but the first?" I found a method `conf.getInstances()` but no `conf.getInstance()`, not sure if it warrants patching Configuration.java I've uploaded a new version of the patch with code style fixes, but I'm going to work on using a counting+decay approach for the next patch.
          Hide
          Chris Li added a comment -

          Hi Arpit Agarwal, I've attached a preview of a new scheduler, the DecayRpcScheduler. This patch contains both schedulers, but presumably the decay scheduler would supplant the historyscheduler in the final patch.

          Performance tests show that the historyscheduler doesn't add statistically significant overhead (on my laptop) compared to both the decayscheduler and no scheduler.

          Next step is to measure performance on a real cluster.

          Show
          Chris Li added a comment - Hi Arpit Agarwal , I've attached a preview of a new scheduler, the DecayRpcScheduler. This patch contains both schedulers, but presumably the decay scheduler would supplant the historyscheduler in the final patch. Performance tests show that the historyscheduler doesn't add statistically significant overhead (on my laptop) compared to both the decayscheduler and no scheduler. Next step is to measure performance on a real cluster.
          Hide
          Arpit Agarwal added a comment - - edited

          Hi Chris Li,

          Thanks for the updated changes! I am basically +1 for the "preview" patch, minus the HistoryRpcScheduler. Is this tested and ready to commit from your side? If so what do you think of just eliminating HistoryRpcScheduler.

          _____

          Just thinking aloud about a possible future optimization (and please don't bother doing it in the same Jira even if it makes sense!). I think we can eliminate the periodic decay timer and perform the decay activity very cheaply in the context of getPriorityLevel in a lazy manner. We would need to store a lastUpdatedTimestamp with each scheduleCacheRef entry, and also a last updated timestamp for the totalCount. Then we could do the following:

          1. If the lastUpdatedTimestamp for the identity's cache entry is greater than the decay period, update lastUpdatedTimestamp for the entry first and multiply the callCounts entry by decayFactor.
          2. If the lastUpdatedTimestamp for the totalCount is greater than the decay period, update both the global timestamp and the timestamp for the corresponding cacheEntry and then divide totalCount by decayFactor
          3. In either case if the time elapsed is greater than some factor n of the decayPeriod, then we can multiply the corresponding count by decayFactor^n.
          4. If either of the two conditions was true, recompute scheduleCacheRef.

          The other advantage is we could use a smaller decayPeriod and a larger decayFactor without increasing timer activity, which should yield a smoother decay curve. The only missing part would be the periodic cleanup of unused identities.

          Show
          Arpit Agarwal added a comment - - edited Hi Chris Li , Thanks for the updated changes! I am basically +1 for the "preview" patch, minus the HistoryRpcScheduler . Is this tested and ready to commit from your side? If so what do you think of just eliminating HistoryRpcScheduler . _____ Just thinking aloud about a possible future optimization (and please don't bother doing it in the same Jira even if it makes sense!). I think we can eliminate the periodic decay timer and perform the decay activity very cheaply in the context of getPriorityLevel in a lazy manner. We would need to store a lastUpdatedTimestamp with each scheduleCacheRef entry, and also a last updated timestamp for the totalCount. Then we could do the following: If the lastUpdatedTimestamp for the identity's cache entry is greater than the decay period, update lastUpdatedTimestamp for the entry first and multiply the callCounts entry by decayFactor . If the lastUpdatedTimestamp for the totalCount is greater than the decay period, update both the global timestamp and the timestamp for the corresponding cacheEntry and then divide totalCount by decayFactor In either case if the time elapsed is greater than some factor n of the decayPeriod , then we can multiply the corresponding count by decayFactor ^n. If either of the two conditions was true, recompute scheduleCacheRef . The other advantage is we could use a smaller decayPeriod and a larger decayFactor without increasing timer activity, which should yield a smoother decay curve. The only missing part would be the periodic cleanup of unused identities .
          Hide
          Lei (Eddy) Xu added a comment -

          Chris Li Thank you for this great work. It looks nice overall. I only have a few minor questions:

          1. Does the latest design abandon the concept of the RPC window (e.g., tracking latest 1000 RPCs)?
          2. With the combination of a relatively larger decayPeriodMillis (i.e., inappropriate settings?), would it be possible that totalCount actually increases for a long time?In this case, when there is a large totalCount (e.g., 1M), it might be difficult to detect a burst traffic (e.g., 800 of the latest 1000 RPCs from the same faulty user)?
          3. Also, would the schedule cache be difficult to detect the same burst above?

          What do you think?

          Show
          Lei (Eddy) Xu added a comment - Chris Li Thank you for this great work. It looks nice overall. I only have a few minor questions: 1. Does the latest design abandon the concept of the RPC window (e.g., tracking latest 1000 RPCs)? 2. With the combination of a relatively larger decayPeriodMillis (i.e., inappropriate settings?), would it be possible that totalCount actually increases for a long time?In this case, when there is a large totalCount (e.g., 1M), it might be difficult to detect a burst traffic (e.g., 800 of the latest 1000 RPCs from the same faulty user)? 3. Also, would the schedule cache be difficult to detect the same burst above? What do you think?
          Hide
          Chris Li added a comment -

          Hey guys, sorry for the delay, was on vacation, and have some stuff to catch up on before I can complete the new benchmarks. I don't think it should be committed until I have benchmarks at scale.

          To answer your questions Eddy:

          1. Yes, the latest design abandons tracking a fixed number of calls and instead tracks all calls over a fixed time period.
          2. Larger decay periods will indeed make it less responsive to burst traffic. totalCount will increase over time, then get decayed along with the counts on each decay sweep. More aggressive decays (longer periods, greater factors) will make recent calls less affected by older calls.
          3. Same, caching will reduce responsiveness to burst traffic. The change Arpit suggested would increase responsiveness, as would eliminating the schedule cache. This might not even make a big difference since it's done on different threads.

          I hope to have benchmarks up next week

          Show
          Chris Li added a comment - Hey guys, sorry for the delay, was on vacation, and have some stuff to catch up on before I can complete the new benchmarks. I don't think it should be committed until I have benchmarks at scale. To answer your questions Eddy: 1. Yes, the latest design abandons tracking a fixed number of calls and instead tracks all calls over a fixed time period. 2. Larger decay periods will indeed make it less responsive to burst traffic. totalCount will increase over time, then get decayed along with the counts on each decay sweep. More aggressive decays (longer periods, greater factors) will make recent calls less affected by older calls. 3. Same, caching will reduce responsiveness to burst traffic. The change Arpit suggested would increase responsiveness, as would eliminating the schedule cache. This might not even make a big difference since it's done on different threads. I hope to have benchmarks up next week
          Hide
          Chris Li added a comment -

          Sorry for the delay, I completed tests at scale and so far have found the decay scheduler to perform as expected.

          Attached is the minority user latency for three different load profiles + at rest (no load). default LinkedBlockingQueue in gray, FairCallQueue in color.

          (At rest)

          Show
          Chris Li added a comment - Sorry for the delay, I completed tests at scale and so far have found the decay scheduler to perform as expected. Attached is the minority user latency for three different load profiles + at rest (no load). default LinkedBlockingQueue in gray, FairCallQueue in color. (At rest)
          Hide
          Chris Li added a comment -

          Also regarding the spikes in above data: spikes are due to GC pauses on the namenode

          Show
          Chris Li added a comment - Also regarding the spikes in above data: spikes are due to GC pauses on the namenode
          Hide
          Arpit Agarwal added a comment -

          Hi Chris Li, trying to understand the graphs. It looks like you did 3 control + 3 measurement runs for each workload. Is that right? What's the difference between the three workloads? Also what was the impact to the majority user latency?

          Do you think this is ready to go in? I am basically still +1 on your last patch so I'd be okay to commit what we have. Given that the feature is off by default I think we can fine tune the implementation later if needed.

          Thanks, Arpit

          Show
          Arpit Agarwal added a comment - Hi Chris Li , trying to understand the graphs. It looks like you did 3 control + 3 measurement runs for each workload. Is that right? What's the difference between the three workloads? Also what was the impact to the majority user latency? Do you think this is ready to go in? I am basically still +1 on your last patch so I'd be okay to commit what we have. Given that the feature is off by default I think we can fine tune the implementation later if needed. Thanks, Arpit
          Hide
          Chris Li added a comment -

          Hi Arpit Agarwal that's correct. It's not very scientific, but it's a sanity check to make sure that the scheduler performs under various loads. The workloads are mapreduce jobs that coordinate to perform a ddos attack on the namenode. Each job runs under 10 users, each job maps to 20 nodes, and spams the namenode using a varying number of threads.

          Rest: No load
          Equal: 100 threads each
          Balanced: 10, 20, 30..., 80, 90, 100 threads respectievly
          Majority: 100, then 1-2 for the rest

          I think this is ready. I will post a patch shortly for CI

          Show
          Chris Li added a comment - Hi Arpit Agarwal that's correct. It's not very scientific, but it's a sanity check to make sure that the scheduler performs under various loads. The workloads are mapreduce jobs that coordinate to perform a ddos attack on the namenode. Each job runs under 10 users, each job maps to 20 nodes, and spams the namenode using a varying number of threads. Rest: No load Equal: 100 threads each Balanced: 10, 20, 30..., 80, 90, 100 threads respectievly Majority: 100, then 1-2 for the rest I think this is ready. I will post a patch shortly for CI
          Hide
          Arpit Agarwal added a comment -

          Thanks Chris. Just curious if you measured the impact to the majority user latency.

          Show
          Arpit Agarwal added a comment - Thanks Chris. Just curious if you measured the impact to the majority user latency.
          Hide
          Chris Li added a comment -

          I didn't record it, but I can if you're interested. I suspect it'll be slightly worse than the minority user's latency in the LinkedBlockingQueue (since the resources have to come from somewhere).

          Show
          Chris Li added a comment - I didn't record it, but I can if you're interested. I suspect it'll be slightly worse than the minority user's latency in the LinkedBlockingQueue (since the resources have to come from somewhere).
          Hide
          Arpit Agarwal added a comment -

          It is probably not worth running the test again just for that.

          Show
          Arpit Agarwal added a comment - It is probably not worth running the test again just for that.
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12661094/HADOOP-10281.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 1 new or modified test files.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. There were no new javadoc warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-common.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4450//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4450//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12661094/HADOOP-10281.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 2.0.3) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-common-project/hadoop-common. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4450//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4450//console This message is automatically generated.
          Hide
          Arpit Agarwal added a comment -

          Hi Chris, could you please add back HADOOP-10281-preview.patch? It's good to have the history of patches intact to diff with what was reviewed earlier.

          The latest patch still contains HistoryRpcSchedulerMXBean.java. I assume we can remove that file now.

          Show
          Arpit Agarwal added a comment - Hi Chris, could you please add back HADOOP-10281 -preview.patch? It's good to have the history of patches intact to diff with what was reviewed earlier. The latest patch still contains HistoryRpcSchedulerMXBean.java. I assume we can remove that file now.
          Hide
          Chris Li added a comment -

          My bad, I didn't want CI picking this file up; here it is again

          Show
          Chris Li added a comment - My bad, I didn't want CI picking this file up; here it is again
          Hide
          Chris Li added a comment -

          Removed the HistoryRpcSchedulerMXBean

          Show
          Chris Li added a comment - Removed the HistoryRpcSchedulerMXBean
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12661317/HADOOP-10281.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 1 new or modified test files.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. There were no new javadoc warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-common.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4458//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4458//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12661317/HADOOP-10281.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 1 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 2.0.3) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-common-project/hadoop-common. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4458//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4458//console This message is automatically generated.
          Hide
          Arpit Agarwal added a comment -

          Thanks Chris, the preview patch was very helpful to review the delta.

          +1 I will commit shortly.

          Show
          Arpit Agarwal added a comment - Thanks Chris, the preview patch was very helpful to review the delta. +1 I will commit shortly.
          Hide
          Arpit Agarwal added a comment -

          Committed to trunk and branch-2.

          Thanks for the contribution Chris Li!

          Show
          Arpit Agarwal added a comment - Committed to trunk and branch-2. Thanks for the contribution Chris Li !
          Hide
          Chris Li added a comment -

          Awesome, thanks Arpit!

          The next stage of this patch is the multilevel queue that ties the scheduler and mux together. This will enable QoS to be actually used: https://issues.apache.org/jira/browse/HADOOP-10282

          Show
          Chris Li added a comment - Awesome, thanks Arpit! The next stage of this patch is the multilevel queue that ties the scheduler and mux together. This will enable QoS to be actually used: https://issues.apache.org/jira/browse/HADOOP-10282
          Hide
          Hudson added a comment -

          FAILURE: Integrated in Hadoop-trunk-Commit #6055 (See https://builds.apache.org/job/Hadoop-trunk-Commit/6055/)
          HADOOP-10281. Create a scheduler, which assigns schedulables a priority level. (Contributed by Chris Li) (arp: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1617643)

          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcScheduler.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcSchedulerMXBean.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RpcScheduler.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestDecayRpcScheduler.java
          Show
          Hudson added a comment - FAILURE: Integrated in Hadoop-trunk-Commit #6055 (See https://builds.apache.org/job/Hadoop-trunk-Commit/6055/ ) HADOOP-10281 . Create a scheduler, which assigns schedulables a priority level. (Contributed by Chris Li) (arp: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1617643 ) /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcScheduler.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcSchedulerMXBean.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RpcScheduler.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestDecayRpcScheduler.java
          Hide
          Hudson added a comment -

          FAILURE: Integrated in Hadoop-Yarn-trunk #644 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/644/)
          HADOOP-10281. Create a scheduler, which assigns schedulables a priority level. (Contributed by Chris Li) (arp: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1617643)

          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcScheduler.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcSchedulerMXBean.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RpcScheduler.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestDecayRpcScheduler.java
          Show
          Hudson added a comment - FAILURE: Integrated in Hadoop-Yarn-trunk #644 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/644/ ) HADOOP-10281 . Create a scheduler, which assigns schedulables a priority level. (Contributed by Chris Li) (arp: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1617643 ) /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcScheduler.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcSchedulerMXBean.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RpcScheduler.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestDecayRpcScheduler.java
          Hide
          Hudson added a comment -

          FAILURE: Integrated in Hadoop-Hdfs-trunk #1836 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1836/)
          HADOOP-10281. Create a scheduler, which assigns schedulables a priority level. (Contributed by Chris Li) (arp: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1617643)

          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcScheduler.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcSchedulerMXBean.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RpcScheduler.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestDecayRpcScheduler.java
          Show
          Hudson added a comment - FAILURE: Integrated in Hadoop-Hdfs-trunk #1836 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1836/ ) HADOOP-10281 . Create a scheduler, which assigns schedulables a priority level. (Contributed by Chris Li) (arp: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1617643 ) /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcScheduler.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcSchedulerMXBean.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RpcScheduler.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestDecayRpcScheduler.java
          Hide
          Hudson added a comment -

          FAILURE: Integrated in Hadoop-Mapreduce-trunk #1862 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1862/)
          HADOOP-10281. Create a scheduler, which assigns schedulables a priority level. (Contributed by Chris Li) (arp: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1617643)

          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcScheduler.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcSchedulerMXBean.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RpcScheduler.java
          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestDecayRpcScheduler.java
          Show
          Hudson added a comment - FAILURE: Integrated in Hadoop-Mapreduce-trunk #1862 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1862/ ) HADOOP-10281 . Create a scheduler, which assigns schedulables a priority level. (Contributed by Chris Li) (arp: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1617643 ) /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcScheduler.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcSchedulerMXBean.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RpcScheduler.java /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestDecayRpcScheduler.java

            People

            • Assignee:
              Chris Li
              Reporter:
              Chris Li
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development