Jose Luis López created MAPREDUCE-7547:
------------------------------------------
Summary: HsWebApp should bind App request-scoped instead of
singleton
Key: MAPREDUCE-7547
URL: https://issues.apache.org/jira/browse/MAPREDUCE-7547
Project: Hadoop Map/Reduce
Issue Type: Bug
Components: webapps, jobhistoryserver
Reporter: Jose Luis López
MAPREDUCE-7527 fixed the JobHistoryServer attempts page by binding {{App}} as a
singleton in {{HsWebApp.setup()}}:
{code:java}
bind(App.class).in(Singleton.class);
{code}
{{App}} holds per-request mutable state: {{AppController.requireJob()}} /
{{requireTask()}} (inherited by {{HsController}}) call {{app.setJob(...)}} /
{{app.setTask(...)}}, and the rendered view reads them back via
{{app.getJob()}} / {{app.getTask()}}. With a singleton, every request to the
JHS shares one {{App}} instance, so concurrent requests can overwrite each
other's job/task and a page can render data for a different job than the one
requested.
The equivalent fix for the AM web UI, MAPREDUCE-7541
(https://github.com/apache/hadoop/pull/8652), was reviewed with this exact
concern and uses request scope instead:
{code:java}
bind(App.class).in(RequestScoped.class);
{code}
The JHS is long-lived and serves all users, so it should use the same
request-scoped binding.
*Proposed change*
* In {{HsWebApp.setup()}}, change {{Singleton.class}} to
{{com.google.inject.servlet.RequestScoped.class}}.
* Add a regression test that starts the JHS web app and requests
{{/jobhistory/attempts/<job_id>/m/SUCCESSFUL}}, asserting attempt rows are
rendered (guards MAPREDUCE-7527), and ideally that two different jobs' pages
each render their own job.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
