[
https://issues.apache.org/jira/browse/YARN-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Lowe reassigned YARN-2246:
--------------------------------
Assignee: Devaraj K (was: Jason Lowe)
bq. Do you suggest that we should use the original tracking url directly
instead of proxy url on the web UI?
Not sure if it's always OK to use the raw history tracking URL, as there might
be some setups where the client can reach the RM but can't reach the history
tracking URL directly. However I think it's OK to always have the RM advertise
the original proxy tracking URL (i.e.: http://<rmaddr>/proxy/<appid>) to
clients through its UI. The AM can redefine what that proxy redirects to, but
the RM should never tack on paths to that proxy URI when advertising it. In
other words, clients visiting http://<rmaddr>/proxy<appid> will always reach
the UI (either AM or history), and if the AM and history have properly mirrored
UIs then it should be seamless to transition between the two when the AM
unregisters and redefines the tracking URL to point to the history server.
bq. seamless view between the AM UI and history UI is not possible nowadays.
Correct, but that's MapReduce's fault and not YARN's. If the RM handles the
proxy properly then it should be possible for an app framework to implement a
properly mirrored UI between the AM and the history server.
bq. In general, seamless view will still be difficult with the aforementioned
solution between two tracking URLs. For example, tracking URL is
http://t1:p1/a/b first, and I'm visiting the path at http://t1:p1/a/b/x/y/z.
When the tracking URL becomes http://t2:p2/c/d/e, I refresh the package and am
redirected http://t2:p2/c/d/e/a/b/x/y/z. Without mapping between original
tracking url and proxy url, we don't know /a/b is part of tracking url base,
and it shouldn't be carried on.
Not sure I'm following the example because there's no proxy URLs in it. The
client should always be using the proxy URL for this discussion. If I follow
the example correctly, the original tracking URL is http://t1:p1/a/b, and the
proxy URL is rooted there (i.e.: proxy/<appid> -> t1:p1/a/b). So I'm visiting
proxy/<appid>/x/y/z and then the AM unregisters with a new tracking URL of
t2:p2/c/d/e. Then the proxy servlet should redirect that same
proxy/<appid>/x/y/z request to t2:p2/c/d/e/x/y/z which seems correct to me.
It's just taking the path underneath the proxy address (i.e.: everything after
proxy/<appid>) and tacking it on the specified tracking URL. The same subpath
is seen by both the AM and history URIs, assuming a/b is the root of the AM UI
and c/d/e is the root of the history UI (for that app). So it seems this
works as I would expect. Am I missing something?
bq. I have updated the generateProxyUriWithScheme() in the latest patch.
Thanks for updating the patch, Devaraj. I think it looks good, although it
would be nice to have some regression tests to verify that if the app changes
the tracking URL that the proxy URL doesn't update like it used to.
> Job History Link in RM UI is redirecting to the URL which contains Job Id
> twice
> -------------------------------------------------------------------------------
>
> Key: YARN-2246
> URL: https://issues.apache.org/jira/browse/YARN-2246
> Project: Hadoop YARN
> Issue Type: Bug
> Components: webapp
> Reporter: Devaraj K
> Assignee: Devaraj K
> Fix For: 2.7.0
>
> Attachments: MAPREDUCE-4064-1.patch, MAPREDUCE-4064.patch,
> YARN-2246-3.patch, YARN-2246.2.patch, YARN-2246.patch
>
>
> {code:xml}
> http://xx.x.x.x:19888/jobhistory/job/job_1332435449546_0001/jobhistory/job/job_1332435449546_0001
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
