Hi Francis, This is due to guava-12 vs guava-13 incompatibility [1]. Tephra depends on guava-13 and HBase depends on guava-12. Depending on how the OS orders the jars in the classpath, sometimes guava-12 may appear earlier in the classpath. This leads to the NoSuchMethodError exception. We are planning on removing Tephra's dependency on guava-13 in the next release. Until then a workaround is to add guava-13 jar into the classpath before guava-12 jar.
Thanks, Poorna. [1] - https://issues.apache.org/jira/browse/TEPHRA-181 On Tue, Sep 27, 2016 at 10:09 PM, F21 <[email protected]> wrote: > Hi Poorna, > > That would be very helpful! Unfortunately, I ran into the same issue where > the image no longer works correct on my dev environment, but works properly > on travis. > > I am not receiving this error: > > java.lang.NoSuchMethodError: > co.cask.tephra.TransactionManager.addListener(Lcom/google/co > mmon/util/concurrent/Service$Listener;Ljava/util/concurrent/Executor;)V > at > co.cask.tephra.distributed.TransactionService$1.leader(Trans > actionService.java:83) > at > org.apache.twill.internal.zookeeper.LeaderElection.becomeLea > der(LeaderElection.java:229) > at > org.apache.twill.internal.zookeeper.LeaderElection.access$ > 1800(LeaderElection.java:53) > at > org.apache.twill.internal.zookeeper.LeaderElection$5.onSucce > ss(LeaderElection.java:207) > at > org.apache.twill.internal.zookeeper.LeaderElection$5.onSucce > ss(LeaderElection.java:186) > at > com.google.common.util.concurrent.Futures$5.run(Futures.java:768) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool > Executor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo > lExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > > This is the exact same problem I encountered and posted on the list about > previously: https://mail-archives.apache.org/mod_mbox/phoenix-user/20160 > 3.mbox/%[email protected]%3E > > It's puzzling that an identical image will behave differently on different > systems. Does tephra use any kernel functionalities directly? > > Cheers, > Francis > > > On 28/09/2016 12:04 PM, Poorna Chandra wrote: > >> Hi Francis, >> >> Tephra startup script redirects all logs to a file by default. To help >> debug such issues, you could update the Tephra startup script [1] to log >> everything to stdout instead of a file when running inside docker. We are >> also planning on adding a --foreground option to Tephra startup script, in >> which case the logs will be written to stdout directly. This will help in >> debugging in future. >> >> Thanks, >> Poorna. >> >> [1] - https://github.com/apache/incubator-tephra/blob/master/bin/ >> tephra#L175 >> >> >> On Tue, Sep 27, 2016 at 12:59 AM, F21 <[email protected]> wrote: >> >> I was able to get it to run reliably with Phoenix 4.8.1-rc0. Another part >>> of the equation was forcing travis to use their Ubuntu 14.04 environment >>> rather than the default 12.04 environment. I am assuming 12.04 had an >>> older >>> kernel which prevent docker images from working correctly. >>> >>> On 27/09/2016 10:15 AM, F21 wrote: >>> >>> Hi all, >>>> >>>> I have created a docker image containing HBase 1.2.3 and Phoenix 4.8.0. >>>> See: https://github.com/Boostport/hbase-phoenix-all-in-one >>>> >>>> When running tests against the image on my machine, tephra works >>>> perfectly. >>>> >>>> However, tephra seems to be unreliable in CI environments. It seems that >>>> the tx service is not discovered: >>>> >>>> RuntimeException: java.lang.Exception: Thrift error for >>>> org.apache.tephra.distributed.TransactionServiceClient$2@3e9e291e: >>>> Unable to discover tx service. -> Exception: Thrift error for >>>> org.apache.tephra.distributed.TransactionServiceClient$2@3e9e291e: >>>> Unable to discover tx service. -> TException: Unable to discover tx >>>> service. >>>> >>>> Here's a build on wercker which shows tephra failing: >>>> https://app.wercker.com/boostport/avatica/runs/build/57e9b5d >>>> 170a35501008402b4?step=57e9b5f72c15ad000127a534 >>>> >>>> I also tried travis, but the same issue occurs: >>>> https://travis-ci.org/Boostport/avatica/builds/162952367 >>>> >>>> Since I am unable to ssh into those docker container on wercker or >>>> travis, it is hard to debug what's causing tephra to fail. I am hoping >>>> that >>>> the issue is related to TEPHRA-179 (and a few other JIRAs related to it) >>>> which I reported a few weeks ago and has since been fixed. >>>> >>>> Has anyone else ran into similar problems? I would love to hear your >>>> thoughts. >>>> >>>> Cheers, >>>> >>>> Francis >>>> >>>> >>>> >
