hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sangjin Lee (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-1492) truly shared cache for jars (jobjar/libjar)
Date Tue, 07 Jan 2014 19:04:11 GMT

    [ https://issues.apache.org/jira/browse/YARN-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13864557#comment-13864557
] 

Sangjin Lee commented on YARN-1492:
-----------------------------------

Thanks for the comments [~kkambatl]!

bq. In the client protocol, if a cleaner instance (or run) starts after R2 and before R2',
the client wouldn't know of this cleaner's existence.

That's why step R1 exists. Since the client lock is dropped *before* the client inspects the
cleaner lock, even if the cleaner starts between R2 and R2' the cleaner simply skips this
entry in favor of the client.

Having said that, we are currently looking at the design again to better address the issue
of security and other aspects. So it is likely some of these design choices may be revisited.

> truly shared cache for jars (jobjar/libjar)
> -------------------------------------------
>
>                 Key: YARN-1492
>                 URL: https://issues.apache.org/jira/browse/YARN-1492
>             Project: Hadoop YARN
>          Issue Type: New Feature
>    Affects Versions: 2.0.4-alpha
>            Reporter: Sangjin Lee
>            Assignee: Sangjin Lee
>         Attachments: shared_cache_design.pdf, shared_cache_design_v2.pdf, shared_cache_design_v3.pdf,
shared_cache_design_v4.pdf
>
>
> Currently there is the distributed cache that enables you to cache jars and files so
that attempts from the same job can reuse them. However, sharing is limited with the distributed
cache because it is normally on a per-job basis. On a large cluster, sometimes copying of
jobjars and libjars becomes so prevalent that it consumes a large portion of the network bandwidth,
not to speak of defeating the purpose of "bringing compute to where data is". This is wasteful
because in most cases code doesn't change much across many jobs.
> I'd like to propose and discuss feasibility of introducing a truly shared cache so that
multiple jobs from multiple users can share and cache jars. This JIRA is to open the discussion.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message