hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-1815) Separate client and server jars
Date Thu, 30 Aug 2007 16:52:30 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523877
] 

Doug Cutting commented on HADOOP-1815:
--------------------------------------

There's lots of code that's used on both the client and the server.  Would that go in a third
jar?

Also, you state that your goal is to be able to upgrade the client jar without updating the
server jar.  Why isn't that possible today?  Our current versioning system should already
permit this: we should not be making incompatible protocol changes in point releases.  So
I'm not clear what this will facilitate that's not already possible.  We shouldn't have to
restart clusters to update the client's jar today, so long as there have been no incompatible
protocol changes.

> Separate client and server jars
> -------------------------------
>
>                 Key: HADOOP-1815
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1815
>             Project: Hadoop
>          Issue Type: Bug
>          Components: build
>    Affects Versions: 0.14.0
>         Environment: All
>            Reporter: Milind Bhandarkar
>             Fix For: 0.15.0
>
>
> For the ease of deployment, one should not have to change the server jars, and restart
clusters, when minor features on the client side are changed. This requireds separating client
and server jars for hadoop. Version numbers appended to hadoop jars can reflect the compatibility.
e.g. the server jar could be at 0.13.1, and the client jar could be at 0.13.2. In short, we
can treat the part following 0. as the "major" version number for now.
> This allows major client frameworks such as streaming and Pig happy. To my knowledge,
Pig uses hadoop's default jobclient. Whereas streaming uses its own jobclient. I would love
to change streaming to use the default hadoop jobclient, if I can make modifications to it
(e.g. to print more stats that are available from TaskReport, for example), if I do not have
to deploy the new version of the whole jar to the backend and restart the mapreduce cluster.
> (I thought there was already a bug filed for separating the client and server jar, but
I could not find it. Hence the new Jira. Sorry about duplication, if any.)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message