Uploaded image for project: 'Flume'
  1. Flume
  2. FLUME-3049

Wrapping the exception into SecurityException in UGIExecutor.execute hides the original one



    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 1.8.0
    • None
    • None


      see: https://github.com/apache/flume/blob/trunk/flume-ng-auth/src/main/java/org/apache/flume/auth/UGIExecutor.java#L49

      This has unexpected side effects as the callers try to catch the wrapped exception, for example in BucketWriter.append(): https://github.com/apache/flume/blob/trunk/flume-ng-sinks/flume-hdfs-sink/src/main/java/org/apache/flume/sink/hdfs/BucketWriter.java#L563
      Here IOException is considered as non-transient failure thus the close() is called, but when the original exception is wrapped into SecurityException it doesn't trigger the close of the file.
      Similarly in HDFSEventSink.process() method the `IOException` is handled in a different way than any other exception. It might come from BucketWriter.append() or BucketWriter.flush() for example, and both of them invoke the hdfs call via a PrivilegedExecutor instance which might be the problematic UGIExecutor.

      The bottom line is that the contract in PrivilegedExecutor.execute() is that they shouldn't change the exception thrown in the business logic - at least it's not indicated in its signature in any way. The default implementation (SimpleAuthenticator) behaves according to this.

      I don't know the original intend behind this wrapping, jrufus or hshreedharan, do you happen to remember? (You were involved in the original implementation in FLUME-2631)

      Right now I don't see any problem in removing this and letting the original exception to propagate as the org.apache.flume.auth.SecurityException doesn't appear anywhere in the public interface.


        Issue Links



              denes Denes Arvay
              denes Denes Arvay
              0 Vote for this issue
              7 Start watching this issue