Accumulo
  1. Accumulo
  2. ACCUMULO-2134

SimpleProxyIT fails on TableNotFoundException

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.6.0
    • Component/s: proxy, test
    • Labels:
      None

      Description

      Running org.apache.accumulo.proxy.SimpleProxyIT
      2014-01-04 17:22:37.202 java[59396:1903] Unable to load realm info from SCDynamicStore
      Tests run: 12, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 29.547 sec <<< FAILURE!
      tableNotFound(org.apache.accumulo.proxy.SimpleProxyIT)  Time elapsed: 0.438 sec  <<< ERROR!
      AccumuloException(msg:org.apache.accumulo.core.client.AccumuloException: org.apache.accumulo.core.client.TableNotFoundException: Table doesNotExists does not exist)
      	at org.apache.accumulo.proxy.thrift.AccumuloProxy$removeConstraint_result$removeConstraint_resultStandardScheme.read(AccumuloProxy.java:42869)
      	at org.apache.accumulo.proxy.thrift.AccumuloProxy$removeConstraint_result$removeConstraint_resultStandardScheme.read(AccumuloProxy.java:42855)
      	at org.apache.accumulo.proxy.thrift.AccumuloProxy$removeConstraint_result.read(AccumuloProxy.java:42789)
      	at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
      	at org.apache.accumulo.proxy.thrift.AccumuloProxy$Client.recv_removeConstraint(AccumuloProxy.java:1298)
      	at org.apache.accumulo.proxy.thrift.AccumuloProxy$Client.removeConstraint(AccumuloProxy.java:1283)
      	at org.apache.accumulo.proxy.SimpleProxyIT.tableNotFound(SimpleProxyIT.java:583)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      	at java.lang.reflect.Method.invoke(Method.java:606)
      	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
      	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
      	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
      	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
      	at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
      

        Activity

        Hide
        Eric Newton added a comment -

        I saw this, too. It was inconsistent, though.

        Show
        Eric Newton added a comment - I saw this, too. It was inconsistent, though.
        Hide
        Josh Elser added a comment -

        Oh, good to know. I think I saw it pretty consistently. Either way, hopefully I'll figure out why

        Show
        Josh Elser added a comment - Oh, good to know. I think I saw it pretty consistently. Either way, hopefully I'll figure out why
        Hide
        Josh Elser added a comment -

        Well, I'm not sure how it fails intermittently for you, Eric Newton. It looks like either ACCUMULO-2079 or ACCUMULO-1965. I can fix this with a change to ProxyServer, but I'm currently trying to unravel whether or not this is an expected or unexpected API change. Given how I understand the changes that were made, I believe it was intentional.

        Instead of throwing an TNFException, the code now throws an AccumuloException which wraps the TNFE, and thus the test case fails. I believe the intent was for the client API to unwrap the AccumuloException and throw the TNFE back to the client.

        Show
        Josh Elser added a comment - Well, I'm not sure how it fails intermittently for you, Eric Newton . It looks like either ACCUMULO-2079 or ACCUMULO-1965 . I can fix this with a change to ProxyServer, but I'm currently trying to unravel whether or not this is an expected or unexpected API change. Given how I understand the changes that were made, I believe it was intentional. Instead of throwing an TNFException, the code now throws an AccumuloException which wraps the TNFE, and thus the test case fails. I believe the intent was for the client API to unwrap the AccumuloException and throw the TNFE back to the client.
        Hide
        Josh Elser added a comment -

        If one of Eric Newton or Christopher Tubbs can take a glance at this to make sure it's kosher, I'd appreciate it. I'll leave it open until then.

        Show
        Josh Elser added a comment - If one of Eric Newton or Christopher Tubbs can take a glance at this to make sure it's kosher, I'd appreciate it. I'll leave it open until then.
        Hide
        Eric Newton added a comment -

        It is surprising that a method that throws TNFE doesn't throw TNFE when the table isn't found. I would call this a regression.

        Show
        Eric Newton added a comment - It is surprising that a method that throws TNFE doesn't throw TNFE when the table isn't found. I would call this a regression.
        Hide
        Josh Elser added a comment -

        It is surprising that a method that throws TNFE doesn't throw TNFE when the table isn't found. I would call this a regression.

        I guess that's the not-straightforward part of this. Best as I can tell, I think this is what Christopher Tubbs did to not have to slap a NamespaceNotFoundException and TNFE on every TableOperations method? At the same time, it doesn't look like TableOperationsImpl hasn't ever thrown TableNotFoundException on removeProperty (at least in 1.5.0).

        At the same time, there are a few methods on TableOperations that don't have TNFE thrown... which is awkward.

        Show
        Josh Elser added a comment - It is surprising that a method that throws TNFE doesn't throw TNFE when the table isn't found. I would call this a regression. I guess that's the not-straightforward part of this. Best as I can tell, I think this is what Christopher Tubbs did to not have to slap a NamespaceNotFoundException and TNFE on every TableOperations method? At the same time, it doesn't look like TableOperationsImpl hasn't ever thrown TableNotFoundException on removeProperty (at least in 1.5.0). At the same time, there are a few methods on TableOperations that don't have TNFE thrown... which is awkward.
        Hide
        Josh Elser added a comment -

        Given that this is what TableOperations(Impl) is doing, I believe ProxyServer just needed to be updated to handle this case, otherwise the semantics of ProxyServer would also vary from the previous release.

        Show
        Josh Elser added a comment - Given that this is what TableOperations(Impl) is doing, I believe ProxyServer just needed to be updated to handle this case, otherwise the semantics of ProxyServer would also vary from the previous release.
        Hide
        Christopher Tubbs added a comment -

        The exception happens because the removeConstraint() method uses setProperty(), and somebody forgot to add TNFE to the setProperty() method. So, these methods never threw TNFE. So, as a hack, we've had to wrap the exception in Accumulo's client code. I don't know that there's any intent for the consumer of the API to unwrap the exception. Some people indicated they'd like to do that... but I don't know that we should be making guarantees in the API about a hierarchy of exception causes. Sadly, this means that TNFE for setProperty() related methods will result in an AccumuloException instead of TNFE. This was always the case, though. At least now, it should have some reasonable cause for the AccumuloException, with an informative message, instead of some TApplicationException or some other obscure and difficult-to-debug cause.

        The intermittency of this issue might be related to ACCUMULO-2092, but I haven't done the investigation necessary to confirm that.

        Show
        Christopher Tubbs added a comment - The exception happens because the removeConstraint() method uses setProperty(), and somebody forgot to add TNFE to the setProperty() method. So, these methods never threw TNFE. So, as a hack, we've had to wrap the exception in Accumulo's client code. I don't know that there's any intent for the consumer of the API to unwrap the exception. Some people indicated they'd like to do that... but I don't know that we should be making guarantees in the API about a hierarchy of exception causes. Sadly, this means that TNFE for setProperty() related methods will result in an AccumuloException instead of TNFE. This was always the case, though. At least now, it should have some reasonable cause for the AccumuloException, with an informative message, instead of some TApplicationException or some other obscure and difficult-to-debug cause. The intermittency of this issue might be related to ACCUMULO-2092 , but I haven't done the investigation necessary to confirm that.

          People

          • Assignee:
            Josh Elser
            Reporter:
            Josh Elser
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development