accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-826) MapReduce over accumlo fails if process that started job is killed
Date Fri, 19 Oct 2012 20:28:13 GMT


Christopher Tubbs commented on ACCUMULO-826:

I think a more important question is: why does the user's password get stored in a file without
their knowledge, as a side-effect of the implementation? I think this fundamentally goes against
the point of having static method to manipulate the job configuration (the point being to
only hold job state in the configuration, and not elsewhere with side-effects).

I do understand the benefit of not showing the user's password in the job configuration, which
is viewable from the JobTracker page, whereas the contents of this file wouldn't be. Perhaps
that was the reasoning for storing the password in a file in the first place. However, I think
it should be up to the user to manage this file's persistence, so we don't do unpredictable/unexpected
things, like create a file with their password in it without their knowledge or expectation,
or automatically delete the file when the client dies after the MapReduce job has been submitted,
therefore killing the MapReduce job.

I propose we modify the method signature to look like:
public static void setInputInfo(Configuration conf, String user, Path fileWithPasswordInHDFS,
String table, Authorizations auths);

Users could then re-use this file for multiple jobs, and they can control read/write access
to it.

This change may need to go through a deprecation path, and we may not want to do this until
> MapReduce over accumlo fails if process that started job is killed
> ------------------------------------------------------------------
>                 Key: ACCUMULO-826
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>    Affects Versions: 1.4.1, 1.4.0
>            Reporter: Keith Turner
>            Priority: Critical
> While testing the 1.4.2rc2 I started a continuous verify and killed the process that
started the job.  Normally you would expect the job to keep running when you do this.  Howerver
task started to fail.  I was seeing errors like the following.
> {noformat}
> File does not exist: /user/hadoop/
> 	at org.apache.hadoop.hdfs.DFSClient$DFSInputStream.openInfo(
> 	at org.apache.hadoop.hdfs.DFSClient$DFSInputStream.<init>(
> 	at
> 	at
> 	at
> 	at org.apache.accumulo.core.client.mapreduce.InputFormatBase.getPassword(
> 	at org.apache.accumulo.core.client.mapreduce.InputFormatBase$RecordReaderBase.initialize(
> 	at org.apache.hadoop.mapred.MapTask$NewTrackingRecordReader.initialize(
> 	at org.apache.hadoop.mapred.MapTask.runNewMapper(
> 	at
> 	at org.apache.hadoop.mapred.Child$
> 	at Method)
> 	at
> 	at
> 	at org.apache.hadoop.mapred.Child.main(
> {noformat}
> I think this is caused by the following code in InputFormatBase
> {code:java}
>   public static void setInputInfo(Configuration conf, String user, byte[] passwd, String
table, Authorizations auths) {
>     if (conf.getBoolean(INPUT_INFO_HAS_BEEN_SET, false))
>       throw new IllegalStateException("Input info can only be set once per job");
>     conf.setBoolean(INPUT_INFO_HAS_BEEN_SET, true);
>     ArgumentChecker.notNull(user, passwd, table);
>     conf.set(USERNAME, user);
>     conf.set(TABLE_NAME, table);
>     if (auths != null && !auths.isEmpty())
>       conf.set(AUTHORIZATIONS, auths.serialize());
>     try {
>       FileSystem fs = FileSystem.get(conf);
>       Path file = new Path(fs.getWorkingDirectory(), conf.get("") + System.currentTimeMillis()
+ ".pw");
>       conf.set(PASSWORD_PATH, file.toString());
>       FSDataOutputStream fos = fs.create(file, false);
>       fs.setPermission(file, new FsPermission(FsAction.ALL, FsAction.NONE, FsAction.NONE));
>       fs.deleteOnExit(file);  // <--- NOT 100% sure, but I think this is the culprit
> {code}

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message