Hi Russel,
Apparently, Phoenix 4.0.0 leverages few API methods of HBase 0.98.4 v
which aren't present within 0.98.1 that comes with CDH 5.1 . That's the
primary cause for the build issues.
Regards
Ravi
On Mon, Aug 18, 2014 at 5:56 PM, Russell Jurney russell.jur...@gmail.com
wrote:
Thats really bad. That means... CDH 5.x can't run Phoenix? How can this be
fixed? I'm not sure what to do. We're in limbo on our new cluster now.
ᐧ
On Mon, Aug 18, 2014 at 11:57 PM, Ravi Kiran maghamraviki...@gmail.com
wrote:
Hi Russel,
Apparently, Phoenix 4.0.0 leverages few API methods
@James Taylor, correct me if I'm wrong, but it should be backwards
compatible with older versions of HBase 0.98 - the build issues are
separate from phoenix actually being able to run on that cluster
(compatibilities should be handled via reflection).
If there are cases where that's not true,
Yeah, that would mean http://phoenix.apache.org/download.html is wrong. It
claims 0.98 support.
ᐧ
On Tue, Aug 19, 2014 at 11:48 AM, Jesse Yates jesse.k.ya...@gmail.com
wrote:
@James Taylor, correct me if I'm wrong, but it should be backwards
compatible with older versions of HBase 0.98 - the
The dependencies on HBase 0.98.4 are *compile time* dependencies. Is it
necessary for you to compile against CDH 5.1 or just run against it?
On Tuesday, August 19, 2014, Russell Jurney russell.jur...@gmail.com
wrote:
Thats really bad. That means... CDH 5.x can't run Phoenix? How can this be
Running against any version would be ok, but it does not work. I get this
error:
2014-08-19 14:03:46,904 FATAL org.apache.hadoop.mapred.Child: Error
running child : java.lang.IncompatibleClassChangeError: Found
interface org.apache.hadoop.mapreduce.TaskAttemptContext, but class
was expected
ᐧ
I
I don't think an Apache project should spend precious bandwidth tracking
the various and sundry redistributors of Apache ecosystem projects. This is
putting the cart before the horse. The horse is the Apache upstream
projects. The cart is the commercial distributions leveraging the Apache
First of all, I apologize if you feel like I was picking on you. I was not
trying to do that.
My understanding is that Salesforce pays people to work on Phoenix. Is that
not the case? I'm hoping one of them will add spark-like support for CDH
and HDP to advance the project.
And I don't mention
FWIW internally at Salesforce we also patch the HBase and Hadoop poms to
support our own internal 'light forks'. Its really not a big deal to manage
- a couple of jenkins jobs (one to automate, one to track open source
changes and ensure your patch(es) still work, etc) and you are good to go.
I
Maybe this is something I can fix. If I were to add the
cloudera/hortonworks maven repos, and then add some supported options for
hadoop beyond 1/2, that would pretty much do it, right?
ᐧ
On Tue, Aug 19, 2014 at 3:49 PM, Jesse Yates jesse.k.ya...@gmail.com
wrote:
FWIW internally at Salesforce
Maybe pick on didn't get close enough to what I was after.
Maybe this is something I can fix. If I were to add the
cloudera/hortonworks maven repos, and then add some supported options for
hadoop beyond 1/2, that would pretty much do it, right?
I doubt it, because v4 and master branches
I agree the vendor should resolve these issues. Hortonworks has already
included Phoenix in HDP. Cloudera is behind the curve here. I'm told
they'll include Phoenix when they feel they can support it well.
That being said, wouldn't adding CDH/HDP options in pom.xml make the
project easier to use,
12 matches
Mail list logo