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/common/util/concurrent/Service$Listener;Ljava/util/concurrent/Executor;)V
at
co.cask.tephra.distributed.TransactionService$1.leader(TransactionService.java:83)
at
org.apache.twill.internal.zookeeper.LeaderElection.becomeLeader(LeaderElection.java:229)
at
org.apache.twill.internal.zookeeper.LeaderElection.access$1800(LeaderElection.java:53)
at
org.apache.twill.internal.zookeeper.LeaderElection$5.onSuccess(LeaderElection.java:207)
at
org.apache.twill.internal.zookeeper.LeaderElection$5.onSuccess(LeaderElection.java:186)
at
com.google.common.util.concurrent.Futures$5.run(Futures.java:768)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.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/201603.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
