Cassandra
  1. Cassandra
  2. CASSANDRA-4177

Little improvement on the messages of the exceptions thrown by ExternalClient

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Trivial Trivial
    • Resolution: Won't Fix
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      After adding BulkRecordWriter (or actually ExternalClient) the ability to make use of authentication I've noticed that exceptions that are thrown on login failure are very misguiding - there's always a "Could not retrieve endpoint ranges" RuntimeException being thrown, no matter what really happens. This "hides" the real reason of all authentication problems. I've changed this line a bit, so all the messages are passed without any change, so now I get - for example - "AuthenticationException(why:Given password in password mode MD5 could not be validated for user operator)" or - in worst case - "Unexpected authentication problem", which is waaay more helpful, so I submit this trivial, but useful improvement.

      1. trunk-4177.txt
        0.7 kB
        Michał Michalski

        Activity

        Hide
        Michał Michalski added a comment -

        Patch

        Show
        Michał Michalski added a comment - Patch
        Hide
        Michał Michalski added a comment -

        Pass the Exceptions messages without overwriting it with some fixed ones.

        Show
        Michał Michalski added a comment - Pass the Exceptions messages without overwriting it with some fixed ones.
        Hide
        Jonathan Ellis added a comment -

        Don't you get a "Caused by" later on in the stack trace with the original approach?

        Show
        Jonathan Ellis added a comment - Don't you get a "Caused by" later on in the stack trace with the original approach?
        Hide
        Michał Michalski added a comment -

        Good point. This is what I get:

        12/04/27 08:58:05 INFO mapred.JobClient: Task Id : attempt_201204100823_2167_m_000000_0, Status : FAILED
        java.lang.RuntimeException: Could not retrieve endpoint ranges: 
        	at org.apache.cassandra.hadoop.BulkRecordWriter$ExternalClient.init(BulkRecordWriter.java:263)
        	at org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:117)
        	at org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:112)
        	at org.apache.cassandra.hadoop.BulkRecordWriter.close(BulkRecordWriter.java:193)
        	at org.apache.cassandra.hadoop.BulkRecordWriter.close(BulkRecordWriter.java:178)
        	at org.apache.hadoop.mapred.MapTask$NewDirectOutputCollector.close(MapTask.java:540)
        	at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:649)
        	at org.apache.hadoop.mapred.MapTask.run(MapTask.java:323)
        	at org.apache.hadoop.mapred.Child$4.run(Child.java:270)
        	at java.security.AccessController.doPrivileged(Native Method)
        	at javax.security.auth.Subject.doAs(Subject.java:396)
        	at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1127)
        	at org.apache.hadoop.mapred.Child.main(Child.java:264)
        Caus
        

        So, I guess that this "Caus" in the end is what you are asking about, but for some reason it's truncated. Of course I bet that it's because of my app, but I will have to investigate it a bit.

        Anyway, I still think that the exception with a fixed message like this is inappriopriate and misguiding in some way if we can get more detailed Exceptions of many kinds here. I've checked how does it looks like in other classes with authentication and what I found is that i.e. in ColumnFamilyRecordReader.java it's made in the way I proposed (throw new RuntimeException(e). So, I'm not arguing that it's a kind of a must-have thing, but I still think it's a bit more "proper" way of handling this case

        However, answering your question - yes, you're right

        Show
        Michał Michalski added a comment - Good point. This is what I get: 12/04/27 08:58:05 INFO mapred.JobClient: Task Id : attempt_201204100823_2167_m_000000_0, Status : FAILED java.lang.RuntimeException: Could not retrieve endpoint ranges: at org.apache.cassandra.hadoop.BulkRecordWriter$ExternalClient.init(BulkRecordWriter.java:263) at org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:117) at org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:112) at org.apache.cassandra.hadoop.BulkRecordWriter.close(BulkRecordWriter.java:193) at org.apache.cassandra.hadoop.BulkRecordWriter.close(BulkRecordWriter.java:178) at org.apache.hadoop.mapred.MapTask$NewDirectOutputCollector.close(MapTask.java:540) at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:649) at org.apache.hadoop.mapred.MapTask.run(MapTask.java:323) at org.apache.hadoop.mapred.Child$4.run(Child.java:270) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:396) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1127) at org.apache.hadoop.mapred.Child.main(Child.java:264) Caus So, I guess that this "Caus" in the end is what you are asking about, but for some reason it's truncated. Of course I bet that it's because of my app, but I will have to investigate it a bit. Anyway, I still think that the exception with a fixed message like this is inappriopriate and misguiding in some way if we can get more detailed Exceptions of many kinds here. I've checked how does it looks like in other classes with authentication and what I found is that i.e. in ColumnFamilyRecordReader.java it's made in the way I proposed (throw new RuntimeException(e) . So, I'm not arguing that it's a kind of a must-have thing, but I still think it's a bit more "proper" way of handling this case However, answering your question - yes, you're right
        Hide
        Brandon Williams added a comment -

        This patch isn't really going to solve anything for you, except remove the "Could not retrieve endpoint ranges" prefix, which is still technically correct.

        Show
        Brandon Williams added a comment - This patch isn't really going to solve anything for you, except remove the "Could not retrieve endpoint ranges" prefix, which is still technically correct.
        Hide
        Michał Michalski added a comment -

        Oh, I almost forgot about this issue! Thanks for reply and yes - as I look at this issue again - it seems invalid even for me now

        Show
        Michał Michalski added a comment - Oh, I almost forgot about this issue! Thanks for reply and yes - as I look at this issue again - it seems invalid even for me now

          People

          • Assignee:
            Michał Michalski
            Reporter:
            Michał Michalski
            Reviewer:
            Brandon Williams
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development