Re: Phoenix CsvBulkLoadTool fails with java.sql.SQLException: ERROR 103 (08004): Unable to establish connection

2018-08-21 Thread Jaanai Zhang
Caused by: java.lang.IllegalAccessError: class org.apache.hadoop.hdfs.web.HftpFileSystem cannot access its superinterface org.apache.hadoop.hdfs.web.TokenAspect$ TokenManagementDelegator This is the root cause, it seems that HBase 1.2 can't access interface of Hadoop 3.1, so you should consider

CursorUtil -> mapCursorIDQuery

2018-08-21 Thread Jack Steenkamp
Hi All, In my application I make heavy use of Apache Phoenix's Cursors (https://phoenix.apache.org/cursors.html) - and for the majority of cases it works great and makes my life a lot easier (thanks for implementing them). However, in very rare cases (fiendishly rare cases), I get

Re: Phoenix CsvBulkLoadTool fails with java.sql.SQLException: ERROR 103 (08004): Unable to establish connection

2018-08-21 Thread Josh Elser
Btw, this is covered in the HBase book: http://hbase.apache.org/book.html#hadoop The reality is that HBase 2.x will work with Hadoop 3. The "unsupported" tag is more expressing that it not ready for "production". On 8/21/18 2:23 AM, Jaanai Zhang wrote: Caused by:

Re: Disable NO_CACHE hint on query for LIMIT OFFSET paging queries

2018-08-21 Thread Abhishek Gupta
Hi, Could you help me understand how LIMIT OFFSET queries work under the hood in Phoenix, is the filtering out of rows done in heap or is there some sort of optimisation where it can skip at disk level. My idea about posting this question was to understand if the rows from paste pages of the

Re: CursorUtil -> mapCursorIDQuery

2018-08-21 Thread Josh Elser
Hi Jack, Given your assessment, it sounds like you've stumbled onto a race condition! Thanks for bringing it to our attention. A few questions: * Have you checked if the same code exist in the latest branches/releases (4.x-HBase-1.{2,3,4} or master)? * Want to create a Jira issue to track

Re: Disable NO_CACHE hint on query for LIMIT OFFSET paging queries

2018-08-21 Thread Thomas D'Silva
When you do an OFFSET Phoenix will scan rows and filter them out until it reaches the offset count which can end up being very costly for large offsets. If you can use a RVC where the order matches the PK of the data table or index the start key of the scan will be set based on the RVC, which is

Re: CursorUtil -> mapCursorIDQuery

2018-08-21 Thread Jack Steenkamp
Hi Josh, Glad I could help. The CursorUtil class it seems has not changed since it was first created as part of PHOENIX-3572 - and is still the same in master (I checked a bit earlier). Sure - will have a go at creating a JIRA for this. Regards, On Tue, 21 Aug 2018 at 16:23, Josh Elser wrote:

Re: CursorUtil -> mapCursorIDQuery

2018-08-21 Thread Jack Steenkamp
Hi Josh, I've created https://issues.apache.org/jira/browse/PHOENIX-4860 for this. Thanks, On Tue, 21 Aug 2018 at 16:34, Jack Steenkamp wrote: > > Hi Josh, > > Glad I could help. The CursorUtil class it seems has not changed since > it was first created as part of PHOENIX-3572 - and is still

Re: CursorUtil -> mapCursorIDQuery

2018-08-21 Thread Josh Elser
Thanks sir! Will take a look up there and continue. On 8/21/18 11:48 AM, Jack Steenkamp wrote: Hi Josh, I've created https://issues.apache.org/jira/browse/PHOENIX-4860 for this. Thanks, On Tue, 21 Aug 2018 at 16:34, Jack Steenkamp wrote: Hi Josh, Glad I could help. The CursorUtil class it