Okay that helps, but it still doesn't really explain that code path. Why are annotations being converted byte-wise to ints? Aren't annotations potentially opaque strings or something else?
-Dan On Fri, Aug 29, 2014 at 11:27 AM, James Taylor <[email protected]> wrote: > Hey Dan, > There were some changes in the test framework to make them run faster. > Our entire test suite can run in about 10-15mins instead of 60mins > now. One of the new requirements is adding the annotation that Samarth > indicated. Once JUnit releases 4.12, this will no longer be necessary, > as the annotation will automatically be inherited from the > BaseClientManagedTimeIT class. > Thanks, > James > > On Thu, Aug 28, 2014 at 10:08 PM, Dan Di Spaltro > <[email protected]> wrote: > > I basically inherit from BaseClientManagedTimeIT and write a junit tests > > > > It's been working great up until 4.1. > > > > This code just doesn't look right, why would an annotation necessarily > have > > to be an int? > > > > > https://github.com/apache/phoenix/blob/29a7be42bfa468b12d16fd0756b987f5359c45c4/phoenix-hadoop2-compat/src/main/java/org/apache/phoenix/trace/TraceMetricSource.java#L122 > > > > then calls the below function, which takes bytes and makes an int from > the > > bytes... > > > > > https://github.com/apache/phoenix/blob/f99e5d8d609d326fb3571255cd8f47961b1c6860/phoenix-hadoop-compat/src/main/java/org/apache/phoenix/trace/TracingCompat.java#L56 > > > > > > On Thu, Aug 28, 2014 at 11:43 AM, Samarth Jain <[email protected]> > > wrote: > >> > >> Dan, > >> > >> Can you tell me how you are running your tests? Do you have the test > class > >> annotated with the right category annotation - > >> @Category(HBaseManagedTimeTest.class). Also, can you send over your test > >> class to see what might be causing problems? > >> > >> Thanks, > >> Samarth > >> > >> > >> On Thu, Aug 28, 2014 at 10:34 AM, Dan Di Spaltro < > [email protected]> > >> wrote: > >>> > >>> Any idea on this, it's blocking my usage in tests and I can't tell if I > >>> am just setting something up incorrectly? Also I am concerned that > this can > >>> affect production since this code path I would assume is used > frequently. > >>> > >>> -Dan > >>> > >>> > >>> On Tue, Aug 26, 2014 at 10:49 PM, Dan Di Spaltro > >>> <[email protected]> wrote: > >>>> > >>>> I inherit from the BaseHBaseManagedTimeIT and implement my own tests > >>>> using the infrastructure you've put together. It's worked pretty > well, > >>>> minus the fact I use an Ivy resolver which doesn't deal with jarless > pom's > >>>> well. > >>>> > >>>> So I've upgraded from 4.0 to 4.1 and ran into a single issue that > looks > >>>> related to Tracing, and I can't really figure it out. When I start > the > >>>> cluster everything works as expected but after I am done creating > tables > >>>> like clockwork I get this: > >>>> > >>>> 58062 [defaultRpcServer.handler=2,queue=0,port=53950] WARN > >>>> org.apache.hadoop.ipc.RpcServer - > >>>> defaultRpcServer.handler=2,queue=0,port=53950: caught: > >>>> java.lang.IllegalArgumentException: offset (0) + length (4) exceed the > >>>> capacity of the array: 3 > >>>> at > >>>> > org.apache.hadoop.hbase.util.Bytes.explainWrongLengthOrOffset(Bytes.java:600) > >>>> at org.apache.hadoop.hbase.util.Bytes.toInt(Bytes.java:749) > >>>> at org.apache.hadoop.hbase.util.Bytes.toInt(Bytes.java:725) > >>>> at > >>>> > org.apache.phoenix.trace.TracingCompat.readAnnotation(TracingCompat.java:56) > >>>> at > >>>> > org.apache.phoenix.trace.TraceMetricSource.receiveSpan(TraceMetricSource.java:121) > >>>> at org.cloudera.htrace.Tracer.deliver(Tracer.java:81) > >>>> at org.cloudera.htrace.impl.MilliSpan.stop(MilliSpan.java:70) > >>>> at org.cloudera.htrace.TraceScope.close(TraceScope.java:70) > >>>> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:106) > >>>> at > >>>> > org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:114) > >>>> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:94) > >>>> at java.lang.Thread.run(Thread.java:744) > >>>> > >>>> And the test just stops, which I imagine is a byproduct of this > >>>> exception. I inspected at this point and there are two traces the > one it > >>>> throws on is the key is "user" and value is my username. It's trying > to > >>>> convert it to an int > >>>> ... > >>>> return new Pair<String, String>(new String(key), > >>>> Integer.toString(Bytes.toInt(value))); > >>>> ... > >>>> > >>>> Any ideas? > >>>> > >>>> -Dan > >>>> > >>>> -- > >>>> Dan Di Spaltro > >>> > >>> > >>> > >>> > >>> -- > >>> Dan Di Spaltro > >> > >> > > > > > > > > -- > > Dan Di Spaltro > -- Dan Di Spaltro
