Avro
  1. Avro
  2. AVRO-1215

AvroMultipleOutputs not working when specifying baseOutputPath

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.2
    • Fix Version/s: 1.7.4
    • Component/s: java
    • Labels:
    • Tags:
      avro

      Description

      I'm calling the write() method of AvroMultipleOutputs which takes the baseOutputPath. The reducer appears to begin hanging once it tries writing to a baseOuputPath value not already encountered. It then fails with:

      org.apache.hadoop.ipc.RemoteException: org.apache.hadoop.hdfs.protocol.AlreadyBeingCreatedException: failed to create file ... because current leaseholder is trying to recreate file.

      I think the problem has to do with this line in AvroMultipleOutputs:

      // get the record writer from context output format
      //FileOutputFormat.setOutputName(taskContext, baseFileName);
      

      This line is not commented out in the similar code from Hadoop. So I think the baseOutputPath is ignored. As a result when each record writer is created it uses the same path, leading to the exception.

      Uncommenting this line does not work because of visibility of the method. However what this method does is set "mapreduce.output.basename". But setting this doesn't work either.

      After digging through Avro code I found that AvroOutputFormatBase is using "avro.mo.config.namedOutput" to create the path. If I replace the commented out line with this it seems to work:

      taskContext.getConfiguration().set("avro.mo.config.namedOutput", baseFileName);  
      
      1. AVRO-1215-v3.patch
        7 kB
        Ashish Nagavaram
      2. AVRO-1215.patch
        29 kB
        Ashish Nagavaram
      3. AVRO-1215.patch
        10 kB
        Ashish Nagavaram
      4. AVRO-1215.patch
        9 kB
        Ashish Nagavaram
      5. AVRO-1215_final.patch
        9 kB
        Ashish Nagavaram

        Issue Links

          Activity

          Matthew Hayes created issue -
          Matthew Hayes made changes -
          Field Original Value New Value
          Description I'm calling the write() method of AvroMultipleOutputs which takes the baseOutputPath. The reducer appears to begin hanging once it tries writing to a baseOuputPath value not already encountered. It then fails with:

          org.apache.hadoop.ipc.RemoteException: org.apache.hadoop.hdfs.protocol.AlreadyBeingCreatedException: failed to create file ... because current leaseholder is trying to recreate file.

          I think the problem has to do with this line in AvroMultipleOutputs:

          {code}
                // get the record writer from context output format
                //FileOutputFormat.setOutputName(taskContext, baseFileName);
          {code}

          This line is not commented out in the similar code from Hadoop. So I think the baseOutputPath is ignored. As a result when each record writer is created it uses the same path, leading to the exception.

          Uncommenting this line does not work because of visibility of the method. However what this method does is set "mapreduce.output.basename". But setting this doesn't work either.

          After digging through Avro code I found that AvroOutputFormatBase is using "avro.mo.config.namedOutput" to create the path. If I replace the commented out line with this it seems to work:

          {code}
          taskContext.getConfiguration().set("avro.mo.config.namedOutput", baseFileName);
          {code}
          I'm calling the write() method of AvroMultipleOutputs which takes the baseOutputPath. The reducer appears to begin hanging once it tries writing to a baseOuputPath value not already encountered. It then fails with:

          org.apache.hadoop.ipc.RemoteException: org.apache.hadoop.hdfs.protocol.AlreadyBeingCreatedException: failed to create file ... because current leaseholder is trying to recreate file.

          I think the problem has to do with this line in AvroMultipleOutputs:

          {code}
          // get the record writer from context output format
          //FileOutputFormat.setOutputName(taskContext, baseFileName);
          {code}

          This line is not commented out in the similar code from Hadoop. So I think the baseOutputPath is ignored. As a result when each record writer is created it uses the same path, leading to the exception.

          Uncommenting this line does not work because of visibility of the method. However what this method does is set "mapreduce.output.basename". But setting this doesn't work either.

          After digging through Avro code I found that AvroOutputFormatBase is using "avro.mo.config.namedOutput" to create the path. If I replace the commented out line with this it seems to work:

          {code}
          taskContext.getConfiguration().set("avro.mo.config.namedOutput", baseFileName);
          {code}
          Matthew Hayes made changes -
          Link This issue blocks AVRO-1106 [ AVRO-1106 ]
          Hide
          Matthew Hayes added a comment -

          JIRA where this code was created

          Show
          Matthew Hayes added a comment - JIRA where this code was created
          Matthew Hayes made changes -
          Labels avro mapreduce
          Matthew Hayes made changes -
          Tags avro
          Matthew Hayes made changes -
          Link This issue blocks AVRO-1106 [ AVRO-1106 ]
          Matthew Hayes made changes -
          Link This issue is related to AVRO-1106 [ AVRO-1106 ]
          Hide
          Ashish Nagavaram added a comment -

          Hi,

          Is this in the function write(key,value,baseoutputPath) ??

          I think there is already an issue open, Please take a look at https://issues.apache.org/jira/browse/AVRO-1179 to check if it is the same.

          I have a fix which I am testing right now.

          Show
          Ashish Nagavaram added a comment - Hi, Is this in the function write(key,value,baseoutputPath) ?? I think there is already an issue open, Please take a look at https://issues.apache.org/jira/browse/AVRO-1179 to check if it is the same. I have a fix which I am testing right now.
          Matthew Hayes made changes -
          Link This issue duplicates AVRO-1179 [ AVRO-1179 ]
          Hide
          Matthew Hayes added a comment -

          Yes this is the function and it is the same issue. If you use only one value for baseOutputPath the task will not fail but it won't use the correct path. If however you use different values it will fail.

          Show
          Matthew Hayes added a comment - Yes this is the function and it is the same issue. If you use only one value for baseOutputPath the task will not fail but it won't use the correct path. If however you use different values it will fail.
          Hide
          Ashish Nagavaram added a comment -

          Patch with necessary changes and Updates TestAvroMultipleOutputs to test the new changes. The Write(key,value,baseoutputpath) will use the default job output Schema to write the output.

          Show
          Ashish Nagavaram added a comment - Patch with necessary changes and Updates TestAvroMultipleOutputs to test the new changes. The Write(key,value,baseoutputpath) will use the default job output Schema to write the output.
          Ashish Nagavaram made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Hide
          Ashish Nagavaram added a comment -

          Patch with changes for jira avro 1215 bug

          Show
          Ashish Nagavaram added a comment - Patch with changes for jira avro 1215 bug
          Ashish Nagavaram made changes -
          Attachment avro-1215.patch [ 12559907 ]
          Ashish Nagavaram made changes -
          Assignee Ashish Nagavaram [ nagav.ashish ]
          Hide
          Matthew Hayes added a comment -

          It looks like this should work. Shouldn't you update the other write method too?

          There is this one:

          public void write(String namedOutput, Object key, Object value,
                String baseOutputPath)
          

          and this one:

          public void write(Object key, Object value, String baseOutputPath) 
          

          Alternatively you could move this code into getRecordWriter.

          Show
          Matthew Hayes added a comment - It looks like this should work. Shouldn't you update the other write method too? There is this one: public void write( String namedOutput, Object key, Object value, String baseOutputPath) and this one: public void write( Object key, Object value, String baseOutputPath) Alternatively you could move this code into getRecordWriter.
          Hide
          Harsh J added a comment -

          Since we're providing a custom implementation of MultipleOutputs here, we do not need to be overly concerned about extending its API.

          For instance, though the Hadoop MR MO has these write(K, V, P) APIs, it had no notion of schemas. Avro MR MO can provide, on top of this default-pulling APIs, a schema-providing API such as write(K, V, Schema, P). I see no harm in doing that since Avro is all schema-dependent and this may be more useful, than relying on the default job output schema automatically.

          Show
          Harsh J added a comment - Since we're providing a custom implementation of MultipleOutputs here, we do not need to be overly concerned about extending its API. For instance, though the Hadoop MR MO has these write(K, V, P) APIs, it had no notion of schemas. Avro MR MO can provide, on top of this default-pulling APIs, a schema-providing API such as write(K, V, Schema, P). I see no harm in doing that since Avro is all schema-dependent and this may be more useful, than relying on the default job output schema automatically.
          Hide
          Ashish Nagavaram added a comment -

          for the function

          public void write(String namedOutput, Object key, Object value,
          String baseOutputPath)

          it is handled by the call to getcontext() from the function. The only function where it fails was

          public void write(Object key, Object value, String baseOutputPath)

          which is handled by the new change.

          It makes sense to have schema in write(K,V,P), this allows us to skip declaring namedoutput for every outputlocation. I will work on this.

          Show
          Ashish Nagavaram added a comment - for the function public void write(String namedOutput, Object key, Object value, String baseOutputPath) it is handled by the call to getcontext() from the function. The only function where it fails was public void write(Object key, Object value, String baseOutputPath) which is handled by the new change. It makes sense to have schema in write(K,V,P), this allows us to skip declaring namedoutput for every outputlocation. I will work on this.
          Hide
          Priyo Mustafi added a comment -

          I am using the write(String namedOutput, Object key, Object value, String baseOutputPath) method with different sets of namedOutput and baseOutputPath so that each namedOutput goes to a different directory. Somehow all files are getting created in the main output directory instead of the directories given under baseOutputPath. I converted all our mapreduces to Avro and suddenly found this issue. Any help greatly appreciated?

          Show
          Priyo Mustafi added a comment - I am using the write(String namedOutput, Object key, Object value, String baseOutputPath) method with different sets of namedOutput and baseOutputPath so that each namedOutput goes to a different directory. Somehow all files are getting created in the main output directory instead of the directories given under baseOutputPath. I converted all our mapreduces to Avro and suddenly found this issue. Any help greatly appreciated?
          Hide
          Priyo Mustafi added a comment -

          I added your patch to the below and it seems to fix the issue for me. When can this be rolled out?
          public void write(String namedOutput, Object key, Object value, String baseOutputPath)

          By the way, the AlreadyBeingCreatedException happens when you have baseOutputPath outside of the main output path. This is a known bug. https://issues.apache.org/jira/browse/MAPREDUCE-3772

          Show
          Priyo Mustafi added a comment - I added your patch to the below and it seems to fix the issue for me. When can this be rolled out? public void write(String namedOutput, Object key, Object value, String baseOutputPath) By the way, the AlreadyBeingCreatedException happens when you have baseOutputPath outside of the main output path. This is a known bug. https://issues.apache.org/jira/browse/MAPREDUCE-3772
          Hide
          Priyo Mustafi added a comment -

          Ashish, please fix you patch to address the other methods mentioned by Matthew. As noted, they don't work either without the patch.

          Show
          Priyo Mustafi added a comment - Ashish, please fix you patch to address the other methods mentioned by Matthew. As noted, they don't work either without the patch.
          Hide
          Ashish Nagavaram added a comment -

          Sorry for the delay, I was on vacation. I am attaching a new Patch with update to function write(K,V,basepath) to accept key and value schemas. This avoids created named outputs for every base path.

          This patch also has the fix for path issues

          Show
          Ashish Nagavaram added a comment - Sorry for the delay, I was on vacation. I am attaching a new Patch with update to function write(K,V,basepath) to accept key and value schemas. This avoids created named outputs for every base path. This patch also has the fix for path issues
          Ashish Nagavaram made changes -
          Attachment AVRO-1215.patch [ 12565903 ]
          Hide
          Ashish Nagavaram added a comment -

          just to add to the earlier comment, the updated method looks like write(K,V,keySchema,valSchema,baseOutputPath).

          Show
          Ashish Nagavaram added a comment - just to add to the earlier comment, the updated method looks like write(K,V,keySchema,valSchema,baseOutputPath).
          Hide
          Ashish Nagavaram added a comment -

          Adding in the old write(K,V,baseoutputpath) so that we can skip specifying schema everytime (default job schema is used)

          Show
          Ashish Nagavaram added a comment - Adding in the old write(K,V,baseoutputpath) so that we can skip specifying schema everytime (default job schema is used)
          Ashish Nagavaram made changes -
          Attachment AVRO-1215-v2.patch [ 12565997 ]
          Hide
          Ashish Nagavaram added a comment -

          removed a out.println line from the code.

          Show
          Ashish Nagavaram added a comment - removed a out.println line from the code.
          Ashish Nagavaram made changes -
          Attachment AVRO-1215-v3.patch [ 12566040 ]
          Ashish Nagavaram made changes -
          Link This issue duplicates AVRO-1236 [ AVRO-1236 ]
          Hide
          Priyo Mustafi added a comment -

          Hi Ashish,
          Are you coming up with a new API? Would you be having a patch for these as well which I use?
          public void write(String namedOutput, Object key, Object value, String baseOutputPath)
          public void write(Object key, Object value, String baseOutputPath)

          I just found another issue. I have a MR which writes different schemas on different outputs. My driver registers these using this method in AvroMultipleOutputs. The output of the mapper is a union-schema as each mapper can output to different multipleoutputs using their respective schemas.

          public static void addNamedOutput(Job job, String namedOutput, Class<? extends OutputFormat> outputFormatClass,
          Schema keySchema, Schema valueSchema)

          When I run locally everything works fine. Each output avro file has their respective key and value schema. When I run on a cluster, all the different avro files have the union schema which is set on the main output otherwise it gives classcastexception.

          Looking deeper into AvroMultipleOutputs I notice that the addNamedOutput() registering method above adds the key and value schema to "private static" map and these schemas are never added to the configuration. So there is no way this map would be populated on the reducer side and when it tries to lookup the schemas using namedoutput+"_KEYSCHEMA" etc, it is obviously not there and it picks up the main outputschema which in my case is the union. If we put these on the configuration and read it back on the reducer, this should work.

          Show
          Priyo Mustafi added a comment - Hi Ashish, Are you coming up with a new API? Would you be having a patch for these as well which I use? public void write(String namedOutput, Object key, Object value, String baseOutputPath) public void write(Object key, Object value, String baseOutputPath) I just found another issue. I have a MR which writes different schemas on different outputs. My driver registers these using this method in AvroMultipleOutputs. The output of the mapper is a union-schema as each mapper can output to different multipleoutputs using their respective schemas. public static void addNamedOutput(Job job, String namedOutput, Class<? extends OutputFormat> outputFormatClass, Schema keySchema, Schema valueSchema) When I run locally everything works fine. Each output avro file has their respective key and value schema. When I run on a cluster, all the different avro files have the union schema which is set on the main output otherwise it gives classcastexception. Looking deeper into AvroMultipleOutputs I notice that the addNamedOutput() registering method above adds the key and value schema to "private static" map and these schemas are never added to the configuration. So there is no way this map would be populated on the reducer side and when it tries to lookup the schemas using namedoutput+"_KEYSCHEMA" etc, it is obviously not there and it picks up the main outputschema which in my case is the union. If we put these on the configuration and read it back on the reducer, this should work.
          Hide
          Ashish Nagavaram added a comment -

          Hi Priyo,

          I have already attached a patch https://issues.apache.org/jira/secure/attachment/12566040/AVRO-1215-v3.patch in this bug which has a fix for write(Object key, Object value, String baseOutputPath). I have tested this and it works fine for me.

          I also added another method in the AvroMultipleOutputs, write(K,V, keyschema , valueschema, baseoutputpath) where we can define multiple schemas, can you try testing your code with this method?

          The main reason for using a map to store schemas was to avoid parsing it again (since some schema declarations maybe huge).

          This map is populated from the main function of the mapreduce code and the AvroMultipleOutputs class is instantiated in the setup method of the reducer.
          http://svn.apache.org/repos/asf/avro/trunk/lang/java/mapred/src/test/java/org/apache/avro/mapreduce/TestAvroMultipleOutputs.java

          Please let me know if it still doesn't work. In the meanwhile I will add methods to expose key and value schemas given the job and namedoutput.

          Show
          Ashish Nagavaram added a comment - Hi Priyo, I have already attached a patch https://issues.apache.org/jira/secure/attachment/12566040/AVRO-1215-v3.patch in this bug which has a fix for write(Object key, Object value, String baseOutputPath). I have tested this and it works fine for me. I also added another method in the AvroMultipleOutputs, write(K,V, keyschema , valueschema, baseoutputpath) where we can define multiple schemas, can you try testing your code with this method? The main reason for using a map to store schemas was to avoid parsing it again (since some schema declarations maybe huge). This map is populated from the main function of the mapreduce code and the AvroMultipleOutputs class is instantiated in the setup method of the reducer. http://svn.apache.org/repos/asf/avro/trunk/lang/java/mapred/src/test/java/org/apache/avro/mapreduce/TestAvroMultipleOutputs.java Please let me know if it still doesn't work. In the meanwhile I will add methods to expose key and value schemas given the job and namedoutput.
          Hide
          Ashish Nagavaram added a comment -

          Hi priyo,

          my bad, I tried to run the MR code and noticed that you were right. I will add it to existing patch.

          Show
          Ashish Nagavaram added a comment - Hi priyo, my bad, I tried to run the MR code and noticed that you were right. I will add it to existing patch.
          Hide
          Johannes Schulte added a comment -

          Hi! Funny thing i ran into the same problem (multiple schemas not working) and created an issue with a patch for it yesterday

          https://issues.apache.org/jira/browse/AVRO-1239

          since the problem is adressed in here, this could be closed. There is a patch in there wrapping the schemas in the configuration, but it should be done by now by your patch. I also like the explicit write(K,V, keyschema , valueschema, baseoutputpath) sinc, like Harsh J said above, we don't have to fulfill an api contract plus you know the type of schema you write mostly in the multiple output case.

          Show
          Johannes Schulte added a comment - Hi! Funny thing i ran into the same problem (multiple schemas not working) and created an issue with a patch for it yesterday https://issues.apache.org/jira/browse/AVRO-1239 since the problem is adressed in here, this could be closed. There is a patch in there wrapping the schemas in the configuration, but it should be done by now by your patch. I also like the explicit write(K,V, keyschema , valueschema, baseoutputpath) sinc, like Harsh J said above, we don't have to fulfill an api contract plus you know the type of schema you write mostly in the multiple output case.
          Johannes Schulte made changes -
          Link This issue is duplicated by AVRO-1239 [ AVRO-1239 ]
          Hide
          Ashish Nagavaram added a comment -

          Final version - with some code formatting and cleanup

          Show
          Ashish Nagavaram added a comment - Final version - with some code formatting and cleanup
          Ashish Nagavaram made changes -
          Attachment AVRO-1215.patch [ 12567959 ]
          Ashish Nagavaram made changes -
          Attachment avro-1215.patch [ 12559907 ]
          Ashish Nagavaram made changes -
          Attachment AVRO-1215.patch [ 12565903 ]
          Ashish Nagavaram made changes -
          Attachment AVRO-1215-v2.patch [ 12565997 ]
          Hide
          Doug Cutting added a comment -

          A lot of the changes in this patch seem to be whitespace-only. This makes it hard to see the functional changes. If you'd like to re-format AvroMultipleOutputs, then that would better be done in a separate patch.

          Can any others (e.g., Johannes, Priyo, Harsh, or Matthew) confirm whether this patch addresses the problems they've had? Thanks!

          Show
          Doug Cutting added a comment - A lot of the changes in this patch seem to be whitespace-only. This makes it hard to see the functional changes. If you'd like to re-format AvroMultipleOutputs, then that would better be done in a separate patch. Can any others (e.g., Johannes, Priyo, Harsh, or Matthew) confirm whether this patch addresses the problems they've had? Thanks!
          Hide
          Priyo Mustafi added a comment -

          I agree with Doug. There are too many changes mostly due to code formatting. Ashish, please post a patch without code formatting changes that we can review.

          Show
          Priyo Mustafi added a comment - I agree with Doug. There are too many changes mostly due to code formatting. Ashish, please post a patch without code formatting changes that we can review.
          Hide
          Ashish Nagavaram added a comment -

          sorry about that, I used the default eclipse formatting which seems to have altered all of the earlier formatting. I will reformat and attach a patch

          Show
          Ashish Nagavaram added a comment - sorry about that, I used the default eclipse formatting which seems to have altered all of the earlier formatting. I will reformat and attach a patch
          Hide
          Ashish Nagavaram added a comment -

          Patch for the above after proper formatting.

          Show
          Ashish Nagavaram added a comment - Patch for the above after proper formatting.
          Ashish Nagavaram made changes -
          Attachment AVRO-1215.patch [ 12568308 ]
          Hide
          Ashish Nagavaram added a comment -

          Forgot to remove commented lines. Final Patch

          Show
          Ashish Nagavaram added a comment - Forgot to remove commented lines. Final Patch
          Ashish Nagavaram made changes -
          Attachment AVRO-1215.patch [ 12568310 ]
          Hide
          Ashish Nagavaram added a comment -

          did anyone get a chance to test the new patch?

          Show
          Ashish Nagavaram added a comment - did anyone get a chance to test the new patch?
          Hide
          Doug Cutting added a comment -

          Shouldn't this still call createTaskAttemptContext to create the context?

          Show
          Doug Cutting added a comment - Shouldn't this still call createTaskAttemptContext to create the context?
          Hide
          Johannes Schulte added a comment -

          Ashish, i tested the patch and it works fine for me (different schemas in the output)

          thanks for the work!

          Show
          Johannes Schulte added a comment - Ashish, i tested the patch and it works fine for me (different schemas in the output) thanks for the work!
          Hide
          Ashish Nagavaram added a comment -

          Hi Doug,

          I assume you are referring to the write(k,v,schema,schema,baseoutputfile), it still has a call to create context only that I moved it after schema has been assigned to the AvroJob.

          Thanks Johannes for testing the patch.

          Show
          Ashish Nagavaram added a comment - Hi Doug, I assume you are referring to the write(k,v,schema,schema,baseoutputfile), it still has a call to create context only that I moved it after schema has been assigned to the AvroJob. Thanks Johannes for testing the patch.
          Hide
          Doug Cutting added a comment -

          I was referring to the following from the patch:

          -    TaskAttemptContext taskContext = createTaskAttemptContext(
          -      context.getConfiguration(), context.getTaskAttemptID());
          +    Job job = new Job(context.getConfiguration());
          +    setSchema(job, keySchema, valSchema);
          +    TaskAttemptContext taskContext = new TaskAttemptContext(
          +        job.getConfiguration(), context.getTaskAttemptID());
          

          A call to createTaskAttemptContext is replaced with a call to 'new TaskAttemptContext'. I believe that createTaskAttemptContext should still be used. This is described in AVRO-1170.

          Show
          Doug Cutting added a comment - I was referring to the following from the patch: - TaskAttemptContext taskContext = createTaskAttemptContext( - context.getConfiguration(), context.getTaskAttemptID()); + Job job = new Job(context.getConfiguration()); + setSchema(job, keySchema, valSchema); + TaskAttemptContext taskContext = new TaskAttemptContext( + job.getConfiguration(), context.getTaskAttemptID()); A call to createTaskAttemptContext is replaced with a call to 'new TaskAttemptContext'. I believe that createTaskAttemptContext should still be used. This is described in AVRO-1170 .
          Hide
          Ashish Nagavaram added a comment -

          sorry, my bad I thought I thought I was using the createTaskAttemptContext() method.

          I am uploading a new patch with changes to call the method, rather than creating a new context object.

          Show
          Ashish Nagavaram added a comment - sorry, my bad I thought I thought I was using the createTaskAttemptContext() method. I am uploading a new patch with changes to call the method, rather than creating a new context object.
          Ashish Nagavaram made changes -
          Attachment AVRO-1215_final.patch [ 12569736 ]
          Hide
          Doug Cutting added a comment -

          I committed this. Thanks, Ashish!

          Show
          Doug Cutting added a comment - I committed this. Thanks, Ashish!
          Doug Cutting made changes -
          Status Patch Available [ 10002 ] Resolved [ 5 ]
          Fix Version/s 1.7.4 [ 12323742 ]
          Resolution Fixed [ 1 ]
          Hide
          Hudson added a comment -

          Integrated in AvroJava #352 (See https://builds.apache.org/job/AvroJava/352/)
          AVRO-1215. Java: Fix AvroMultipleOutputs when specifying baseOutputPath. Contributed by Ashish Nagavaram. (Revision 1447419)

          Result = FAILURE
          cutting :
          Files :

          • /avro/trunk/CHANGES.txt
          • /avro/trunk/lang/java/mapred/src/main/java/org/apache/avro/mapreduce/AvroMultipleOutputs.java
          • /avro/trunk/lang/java/mapred/src/test/java/org/apache/avro/mapreduce/TestAvroMultipleOutputs.java
          Show
          Hudson added a comment - Integrated in AvroJava #352 (See https://builds.apache.org/job/AvroJava/352/ ) AVRO-1215 . Java: Fix AvroMultipleOutputs when specifying baseOutputPath. Contributed by Ashish Nagavaram. (Revision 1447419) Result = FAILURE cutting : Files : /avro/trunk/CHANGES.txt /avro/trunk/lang/java/mapred/src/main/java/org/apache/avro/mapreduce/AvroMultipleOutputs.java /avro/trunk/lang/java/mapred/src/test/java/org/apache/avro/mapreduce/TestAvroMultipleOutputs.java
          Doug Cutting made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Ashish Nagavaram made changes -
          Link This issue relates AVRO-1266 [ AVRO-1266 ]
          Gavin made changes -
          Link This issue relates to AVRO-1266 [ AVRO-1266 ]
          Gavin made changes -
          Link This issue relates to AVRO-1266 [ AVRO-1266 ]

            People

            • Assignee:
              Ashish Nagavaram
              Reporter:
              Matthew Hayes
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development