[jira] [Comment Edited] (TEZ-2917) change some logs from info to debug
[ https://issues.apache.org/jira/browse/TEZ-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14983531#comment-14983531 ] Sergey Shelukhin edited comment on TEZ-2917 at 10/30/15 10:45 PM: -- MRInputLegacy deferring initialization - how is this useful. Another thing btw is that whatever developer can figure out by just looking at config file, metadata, etc., and code should not be on info level. I.e. logging configs and other such things. getContext().getDestinationVertexName() + ": " + "outputFormat=" + outputFormatClassName + ", using newmapreduce API=" + useNewApi - that looks like it could just be figured out from the job and config Using oldApi, MRpartitionerClass= - same Waiting for N... - is just logged many times all the time and it seems extremely situational, when some small piece of code got stuck. Start of the process is already logged, and so is the end (I can restore these back to info) so it doesn't give much information even if it does hang; in 99.99% cases it's just noise. Cleaning up task, Initializing task are extremely situational given the surrounding log lines (i.e. running... is logged at info). I dunno, I don't really care either way, this is based on users' complaints that too much obscure stuff that doesn't matter is getting logged. [~hagleitn] any opinion? was (Author: sershe): MRInputLegacy deferring initialization - how is this useful. Another thing btw is that whatever developer can figure out by just looking at config file, metadata, etc., and code should not be on info level. I.e. logging configs and other such things. getContext().getDestinationVertexName() + ": " + "outputFormat=" + outputFormatClassName + ", using newmapreduce API=" + useNewApi - that looks like it could just be figured out from the job and config Using oldApi, MRpartitionerClass= - same Waiting for N... - is just logged many times all the time and it seems extremely situational, when some small piece of code got stuck. Maybe it can log waiting once. Cleaning up task, Initializing task are extremely situational given the surrounding log lines (i.e. running... is logged at info). I dunno, I don't really care either way, this is based on users' complaints that too much obscure stuff that doesn't matter is getting logged. [~hagleitn] any opinion? > change some logs from info to debug > --- > > Key: TEZ-2917 > URL: https://issues.apache.org/jira/browse/TEZ-2917 > Project: Apache Tez > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: TEZ-2917.patch > > > I've done a highly unscientific summarization of the logs from some random > queries, and will now change some log statements that are the most prevalent > and not extremely useful from info to debug. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEZ-2917) change some logs from info to debug
[ https://issues.apache.org/jira/browse/TEZ-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14983267#comment-14983267 ] Siddharth Seth commented on TEZ-2917: - [~sershe] - there have been a couple other jiras which try cleaning up logs. TEZ-2774, TEZ-2775. Some of these changes are even more aggressive than the ones on that jira. Many of the log lines become useful when things break. A lot of them show up once per task. Some of them though show up multiple times per task - and cause far more noise. Wondering if there's some other way to control these noisy lines. One would be to go and move a large chunk of the logging to TRACE, and move such lines to DEBUG. Another would be to use a cusom LOGGER for such lines - so that they can be turned off via logging configuration when required. > change some logs from info to debug > --- > > Key: TEZ-2917 > URL: https://issues.apache.org/jira/browse/TEZ-2917 > Project: Apache Tez > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: TEZ-2917.patch > > > I've done a highly unscientific summarization of the logs from some random > queries, and will now change some log statements that are the most prevalent > and not extremely useful from info to debug. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TEZ-2921) Tez UI: Show counts of running tasks under a vertex
Sreenath Somarajapuram created TEZ-2921: --- Summary: Tez UI: Show counts of running tasks under a vertex Key: TEZ-2921 URL: https://issues.apache.org/jira/browse/TEZ-2921 Project: Apache Tez Issue Type: Bug Reporter: Sreenath Somarajapuram Show running tasks in All Vertices table, and ensure that its available in Graphical View tooltip. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEZ-2917) change some logs from info to debug
[ https://issues.apache.org/jira/browse/TEZ-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14983531#comment-14983531 ] Sergey Shelukhin commented on TEZ-2917: --- MRInputLegacy deferring initialization - how is this useful. Another thing btw is that whatever developer can figure out by just looking at config file, metadata, etc., and code should not be on info level. I.e. logging configs and other such things. getContext().getDestinationVertexName() + ": " + "outputFormat=" + outputFormatClassName + ", using newmapreduce API=" + useNewApi - that looks like it could just be figured out from the job and config Using oldApi, MRpartitionerClass= - same Waiting for N... - same. It is just logged all the time and it seems extremely situational, when some small piece of code got stuck. Maybe it can log waiting once. Cleaning up task, Initializing task are extremely situational given the surrounding log lines (i.e. running... is logged at info). I dunno, I don't really care either way, this is based on users' complaints that too much obscure stuff that doesn't matter is getting logged. [~hagleitn] any opinion? > change some logs from info to debug > --- > > Key: TEZ-2917 > URL: https://issues.apache.org/jira/browse/TEZ-2917 > Project: Apache Tez > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: TEZ-2917.patch > > > I've done a highly unscientific summarization of the logs from some random > queries, and will now change some log statements that are the most prevalent > and not extremely useful from info to debug. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEZ-2917) change some logs from info to debug
[ https://issues.apache.org/jira/browse/TEZ-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14983591#comment-14983591 ] Siddharth Seth commented on TEZ-2917: - On the stuff the can be picked up from config - that's almost always the case, except it can be difficult to obtain the config for a job in Tez, unless the equivalent text fields have been written to config. After that, it can be retrieved if ATS is running. I don't mind removing some of the simpler lines like Initializing specific input. (That was 3 log lines before 2774/2775). Awaiting initialization - maybe once and on a timer. Cleaned up task includes information about the exit status - so it's more than a "Cleaning up" state transition line. On the others in the Fetcher, Merger etc - they were explicitly retained in TEZ-2775. I'm not going to +1 the removal since obviously there's others who think they need to be kept. Ability to debug gets priority. > change some logs from info to debug > --- > > Key: TEZ-2917 > URL: https://issues.apache.org/jira/browse/TEZ-2917 > Project: Apache Tez > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: TEZ-2917.patch > > > I've done a highly unscientific summarization of the logs from some random > queries, and will now change some log statements that are the most prevalent > and not extremely useful from info to debug. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TEZ-2918) Make progress notifications in IOs
Bikas Saha created TEZ-2918: --- Summary: Make progress notifications in IOs Key: TEZ-2918 URL: https://issues.apache.org/jira/browse/TEZ-2918 Project: Apache Tez Issue Type: Sub-task Reporter: Bikas Saha Assignee: Bikas Saha -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TEZ-2918) Make progress notifications in IOs
[ https://issues.apache.org/jira/browse/TEZ-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bikas Saha updated TEZ-2918: Attachment: TEZ-2918.2.patch Updating patch for test failures > Make progress notifications in IOs > -- > > Key: TEZ-2918 > URL: https://issues.apache.org/jira/browse/TEZ-2918 > Project: Apache Tez > Issue Type: Sub-task >Reporter: Bikas Saha >Assignee: Bikas Saha > Attachments: TEZ-2918.1.patch, TEZ-2918.2.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEZ-704) Tez MapReduce job hangs if setting mapreduce.reduce.cpu.vcores to be 2
[ https://issues.apache.org/jira/browse/TEZ-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14983786#comment-14983786 ] Hitesh Shah commented on TEZ-704: - In the meantime, will also look to see if we can around the bug in YARN by changing Tez. > Tez MapReduce job hangs if setting mapreduce.reduce.cpu.vcores to be 2 > -- > > Key: TEZ-704 > URL: https://issues.apache.org/jira/browse/TEZ-704 > Project: Apache Tez > Issue Type: Bug >Reporter: Zhenxiao Luo >Assignee: Hitesh Shah > > When running Hive on Tez in EMR hadoop districution, which set > mapreduce.reduce.cpu.vcores to be 2 in mapred-site.xml, all MapReduce jobs > get hang, without any progress. > The problem seems like, > Hive On Tez sets mapreduce.reduce.cpu.vcores to 2, so its application > manager asks for a 2 cpu container, but the resource manager could not > allocate a node for it, since all it has are 1 cpu containers. > I saw the same problem when running MapReduce Job on Tez when setting > mapreduce.reduce.cpu.vcores to be 2. > This could be a bug in Tez MapReduce code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEZ-704) Tez MapReduce job hangs if setting mapreduce.reduce.cpu.vcores to be 2
[ https://issues.apache.org/jira/browse/TEZ-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14983781#comment-14983781 ] Hitesh Shah commented on TEZ-704: - Sorry for the delay in looking into this. Looks like this effectively stems from a bug in AMRMClient in YARN which does not do the correct matching depending on what resources are supported i.e. in AMRMClient::getMatchingRequests. Will file a bug for that - YARN-4323 > Tez MapReduce job hangs if setting mapreduce.reduce.cpu.vcores to be 2 > -- > > Key: TEZ-704 > URL: https://issues.apache.org/jira/browse/TEZ-704 > Project: Apache Tez > Issue Type: Bug >Reporter: Zhenxiao Luo >Assignee: Hitesh Shah > > When running Hive on Tez in EMR hadoop districution, which set > mapreduce.reduce.cpu.vcores to be 2 in mapred-site.xml, all MapReduce jobs > get hang, without any progress. > The problem seems like, > Hive On Tez sets mapreduce.reduce.cpu.vcores to 2, so its application > manager asks for a 2 cpu container, but the resource manager could not > allocate a node for it, since all it has are 1 cpu containers. > I saw the same problem when running MapReduce Job on Tez when setting > mapreduce.reduce.cpu.vcores to be 2. > This could be a bug in Tez MapReduce code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TEZ-2919) TestTezClient & TestUnorderedPartitionedKVWriter fails
Jeff Zhang created TEZ-2919:
---
Summary: TestTezClient & TestUnorderedPartitionedKVWriter fails
Key: TEZ-2919
URL: https://issues.apache.org/jira/browse/TEZ-2919
Project: Apache Tez
Issue Type: Bug
Reporter: Jeff Zhang
https://builds.apache.org/job/Tez-Build-Hadoop-2.2/198/testReport/org.apache.tez.runtime.library.common.writers/TestUnorderedPartitionedKVWriter/testSingleSpill_WithPipelinedShuffle_0_/
{noformat}
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.tez.runtime.library.common.writers.TestUnorderedPartitionedKVWriter.baseTestWithPipelinedTransfer(TestUnorderedPartitionedKVWriter.java:503)
at
org.apache.tez.runtime.library.common.writers.TestUnorderedPartitionedKVWriter.testSingleSpill_WithPipelinedShuffle(TestUnorderedPartitionedKVWriter.java:414)
{noformat}
https://builds.apache.org/job/Tez-Build/1295/testReport/org.apache.tez.client/TestTezClient/testStopRetriesUntilTimeout/
{noformat}
Stacktrace
java.lang.Exception: test timed out after 5000 milliseconds
at java.lang.Thread.sleep(Native Method)
at org.apache.tez.client.TezClient.stop(TezClient.java:589)
at
org.apache.tez.client.TestTezClient.testStopRetriesUntilTimeout(TestTezClient.java:557)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TEZ-2920) org.apache.tez.client.TestTezClient.testStopRetriesUntilTimeout is flaky
Hitesh Shah created TEZ-2920: Summary: org.apache.tez.client.TestTezClient.testStopRetriesUntilTimeout is flaky Key: TEZ-2920 URL: https://issues.apache.org/jira/browse/TEZ-2920 Project: Apache Tez Issue Type: Bug Reporter: Hitesh Shah https://builds.apache.org/job/Tez-Build/1295/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TEZ-2920) org.apache.tez.client.TestTezClient.testStopRetriesUntilTimeout is flaky
[ https://issues.apache.org/jira/browse/TEZ-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hitesh Shah updated TEZ-2920: - Priority: Critical (was: Major) > org.apache.tez.client.TestTezClient.testStopRetriesUntilTimeout is flaky > > > Key: TEZ-2920 > URL: https://issues.apache.org/jira/browse/TEZ-2920 > Project: Apache Tez > Issue Type: Bug >Reporter: Hitesh Shah >Priority: Critical > > https://builds.apache.org/job/Tez-Build/1295/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEZ-2917) change some logs from info to debug
[ https://issues.apache.org/jira/browse/TEZ-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14983439#comment-14983439 ] Siddharth Seth commented on TEZ-2917: - Almost all of them. We've been through the same exercise in TEZ-2774 and TEZ-2775. There is value in disabling a lot of these log lines in specific scenarios. However, for regular production runs of potentially long running Tez jobs - leaving them there is useful. Some of the noisier lines were explicitly added back in the previous jiras. > change some logs from info to debug > --- > > Key: TEZ-2917 > URL: https://issues.apache.org/jira/browse/TEZ-2917 > Project: Apache Tez > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: TEZ-2917.patch > > > I've done a highly unscientific summarization of the logs from some random > queries, and will now change some log statements that are the most prevalent > and not extremely useful from info to debug. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TEZ-2916) Show counts of running tasks on the DAG visualization page
[ https://issues.apache.org/jira/browse/TEZ-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sreenath Somarajapuram reassigned TEZ-2916: --- Assignee: Sreenath Somarajapuram > Show counts of running tasks on the DAG visualization page > -- > > Key: TEZ-2916 > URL: https://issues.apache.org/jira/browse/TEZ-2916 > Project: Apache Tez > Issue Type: Improvement >Reporter: Siddharth Seth >Assignee: Sreenath Somarajapuram > > While a DAG is running, it's useful to have task counts for running / total / > complete tasks on the DAG visualization page. This can be used to figure out > dependencies, and which tasks/vertices are blocking others. > As part of this - some indication of which vertices are currently running > will be a useful addition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TEZ-2679) Admin forms of launch env settings
[ https://issues.apache.org/jira/browse/TEZ-2679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Eagles updated TEZ-2679: - Release Note: TEZ-2679 introduced new admin configuration (tez.am.launch.cluster-default.env, tez.task.launch.cluster-default.env) settings. The settings will be merged per environment variable and environment variables specified in both admin setting and user override will merged in the following manner (assuming linux classpath here, but works for other OS's). ./:USER_PATH:ADMIN_PATH > Admin forms of launch env settings > -- > > Key: TEZ-2679 > URL: https://issues.apache.org/jira/browse/TEZ-2679 > Project: Apache Tez > Issue Type: Improvement >Reporter: Jason Lowe >Assignee: Jonathan Eagles > Fix For: 0.7.1, 0.8.2 > > Attachments: TEZ-2679.1.patch, TEZ-2679.2.patch, TEZ-2679.3.patch, > TEZ-2679.4.patch > > > Tez should provide corresponding admin configs for launch env and java opt > settings that can be specified in tez-site.xml by cluster admins. For > example, if users override the launch env settings to setup LD_LIBRARY_PATH > to just reference their libs then we can fail to load the native Hadoop libs. > This is currently mitigated by having Tez rely on the MapReduce admin > properties in many cases, but Tez should provide its own admin settings to > match the Tez-specific non-admin settings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEZ-2918) Make progress notifications in IOs
[
https://issues.apache.org/jira/browse/TEZ-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14983093#comment-14983093
]
TezQA commented on TEZ-2918:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12769815/TEZ-2918.1.patch
against master revision 414258e.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 3.0.1) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in :
org.apache.tez.runtime.library.common.sort.impl.dflt.TestDefaultSorter
org.apache.tez.runtime.library.common.sort.impl.TestPipelinedSorter
Test results:
https://builds.apache.org/job/PreCommit-TEZ-Build/1266//testReport/
Console output: https://builds.apache.org/job/PreCommit-TEZ-Build/1266//console
This message is automatically generated.
> Make progress notifications in IOs
> --
>
> Key: TEZ-2918
> URL: https://issues.apache.org/jira/browse/TEZ-2918
> Project: Apache Tez
> Issue Type: Sub-task
>Reporter: Bikas Saha
>Assignee: Bikas Saha
> Attachments: TEZ-2918.1.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Failed: TEZ-2918 PreCommit Build #1266
Jira: https://issues.apache.org/jira/browse/TEZ-2918
Build: https://builds.apache.org/job/PreCommit-TEZ-Build/1266/
###
## LAST 60 LINES OF THE CONSOLE
###
[...truncated 3120 lines...]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :tez-runtime-library
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12769815/TEZ-2918.1.patch
against master revision 414258e.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 3.0.1) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in :
org.apache.tez.runtime.library.common.sort.impl.dflt.TestDefaultSorter
org.apache.tez.runtime.library.common.sort.impl.TestPipelinedSorter
Test results:
https://builds.apache.org/job/PreCommit-TEZ-Build/1266//testReport/
Console output: https://builds.apache.org/job/PreCommit-TEZ-Build/1266//console
This message is automatically generated.
==
==
Adding comment to Jira.
==
==
Comment added.
d8d49e825ef93088319205dbe570afc63657198c logged out
==
==
Finished build.
==
==
Build step 'Execute shell' marked build as failure
Archiving artifacts
[description-setter] Could not determine description.
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
###
## FAILED TESTS (if any)
##
3 tests failed.
FAILED:
org.apache.tez.runtime.library.common.sort.impl.TestPipelinedSorter.testWithoutPartitionStats
Error Message:
Wanted but not invoked:
outputContext.notifyProgress();
-> at
org.apache.tez.runtime.library.common.sort.impl.TestPipelinedSorter.basicTest(TestPipelinedSorter.java:421)
However, there were other interactions with this mock:
outputContext.getDestinationVertexName();
-> at
org.apache.tez.runtime.library.common.sort.impl.ExternalSorter.(ExternalSorter.java:198)
outputContext.getCounters();
-> at
org.apache.tez.runtime.library.common.sort.impl.ExternalSorter.(ExternalSorter.java:207)
outputContext.getCounters();
-> at
org.apache.tez.runtime.library.common.sort.impl.ExternalSorter.(ExternalSorter.java:208)
outputContext.getCounters();
-> at
org.apache.tez.runtime.library.common.sort.impl.ExternalSorter.(ExternalSorter.java:209)
outputContext.getCounters();
-> at
org.apache.tez.runtime.library.common.sort.impl.ExternalSorter.(ExternalSorter.java:210)
outputContext.getCounters();
-> at
org.apache.tez.runtime.library.common.sort.impl.ExternalSorter.(ExternalSorter.java:211)
outputContext.getCounters();
-> at
org.apache.tez.runtime.library.common.sort.impl.ExternalSorter.(ExternalSorter.java:212)
outputContext.getCounters();
-> at
org.apache.tez.runtime.library.common.sort.impl.ExternalSorter.(ExternalSorter.java:213)
outputContext.getCounters();
-> at
org.apache.tez.runtime.library.common.sort.impl.ExternalSorter.(ExternalSorter.java:214)
outputContext.getCounters();
-> at
org.apache.tez.runtime.library.common.sort.impl.ExternalSorter.(ExternalSorter.java:215)
outputContext.getUniqueIdentifier();
-> at
org.apache.tez.runtime.library.common.TezRuntimeUtils.instantiateTaskOutputManager(TezRuntimeUtils.java:149)
outputContext.getStatisticsReporter();
-> at
org.apache.tez.runtime.library.common.sort.impl.ExternalSorter.(ExternalSorter.java:264)
outputContext.getDestinationVertexName();
-> at
[jira] [Updated] (TEZ-2918) Make progress notifications in IOs
[ https://issues.apache.org/jira/browse/TEZ-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bikas Saha updated TEZ-2918: Attachment: TEZ-2918.1.patch Patch updates IO's to make notifyProgress() API (added in TEZ-808) calls at different places to notify that progress is being made. Different places are where readers and writers transfer KV transfer KV pairs, spills, event generation, sorts, merges. Some places (merge, sorts etc.) have existing updating via progressable objects (which were nullprogressable until now). Changed them to use the new API with a different progressable. [~rajesh.balamohan] [~jlowe] Please review! > Make progress notifications in IOs > -- > > Key: TEZ-2918 > URL: https://issues.apache.org/jira/browse/TEZ-2918 > Project: Apache Tez > Issue Type: Sub-task >Reporter: Bikas Saha >Assignee: Bikas Saha > Attachments: TEZ-2918.1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEZ-2917) change some logs from info to debug
[ https://issues.apache.org/jira/browse/TEZ-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14983419#comment-14983419 ] Sergey Shelukhin commented on TEZ-2917: --- I dunno if it matters how we disable the lines, as long as we do - to debug, you'd still have to reenable them. Many of these lines look like they would only be useful in very narrow debugging scenarios (e.g. ratio calculation details), so I think they belong on debug level. The lines that are useful for general understanding of what is going on are retained (e.g. for task transitions, running and finished, plus unexpected conditions, are info, but stuff like initializing, cleaning up or whatever are debug). Do you have suggestions for which lines to keep at info? > change some logs from info to debug > --- > > Key: TEZ-2917 > URL: https://issues.apache.org/jira/browse/TEZ-2917 > Project: Apache Tez > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: TEZ-2917.patch > > > I've done a highly unscientific summarization of the logs from some random > queries, and will now change some log statements that are the most prevalent > and not extremely useful from info to debug. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TEZ-2921) Tez UI: Show counts of running tasks under a vertex
[ https://issues.apache.org/jira/browse/TEZ-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sreenath Somarajapuram reassigned TEZ-2921: --- Assignee: Sreenath Somarajapuram > Tez UI: Show counts of running tasks under a vertex > --- > > Key: TEZ-2921 > URL: https://issues.apache.org/jira/browse/TEZ-2921 > Project: Apache Tez > Issue Type: Bug >Reporter: Sreenath Somarajapuram >Assignee: Sreenath Somarajapuram > > Show running tasks in All Vertices table, and ensure that its available in > Graphical View tooltip. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
