[jira] [Commented] (TEZ-3470) Tez UI: Make the build work in IBM PPC
[ https://issues.apache.org/jira/browse/TEZ-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15653260#comment-15653260 ] Ayappan commented on TEZ-3470: -- Is this happening on a x86 machine or PPC machine ? > Tez UI: Make the build work in IBM PPC > -- > > Key: TEZ-3470 > URL: https://issues.apache.org/jira/browse/TEZ-3470 > Project: Apache Tez > Issue Type: Bug >Affects Versions: 0.8.3 >Reporter: Sreenath Somarajapuram >Assignee: Sreenath Somarajapuram > Labels: TezUI > Fix For: 0.9.0 > > Attachments: TEZ-3470.1.patch, TEZ-3470.2.patch, TEZ-3470.3.patch, > TEZ-3470.4.patch, TEZ-3470.wip.1.patch > > > Current versions of frontend-maven-plugin, node & npm used by the build is > not functioning as expected in IBM PPC. Following version works, and the > build must be changed to used the same in a PPC. > - frontend-maven-plugin : v1.1 > - node : v5.7.0 > - npm : 3.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEZ-3534) Differentiate thread names on Fetchers, minor changes to shuffle shutdown code
[
https://issues.apache.org/jira/browse/TEZ-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15652818#comment-15652818
]
TezQA commented on TEZ-3534:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12838269/TEZ-3534.02.patch
against master revision 4b62875.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 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 following test timeouts occurred in :
org.apache.tez.test.TestRecovery
Test results:
https://builds.apache.org/job/PreCommit-TEZ-Build/2100//testReport/
Console output: https://builds.apache.org/job/PreCommit-TEZ-Build/2100//console
This message is automatically generated.
> Differentiate thread names on Fetchers, minor changes to shuffle shutdown code
> --
>
> Key: TEZ-3534
> URL: https://issues.apache.org/jira/browse/TEZ-3534
> Project: Apache Tez
> Issue Type: Task
>Reporter: Siddharth Seth
>Assignee: Siddharth Seth
> Attachments: TEZ-3534.01.patch, TEZ-3534.02.patch
>
>
> Follow up to https://issues.apache.org/jira/browse/TEZ-3533.
> Adding some exception checks during shutdown could help with ensuring all
> components shutdown, in case there is a failure from a previous one.
> Rename threads is to make it easier to debug from stacktraces.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Failed: TEZ-3534 PreCommit Build #2100
Jira: https://issues.apache.org/jira/browse/TEZ-3534
Build: https://builds.apache.org/job/PreCommit-TEZ-Build/2100/
###
## LAST 60 LINES OF THE CONSOLE
###
[...truncated 4602 lines...]
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :tez-tests
[INFO] Build failures were ignored.
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12838269/TEZ-3534.02.patch
against master revision 4b62875.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 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 following test timeouts occurred in :
org.apache.tez.test.TestRecovery
Test results:
https://builds.apache.org/job/PreCommit-TEZ-Build/2100//testReport/
Console output: https://builds.apache.org/job/PreCommit-TEZ-Build/2100//console
This message is automatically generated.
==
==
Adding comment to Jira.
==
==
Comment added.
c38be0c212b9f01fdd3c4d09f8eb933b94681ed9 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)
##
All tests passed
[jira] [Commented] (TEZ-1190) Allow multiple edges between two vertices
[ https://issues.apache.org/jira/browse/TEZ-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15652811#comment-15652811 ] Bikas Saha commented on TEZ-1190: - How is the restriction of either all named or unnamed helpful? How about an implementation approach where all implicit behavior is removed in the core layer. And edges are always named. In the DAGClient layer, the new API will provide the name or for backwards compatibility the DAGClient layer will auto-generate uniqueNames (e.g. SourceDestinationCounter). Thus the implicit existing behaviors is limited to the DAGClient layer. Similarly for plugins/contexts, we could add a new API with the edge name semantics instead of overloading the semantics because both parameters (sourceName or edgeName) are string. And we could deprecate the existing semantic API that uses vertex names. A translation layer could handle the implicit conversion of vertexName to auto-generated names produced by the DAGClient. The reason I suggest changing the internal core layer to always use edge names and keep the compatibility handling to the API layers is that might be cleaner cut of the code. And reduce the number of bugs left behind due to missed cases of implicit use. By continuing to support implicit names internally we may increase the surface area of such leaks. Rest looks good to me for now. Nice job with capturing the cases! Of course the devil is in the details :) BTW, the doc implicitly assumes that the dummy vertex approach is being dropped in favor of the named edge approach? > Allow multiple edges between two vertices > - > > Key: TEZ-1190 > URL: https://issues.apache.org/jira/browse/TEZ-1190 > Project: Apache Tez > Issue Type: Bug >Reporter: Daniel Dai >Assignee: Zhiyuan Yang > Attachments: NamedEdgeDesign.pdf, TEZ-1190.prototype.patch > > > This will be helpful in some scenario. In particular example, we can merge > two small pipelines together in one pair of vertex. Note it is possible the > edge type between the two vertexes are different. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEZ-3509) Make DAG Deletion path based
[
https://issues.apache.org/jira/browse/TEZ-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15652777#comment-15652777
]
Siddharth Seth commented on TEZ-3509:
-
We may be better of relying on the ShuffleHandler accepting the parameter on
dag vs vertex delete, instead of a path. I can't see a case where we want to go
more granular than that. Path level starts exposing a lot of information, which
can otherwise be avoided, in the container launcher.
e.g. a call to the shuffle handler saying
dagDelete?action=delete=jobId=dagId
vertexDelete?action=delete=jobId=dagId=vertexId
The ShuffleHandler has all the relevant information, and context available to
delete the necessary files.
If going with the path route, have to make sure that no absolute paths are sent
in. The paths in fact should be a localized directory for the app (i.e. I
should not be able to delete local resources used by the app using this
invocation).
In terms of the patch - mostly looks good. There's some access to private
members of the Tracker class. That should be changed to methods (node
registration).
I think there was mentioned of pluggability of this piece at some point. The
ContainerLauncher can be shared by entities which use different
ShuffleHandlers. e.g. If the MR ShuffleHandler were to be enhanced to support
deletes, deletion would not work since it is tied to the new Tez
ShuffleHandler. Making the entire DeletionTracker pluggable - with config
coming in via the ContainerLauncher payload would help with this. tez-dag
ideally should not be referencing the tez-runtime-library module. That's in
place today because of some stuff in the ShuffleHandler, and can be broken by
moving the VertexManager implementations out of tez-dag. Referencing
ShuffleHandler directly brings in one more dependency from tez-dag to
tez-runtime-library.
Unrelated to this specific patch.
The model used for dagComplete notifications is to only pass in the dagId. Dag
info is supposed to be picked up from the getDagInfo method in
{TaskCommunicator|ContainerLauncher}Context. At the moment, the entire DAG is
exposed.
> Make DAG Deletion path based
>
>
> Key: TEZ-3509
> URL: https://issues.apache.org/jira/browse/TEZ-3509
> Project: Apache Tez
> Issue Type: Sub-task
>Reporter: Kuhu Shukla
>Assignee: Kuhu Shukla
> Attachments: TEZ-3509.001.patch
>
>
> The idea here is to have the API take a path to delete, be it DAG path today
> or a vertex level path later on. The current implementation takes a flag
> which is specific to DAG deletion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TEZ-3269) Provide basic fair routing and scheduling functionality via custom VertexManager and EdgeManager
[ https://issues.apache.org/jira/browse/TEZ-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15652670#comment-15652670 ] Siddharth Seth commented on TEZ-3269: - +1. Looks good. Thanks [~mingma] > Provide basic fair routing and scheduling functionality via custom > VertexManager and EdgeManager > > > Key: TEZ-3269 > URL: https://issues.apache.org/jira/browse/TEZ-3269 > Project: Apache Tez > Issue Type: Sub-task >Reporter: Ming Ma >Assignee: Ming Ma > Attachments: TEZ-3269-2.patch, TEZ-3269-3.patch, TEZ-3269-4.patch, > TEZ-3269-5.patch, TEZ-3269.patch > > > With TEZ-3206 and TEZ-3216, we can build a custom VertexManager and > EdgeManager that uses partition stats to do fair routing as well as the > scheduling based on destination tasks’ dependency on source tasks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEZ-3534) Differentiate thread names on Fetchers, minor changes to shuffle shutdown code
[
https://issues.apache.org/jira/browse/TEZ-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15652624#comment-15652624
]
Rajesh Balamohan commented on TEZ-3534:
---
Minor: plz fix {{Failed log prgress while closing}} in {{ShuffleScheduler}}
before committing
Rest LGTM. +1. Thanks [~sseth].
> Differentiate thread names on Fetchers, minor changes to shuffle shutdown code
> --
>
> Key: TEZ-3534
> URL: https://issues.apache.org/jira/browse/TEZ-3534
> Project: Apache Tez
> Issue Type: Task
>Reporter: Siddharth Seth
>Assignee: Siddharth Seth
> Attachments: TEZ-3534.01.patch, TEZ-3534.02.patch
>
>
> Follow up to https://issues.apache.org/jira/browse/TEZ-3533.
> Adding some exception checks during shutdown could help with ensuring all
> components shutdown, in case there is a failure from a previous one.
> Rename threads is to make it easier to debug from stacktraces.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TEZ-3491) Tez job can hang due to container priority inversion
[ https://issues.apache.org/jira/browse/TEZ-3491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15652613#comment-15652613 ] Siddharth Seth commented on TEZ-3491: - [~jlowe] - the patch looks good to me. +1. Like you pointed out, it's not ideal to wait for timeouts and then make container requests again. What scenario led to this situation. YARN ended up handing out a lower priority ask before a higher priority ask?, or did the AM decide to release containers that it had obtained at a higher priority, or multiple DAGs in the same AM? You had mentioned an alternate approach / potential improvement to solve the same problem in an offline discussion. Have a little more context after looking at the code again. Would be useful if you could add some notes about that on the jira. For sessions, where containers can be used across multiple DAGs - I think the logic of avoiding lower priority container for a higher priority task because of the risk of 'polluting' the container goes for a toss. The held containers could be at any priority level. Maybe we should have a mode where the container priority check is not enforced. This would work for most submissions. It'll be problematic if the same file, same jar or conflicting jars are specified as LRs for different Vertices / DAGs. > Tez job can hang due to container priority inversion > > > Key: TEZ-3491 > URL: https://issues.apache.org/jira/browse/TEZ-3491 > Project: Apache Tez > Issue Type: Bug >Affects Versions: 0.7.1 >Reporter: Jason Lowe >Assignee: Jason Lowe >Priority: Critical > Attachments: TEZ-3491.001.patch > > > If the Tez AM receives containers at a lower priority than the highest > priority task being requested then it fails to assign the container to any > task. In addition if the container is new then it refuses to release it if > there are any pending tasks. If it takes too long for the higher priority > requests to be fulfilled (e.g.: the lower priority containers are filling the > queue) then eventually YARN will expire the unused lower priority containers > since they were never launched. The Tez AM then never re-requests these > lower priority containers and the job hangs because the AM is waiting for > containers from the RM that the RM already sent and expired. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Failed: TEZ-3534 PreCommit Build #2099
Jira: https://issues.apache.org/jira/browse/TEZ-3534
Build: https://builds.apache.org/job/PreCommit-TEZ-Build/2099/
###
## LAST 60 LINES OF THE CONSOLE
###
[...truncated 86 lines...]
patching file
tez-runtime-library/src/main/java/org/apache/tez/runtime/library/common/shuffle/orderedgrouped/Shuffle.java
patching file
tez-runtime-library/src/main/java/org/apache/tez/runtime/library/common/shuffle/orderedgrouped/ShuffleScheduler.java
==
==
Determining number of patched javac warnings.
==
==
/home/jenkins/tools/maven/latest/bin/mvn clean test -DskipTests -Ptest-patch >
/home/jenkins/jenkins-slave/workspace/PreCommit-TEZ-Build/../patchprocess/patchJavacWarnings.txt
2>&1
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12838256/TEZ-3534.01.patch
against master revision 4b62875.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:red}-1 javac{color:red}. The patch appears to cause the build to
fail.
Console output: https://builds.apache.org/job/PreCommit-TEZ-Build/2099//console
This message is automatically generated.
==
==
Adding comment to Jira.
==
==
Comment added.
3cd178d5fe0aefb871a29952ad264d6c0fee38b5 logged out
==
==
Finished build.
==
==
Build step 'Execute shell' marked build as failure
Archiving artifacts
Compressed 806.57 KB of artifacts by 39.7% relative to #2096
[description-setter] Could not determine description.
Recording test results
ERROR: Step ?Publish JUnit test result report? failed: No test report files
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
###
## FAILED TESTS (if any)
##
No tests ran.
[jira] [Commented] (TEZ-3534) Differentiate thread names on Fetchers, minor changes to shuffle shutdown code
[
https://issues.apache.org/jira/browse/TEZ-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15652435#comment-15652435
]
TezQA commented on TEZ-3534:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12838256/TEZ-3534.01.patch
against master revision 4b62875.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:red}-1 javac{color:red}. The patch appears to cause the build to
fail.
Console output: https://builds.apache.org/job/PreCommit-TEZ-Build/2099//console
This message is automatically generated.
> Differentiate thread names on Fetchers, minor changes to shuffle shutdown code
> --
>
> Key: TEZ-3534
> URL: https://issues.apache.org/jira/browse/TEZ-3534
> Project: Apache Tez
> Issue Type: Task
>Reporter: Siddharth Seth
>Assignee: Siddharth Seth
> Attachments: TEZ-3534.01.patch
>
>
> Follow up to https://issues.apache.org/jira/browse/TEZ-3533.
> Adding some exception checks during shutdown could help with ensuring all
> components shutdown, in case there is a failure from a previous one.
> Rename threads is to make it easier to debug from stacktraces.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TEZ-3534) Differentiate thread names on Fetchers, minor changes to shuffle shutdown code
[ https://issues.apache.org/jira/browse/TEZ-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddharth Seth updated TEZ-3534: Attachment: TEZ-3534.01.patch Trivial patch. [~rajesh.balamohan] - could you please take a look. > Differentiate thread names on Fetchers, minor changes to shuffle shutdown code > -- > > Key: TEZ-3534 > URL: https://issues.apache.org/jira/browse/TEZ-3534 > Project: Apache Tez > Issue Type: Task >Reporter: Siddharth Seth >Assignee: Siddharth Seth > Attachments: TEZ-3534.01.patch > > > Follow up to https://issues.apache.org/jira/browse/TEZ-3533. > Adding some exception checks during shutdown could help with ensuring all > components shutdown, in case there is a failure from a previous one. > Rename threads is to make it easier to debug from stacktraces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TEZ-3534) Differentiate thread names on Fetchers, minor changes to shuffle shutdown code
Siddharth Seth created TEZ-3534: --- Summary: Differentiate thread names on Fetchers, minor changes to shuffle shutdown code Key: TEZ-3534 URL: https://issues.apache.org/jira/browse/TEZ-3534 Project: Apache Tez Issue Type: Task Reporter: Siddharth Seth Assignee: Siddharth Seth Attachments: TEZ-3534.01.patch Follow up to https://issues.apache.org/jira/browse/TEZ-3533. Adding some exception checks during shutdown could help with ensuring all components shutdown, in case there is a failure from a previous one. Rename threads is to make it easier to debug from stacktraces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEZ-3470) Tez UI: Make the build work in IBM PPC
[
https://issues.apache.org/jira/browse/TEZ-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15652317#comment-15652317
]
Jonathan Eagles commented on TEZ-3470:
--
[~Sreenath], getting an error on RHEL6 with this patch applied. Any ideas?
{code}
22:29:08 [INFO] PhantomJS not found on PATH
22:29:08 [INFO] Downloading
https://github.com/Medium/phantomjs/releases/download/v2.1.1/phantomjs-2.1.1-linux-x86_64.tar.bz2
22:29:08 [INFO] Saving to /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2
22:29:08 [INFO] Receiving...
22:29:12 [INFO]
22:29:12 [INFO] Received 22866K total.
22:29:12 [INFO] Extracting tar contents (via spawned process)
22:29:15 [INFO] Removing
/var/builds/workspace/151597-v3-component/BUILD_CONTAINER/rhel6/label/DOCKER-LOW/app_root/tez-ui/src/main/webapp/node_modules/phantomjs-prebuilt/lib/phantom
22:29:15 [INFO] Copying extracted folder
/tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2-extract-1478730552798/phantomjs-2.1.1-linux-x86_64
->
/var/builds/workspace/151597-v3-component/BUILD_CONTAINER/rhel6/label/DOCKER-LOW/app_root/tez-ui/src/main/webapp/node_modules/phantomjs-prebuilt/lib/phantom
22:29:15 [INFO] Writing location.js file
22:29:15 [INFO] Done. Phantomjs binary available at
/var/builds/workspace/151597-v3-component/BUILD_CONTAINER/rhel6/label/DOCKER-LOW/app_root/tez-ui/src/main/webapp/node_modules/phantomjs-prebuilt/lib/phantom/bin/phantomjs
...
22:29:53 > TMPDIR=tmp node/node ./node_modules/ember-cli/bin/ember test
...
22:30:19 not ok 1 Error
22:30:19 ---
22:30:19 message: >
22:30:19 Launcher PhantomJS not found. Not installed?
22:30:19 ...
22:30:19
22:30:19 1..1
22:30:19 # tests 1
22:30:19 # pass 0
22:30:19 # skip 0
22:30:19 # fail 1
{code}
> Tez UI: Make the build work in IBM PPC
> --
>
> Key: TEZ-3470
> URL: https://issues.apache.org/jira/browse/TEZ-3470
> Project: Apache Tez
> Issue Type: Bug
>Affects Versions: 0.8.3
>Reporter: Sreenath Somarajapuram
>Assignee: Sreenath Somarajapuram
> Labels: TezUI
> Fix For: 0.9.0
>
> Attachments: TEZ-3470.1.patch, TEZ-3470.2.patch, TEZ-3470.3.patch,
> TEZ-3470.4.patch, TEZ-3470.wip.1.patch
>
>
> Current versions of frontend-maven-plugin, node & npm used by the build is
> not functioning as expected in IBM PPC. Following version works, and the
> build must be changed to used the same in a PPC.
> - frontend-maven-plugin : v1.1
> - node : v5.7.0
> - npm : 3.6.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TEZ-3488) Tez UI Vertex 404
[ https://issues.apache.org/jira/browse/TEZ-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15651720#comment-15651720 ] Jonathan Eagles commented on TEZ-3488: -- Leaving withCredentials is preferred since there is a movement to consider moving credentials into the request headers since passing credentials as part of the URL is a security concern. This will allow the Tez UI to be protected from this design change. > Tez UI Vertex 404 > - > > Key: TEZ-3488 > URL: https://issues.apache.org/jira/browse/TEZ-3488 > Project: Apache Tez > Issue Type: Bug >Affects Versions: 0.8.4 >Reporter: George Liaw > > When we're trying to view vertices for a running job, the Vertex page will > show a 404 error saying: > "Could not retrieve expected data from @ " > And the Vertex Counter page will show: > "Counters unavailable" > and > "Error code: Unknown, message: Resource Manager (RM) out of reach. Either > it's down or CORS is not enabled" > The RMs are up and CORS is enabled. If we go to the displayed url, we get the > expected XML with the application info. When the DAG finishes running, those > errors go away and the pages display fine. Any idea what's going on here? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEZ-3529) Tez UI: Add 'All Queries' table in the landing page along 'All DAGs' page
[ https://issues.apache.org/jira/browse/TEZ-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15651666#comment-15651666 ] Sreenath Somarajapuram commented on TEZ-3529: - Hi [~hitesh] Was looking at use cases for Tez UI, and realized that majority of our users are from Hive & Pig. So to start with, felt that adding an "All Queries" table would make it easier to debug Hive queries. Later-on we can add one more tab for Pig. The display of these tabs can also be controlled by the availability of the respective entities in timeline server. > Tez UI: Add 'All Queries' table in the landing page along 'All DAGs' page > - > > Key: TEZ-3529 > URL: https://issues.apache.org/jira/browse/TEZ-3529 > Project: Apache Tez > Issue Type: Bug >Reporter: Sreenath Somarajapuram >Assignee: Sreenath Somarajapuram > Attachments: TEZ-3529.1.patch > > > Landing page must have two tabs - All DAGs & All Queries > Following search functionalities must be supported: > - Search for Hive query ID > - Search for user who submitted the query -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEZ-3488) Tez UI Vertex 404
[ https://issues.apache.org/jira/browse/TEZ-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15651151#comment-15651151 ] Sreenath Somarajapuram commented on TEZ-3488: - [~hitesh] I'v improved the above documentation. Please review. Working on the other parts of the doc. bq. Is there any security aspect raised if we use "*" instead of the origin host as currently being done? We cannot use "*" when withCredentials is set to true in the request. As explained here https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Requests_with_credentials, withCredentials is required for making calls that are aware of HTTP cookies and HTTP Authentication information. It was added as part of TEZ-1799. [~jeagles] Considering that we are not sending any credentials as of now in the headers, should we remove the flag for the time being? > Tez UI Vertex 404 > - > > Key: TEZ-3488 > URL: https://issues.apache.org/jira/browse/TEZ-3488 > Project: Apache Tez > Issue Type: Bug >Affects Versions: 0.8.4 >Reporter: George Liaw > > When we're trying to view vertices for a running job, the Vertex page will > show a 404 error saying: > "Could not retrieve expected data from @ " > And the Vertex Counter page will show: > "Counters unavailable" > and > "Error code: Unknown, message: Resource Manager (RM) out of reach. Either > it's down or CORS is not enabled" > The RMs are up and CORS is enabled. If we go to the displayed url, we get the > expected XML with the application info. When the DAG finishes running, those > errors go away and the pages display fine. Any idea what's going on here? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
