[jira] [Updated] (PHOENIX-777) Support null value for fixed length ARRAY
[ https://issues.apache.org/jira/browse/PHOENIX-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated PHOENIX-777: --- Attachment: PHOENIX-777_addendumfor_testfailure.patch Addendum for test failure. > Support null value for fixed length ARRAY > - > > Key: PHOENIX-777 > URL: https://issues.apache.org/jira/browse/PHOENIX-777 > Project: Phoenix > Issue Type: Task >Reporter: James Taylor >Assignee: Dumindu Buddhika > Fix For: 4.4.0 > > Attachments: PHOENIX-777.patch, > PHOENIX-777_addendumfor_testfailure.patch > > > A null value for a fixed length array can be handled with a bitset tacked on > the end of the array. If an element is set to null, then the bit at that > index is set. Trailing nulls are not stored and an attempt to access an array > past the current size returns null. > Current behavior, > PBinaryArray - Throws an exception when a null is inserted. > PBooleanArray - null is considered as false when a null is inserted. > PCharArray - Throws an exception when a null is inserted. > PDateArray - Throws an exception when a null is inserted. > PDoubleArray - null is considered as 0.0 when a null is inserted. > PFloatArray - null is considered as 0.0 when a null is inserted. > PIntegerArray - null is considered as 0 when a null is inserted. > PLongArray - null is considered as 0 when a null is inserted. > PSmallIntArray - null is considered as 0 when a null is inserted. > PTimeArray - Throws an exception when a null is inserted. > PTimeStampArray - Throws an exception when a null is inserted. > PTinyIntArray - null is considered as 0 when a null is inserted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-777) Support null value for fixed length ARRAY
[ https://issues.apache.org/jira/browse/PHOENIX-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568590#comment-14568590 ] ramkrishna.s.vasudevan commented on PHOENIX-777: There is one test failing. Looking into it. > Support null value for fixed length ARRAY > - > > Key: PHOENIX-777 > URL: https://issues.apache.org/jira/browse/PHOENIX-777 > Project: Phoenix > Issue Type: Task >Reporter: James Taylor >Assignee: Dumindu Buddhika > Fix For: 4.4.0 > > Attachments: PHOENIX-777.patch > > > A null value for a fixed length array can be handled with a bitset tacked on > the end of the array. If an element is set to null, then the bit at that > index is set. Trailing nulls are not stored and an attempt to access an array > past the current size returns null. > Current behavior, > PBinaryArray - Throws an exception when a null is inserted. > PBooleanArray - null is considered as false when a null is inserted. > PCharArray - Throws an exception when a null is inserted. > PDateArray - Throws an exception when a null is inserted. > PDoubleArray - null is considered as 0.0 when a null is inserted. > PFloatArray - null is considered as 0.0 when a null is inserted. > PIntegerArray - null is considered as 0 when a null is inserted. > PLongArray - null is considered as 0 when a null is inserted. > PSmallIntArray - null is considered as 0 when a null is inserted. > PTimeArray - Throws an exception when a null is inserted. > PTimeStampArray - Throws an exception when a null is inserted. > PTinyIntArray - null is considered as 0 when a null is inserted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1987) SIGN built-in function should be order preserving
[
https://issues.apache.org/jira/browse/PHOENIX-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568587#comment-14568587
]
Shuxiong Ye commented on PHOENIX-1987:
--
Hi [~jamestaylor], PHOENIX-1986 PHOENIX-1987 PHOENIX-2015 PHOENIX-2018
PHOENIX-2019 PHOENIX-2020 is ready now.
Please help me to review them. : )
Thanks.
> SIGN built-in function should be order preserving
> -
>
> Key: PHOENIX-1987
> URL: https://issues.apache.org/jira/browse/PHOENIX-1987
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Shuxiong Ye
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments:
> 0001-PHOENIX-1987-SIGN-built-in-function-should-be-order-.patch
>
>
> The SIGN built-in function preserves the order of its input. This needs to be
> explicitly implemented in SignFunction by implementing the following method:
> {code}
> public OrderPreserving preservesOrder() {
> return OrderPreserving.YES;
> }
> {code}
> This will allow certain optimizations reducing the amount of memory and/or
> buffering that is required if SIGN is used in a GROUP BY or ORDER BY clause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-777) Support null value for fixed length ARRAY
[ https://issues.apache.org/jira/browse/PHOENIX-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568583#comment-14568583 ] Hudson commented on PHOENIX-777: FAILURE: Integrated in Phoenix-master #776 (See [https://builds.apache.org/job/Phoenix-master/776/]) PHOENIX-777 Support null value for fixed length ARRAY (Dumindu Buddhika) (ramkrishna: rev 7f6bf10b2cc54279b9210772323dc8f4d2939a19) * phoenix-core/src/main/java/org/apache/phoenix/compile/ExpressionCompiler.java * phoenix-core/src/main/java/org/apache/phoenix/schema/types/PDate.java * phoenix-core/src/main/java/org/apache/phoenix/schema/types/PTimestamp.java * phoenix-core/src/main/java/org/apache/phoenix/schema/types/PChar.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/ArraysWithNullsIT.java * phoenix-core/src/main/java/org/apache/phoenix/schema/types/PDecimal.java * phoenix-core/src/main/java/org/apache/phoenix/schema/types/PBinary.java * phoenix-core/src/main/java/org/apache/phoenix/schema/types/PhoenixArray.java > Support null value for fixed length ARRAY > - > > Key: PHOENIX-777 > URL: https://issues.apache.org/jira/browse/PHOENIX-777 > Project: Phoenix > Issue Type: Task >Reporter: James Taylor >Assignee: Dumindu Buddhika > Fix For: 4.4.0 > > Attachments: PHOENIX-777.patch > > > A null value for a fixed length array can be handled with a bitset tacked on > the end of the array. If an element is set to null, then the bit at that > index is set. Trailing nulls are not stored and an attempt to access an array > past the current size returns null. > Current behavior, > PBinaryArray - Throws an exception when a null is inserted. > PBooleanArray - null is considered as false when a null is inserted. > PCharArray - Throws an exception when a null is inserted. > PDateArray - Throws an exception when a null is inserted. > PDoubleArray - null is considered as 0.0 when a null is inserted. > PFloatArray - null is considered as 0.0 when a null is inserted. > PIntegerArray - null is considered as 0 when a null is inserted. > PLongArray - null is considered as 0 when a null is inserted. > PSmallIntArray - null is considered as 0 when a null is inserted. > PTimeArray - Throws an exception when a null is inserted. > PTimeStampArray - Throws an exception when a null is inserted. > PTinyIntArray - null is considered as 0 when a null is inserted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-777) Support null value for fixed length ARRAY
[ https://issues.apache.org/jira/browse/PHOENIX-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568582#comment-14568582 ] ramkrishna.s.vasudevan commented on PHOENIX-777: Pushed to master, 4.x and 4.4 branches as this patch is a bug fix. The implementation of handling nulls can go to 4.5.x branches alone when we do that JIRA. Thanks for the patch [~Dumindux]. Thanks for the reviews and feed back [~alexdl], [~kathir] and finally [~giacomotaylor]. > Support null value for fixed length ARRAY > - > > Key: PHOENIX-777 > URL: https://issues.apache.org/jira/browse/PHOENIX-777 > Project: Phoenix > Issue Type: Task >Reporter: James Taylor >Assignee: Dumindu Buddhika > Fix For: 4.4.0 > > Attachments: PHOENIX-777.patch > > > A null value for a fixed length array can be handled with a bitset tacked on > the end of the array. If an element is set to null, then the bit at that > index is set. Trailing nulls are not stored and an attempt to access an array > past the current size returns null. > Current behavior, > PBinaryArray - Throws an exception when a null is inserted. > PBooleanArray - null is considered as false when a null is inserted. > PCharArray - Throws an exception when a null is inserted. > PDateArray - Throws an exception when a null is inserted. > PDoubleArray - null is considered as 0.0 when a null is inserted. > PFloatArray - null is considered as 0.0 when a null is inserted. > PIntegerArray - null is considered as 0 when a null is inserted. > PLongArray - null is considered as 0 when a null is inserted. > PSmallIntArray - null is considered as 0 when a null is inserted. > PTimeArray - Throws an exception when a null is inserted. > PTimeStampArray - Throws an exception when a null is inserted. > PTinyIntArray - null is considered as 0 when a null is inserted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-777) Support null value for fixed length ARRAY
[ https://issues.apache.org/jira/browse/PHOENIX-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568575#comment-14568575 ] James Taylor commented on PHOENIX-777: -- [~ram_krish], [~rajeshbabu] - would be good to get this into 4.4.1 too IMHO. > Support null value for fixed length ARRAY > - > > Key: PHOENIX-777 > URL: https://issues.apache.org/jira/browse/PHOENIX-777 > Project: Phoenix > Issue Type: Task >Reporter: James Taylor >Assignee: Dumindu Buddhika > Fix For: 4.4.0 > > Attachments: PHOENIX-777.patch > > > A null value for a fixed length array can be handled with a bitset tacked on > the end of the array. If an element is set to null, then the bit at that > index is set. Trailing nulls are not stored and an attempt to access an array > past the current size returns null. > Current behavior, > PBinaryArray - Throws an exception when a null is inserted. > PBooleanArray - null is considered as false when a null is inserted. > PCharArray - Throws an exception when a null is inserted. > PDateArray - Throws an exception when a null is inserted. > PDoubleArray - null is considered as 0.0 when a null is inserted. > PFloatArray - null is considered as 0.0 when a null is inserted. > PIntegerArray - null is considered as 0 when a null is inserted. > PLongArray - null is considered as 0 when a null is inserted. > PSmallIntArray - null is considered as 0 when a null is inserted. > PTimeArray - Throws an exception when a null is inserted. > PTimeStampArray - Throws an exception when a null is inserted. > PTinyIntArray - null is considered as 0 when a null is inserted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1118) Provide a tool for visualizing Phoenix tracing information
[ https://issues.apache.org/jira/browse/PHOENIX-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568503#comment-14568503 ] Nishani commented on PHOENIX-1118: --- Hi, As we discussed I have used Jetty Server. The code is in the repo [1]. The screenshot of the tracing web app is attached. Here I have used AngularJS and Bootstrap. Regarding the implementation details you can find in my blog. [1] https://github.com/AyolaJayamaha/TracingWebApp > Provide a tool for visualizing Phoenix tracing information > -- > > Key: PHOENIX-1118 > URL: https://issues.apache.org/jira/browse/PHOENIX-1118 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor >Assignee: Nishani > Labels: Java, SQL, Visualization, gsoc2015, mentor > Attachments: MockUp1-TimeSlider.png, MockUp2-AdvanceSearch.png, > MockUp3-PatternDetector.png, MockUp4-FlameGraph.png, screenshot of tracing > web app.png > > > Currently there's no means of visualizing the trace information provided by > Phoenix. We should provide some simple charting over our metrics tables. Take > a look at the following JIRA for sample queries: > https://issues.apache.org/jira/browse/PHOENIX-1115?focusedCommentId=14323151&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14323151 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1118) Provide a tool for visualizing Phoenix tracing information
[ https://issues.apache.org/jira/browse/PHOENIX-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nishani updated PHOENIX-1118: -- Attachment: screenshot of tracing web app.png > Provide a tool for visualizing Phoenix tracing information > -- > > Key: PHOENIX-1118 > URL: https://issues.apache.org/jira/browse/PHOENIX-1118 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor >Assignee: Nishani > Labels: Java, SQL, Visualization, gsoc2015, mentor > Attachments: MockUp1-TimeSlider.png, MockUp2-AdvanceSearch.png, > MockUp3-PatternDetector.png, MockUp4-FlameGraph.png, screenshot of tracing > web app.png > > > Currently there's no means of visualizing the trace information provided by > Phoenix. We should provide some simple charting over our metrics tables. Take > a look at the following JIRA for sample queries: > https://issues.apache.org/jira/browse/PHOENIX-1115?focusedCommentId=14323151&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14323151 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1990) bin/queryserver makeWinServiceDesc doesn't actually work in Windows
[
https://issues.apache.org/jira/browse/PHOENIX-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568370#comment-14568370
]
Rajeshbabu Chintaguntla commented on PHOENIX-1990:
--
Thank you very much [~ndimiduk] for pushing the patches for 4.4 branches.
> bin/queryserver makeWinServiceDesc doesn't actually work in Windows
> ---
>
> Key: PHOENIX-1990
> URL: https://issues.apache.org/jira/browse/PHOENIX-1990
> Project: Phoenix
> Issue Type: Bug
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments: win.patch
>
>
> This approach requires parsing {{hbase-env.cmd}}, which my previous patch
> didn't do at all.
> {noformat}
> C:\Users\ndimiduk>c:\phoenix\bin\queryserver.py makeWinServiceDesc
> Traceback (most recent call last):
> File "C:\phoenix\bin\queryserver.py", line 85, in
> p = subprocess.Popen(['bash', '-c', 'source %s && env' % hbase_env_path],
> stdout = subprocess.PIPE)
> File "C:\Python27\lib\subprocess.py", line 679, in __init__
> errread, errwrite)
> File "C:\Python27\lib\subprocess.py", line 896, in _execute_child
> startupinfo)
> WindowsError: [Error 2] The system cannot find the file specified
> {noformat}
> hat-tip to [~hhuang2014] for finding this one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1984) Return value of INSTR should be one-based instead of zero-based
[ https://issues.apache.org/jira/browse/PHOENIX-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568368#comment-14568368 ] Rajeshbabu Chintaguntla commented on PHOENIX-1984: -- Thanks [~jamestaylor]. > Return value of INSTR should be one-based instead of zero-based > --- > > Key: PHOENIX-1984 > URL: https://issues.apache.org/jira/browse/PHOENIX-1984 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor >Assignee: Naveen Madhire > Fix For: 5.0.0, 4.5.0, 4.4.1 > > > String functions in SQL are one-based, not zero-based. One should be added to > the return value of the INSTR function as it's returning a zero-based return > value current. > We'll hold off on documenting this built-in until this is corrected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2012) RowKeyComparisonFilter logs unencoded data at DEBUG level
[ https://issues.apache.org/jira/browse/PHOENIX-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568291#comment-14568291 ] Hudson commented on PHOENIX-2012: - SUCCESS: Integrated in Phoenix-master #775 (See [https://builds.apache.org/job/Phoenix-master/775/]) PHOENIX-2012 RowKeyComparisonFilter logs unencoded data at DEBUG level (ndimiduk: rev 9e686b758ff735fd9129430cd31fe36993b9711b) * phoenix-core/src/main/java/org/apache/phoenix/filter/RowKeyComparisonFilter.java > RowKeyComparisonFilter logs unencoded data at DEBUG level > - > > Key: PHOENIX-2012 > URL: https://issues.apache.org/jira/browse/PHOENIX-2012 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.4.0 >Reporter: Nick Dimiduk >Assignee: Nick Dimiduk >Priority: Minor > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2012.00.patch > > > Noticed this while running verification tests. Occasionally the printed tuple > is interpreted by the shell and mangles the output for the rest of the test. > IF we're going to log data at all, should really be passing values through > some kind of ascii encoder. Also, don't print values, and or only do it at > TRACE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Mondrian with Phoenix
Yes, please still file a JIRA (ideally with a simple reproducer).
Thanks!
James
On Thu, May 28, 2015 at 11:06 PM, divye sheth wrote:
> I was able to get the IN operator working on STRING's. The issue was on my
> end, while creating the table I used CHAR instead of VARCHAR as the
> datatype.
>
> The IN operator works fine when the datatype is VARCHAR but fails to return
> a value if it is CHAR. Mondrian returns a result with values when VARCHAR
> is used but the issue persists when used with CHAR. I verified one another
> thing, if I have a single character in the field declared as CHAR(50) the
> IN operator works fine, also it works well when there is only one string in
> the CHAR(50) field.
>
> Should I still go ahead and raise a Jira?
>
> Thanks!
> Divye Sheth
>
> On Thu, May 28, 2015 at 11:14 PM, James Taylor
> wrote:
>
>> Please file a JIRA if you haven't already (ideally with a reproducible test
>> case).
>> Thanks,
>> James
>>
>> On Thursday, May 28, 2015, Marek Wiewiorka
>> wrote:
>>
>> > Hi,
>> > I experienced exactly the same issue yesterday.
>> > I tried to run query with IN operator - I tested it in sqlline and it was
>> > fine.
>> > When I tried to run it over jdbc I got strange exception in the log.
>> > I end up rewriting the query into series of conditions joined with AND/OR
>> > operators.
>> >
>> > Marek
>> >
>> > 2015-05-28 11:47 GMT+02:00 divye sheth > > >:
>> >
>> > > Hi,
>> > >
>> > > I am trying to integrate Mondrian with Phoenix and face some issues:
>> > > Mondrian version: 4.3
>> > > Phoenix Version: 4.4
>> > > Hbase: 0.98
>> > >
>> > > Mondrian is able to get data from Phoenix in most of the cases but
>> fails
>> > > when there is an IN operator involved.
>> > >
>> > > I verified using the sqlline cli, Phoenix works fine when the IN clause
>> > is
>> > > applied to INTEGERS or one STRING
>> > > e.g.
>> > > select emp_id from employee where emp_id IN (1,2,3,4); //this works
>> fine
>> > >
>> > > select name from employee where name IN ('divye'); //even this works
>> fine
>> > >
>> > > *select name from employee where name IN ('divye', 'sheth');* //no
>> result
>> > > returned
>> > >
>> > > when a list of STRINGs are given to the IN clause, phoenix does not
>> > return
>> > > any result. I have verified that the values are present and are in
>> proper
>> > > case as well.
>> > >
>> > > I am trying to figure out how mondrian generates sql from mdx so that I
>> > can
>> > > modify the IN clause to a series of OR conditions, so far I have not
>> been
>> > > able to figure that out.
>> > >
>> > > In the meantime if someone can throw some light on how can I have
>> phoenix
>> > > accept STRINGS in the IN clause that would be very helpful.
>> > >
>> > > Thanks
>> > > Divye Sheth
>> > >
>> >
>>
[jira] [Commented] (PHOENIX-1984) Return value of INSTR should be one-based instead of zero-based
[ https://issues.apache.org/jira/browse/PHOENIX-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568229#comment-14568229 ] James Taylor commented on PHOENIX-1984: --- [~rajeshbabu] - pushed this to 4.4 branches as well so that we can surface INSTR built-in > Return value of INSTR should be one-based instead of zero-based > --- > > Key: PHOENIX-1984 > URL: https://issues.apache.org/jira/browse/PHOENIX-1984 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor >Assignee: Naveen Madhire > Fix For: 5.0.0, 4.5.0, 4.4.1 > > > String functions in SQL are one-based, not zero-based. One should be added to > the return value of the INSTR function as it's returning a zero-based return > value current. > We'll hold off on documenting this built-in until this is corrected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2023) Build tgz only on release profile
Nick Dimiduk created PHOENIX-2023: - Summary: Build tgz only on release profile Key: PHOENIX-2023 URL: https://issues.apache.org/jira/browse/PHOENIX-2023 Project: Phoenix Issue Type: Improvement Reporter: Nick Dimiduk We should follow [~enis]'s lead on HBASE-13816 and save everyone some time on the build cycle by moving some (all?) of the assembly bits to a release profile that's only invoked at RC time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1984) Return value of INSTR should be one-based instead of zero-based
[ https://issues.apache.org/jira/browse/PHOENIX-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-1984: -- Fix Version/s: 4.4.1 4.5.0 5.0.0 > Return value of INSTR should be one-based instead of zero-based > --- > > Key: PHOENIX-1984 > URL: https://issues.apache.org/jira/browse/PHOENIX-1984 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor >Assignee: Naveen Madhire > Fix For: 5.0.0, 4.5.0, 4.4.1 > > > String functions in SQL are one-based, not zero-based. One should be added to > the return value of the INSTR function as it's returning a zero-based return > value current. > We'll hold off on documenting this built-in until this is corrected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PHOENIX-1962) Apply check style to the build
[ https://issues.apache.org/jira/browse/PHOENIX-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk resolved PHOENIX-1962. --- Resolution: Fixed Pushed to 4.x-HBase-1.1. > Apply check style to the build > -- > > Key: PHOENIX-1962 > URL: https://issues.apache.org/jira/browse/PHOENIX-1962 > Project: Phoenix > Issue Type: Task >Reporter: Nick Dimiduk >Assignee: Nick Dimiduk > Fix For: 5.0.0, 4.5.0 > > Attachments: PHOENIX-1962.00.patch, PHOENIX-1962.01.patch > > > Let's enforce our code style and structure at compile time in maven instead > of via IDE integration that isn't applied universally. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (PHOENIX-1962) Apply check style to the build
[ https://issues.apache.org/jira/browse/PHOENIX-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk reopened PHOENIX-1962: --- Looks like this is missing from 4.x-HBase-1.1. Thanks for the heads up [~chrajeshbab...@gmail.com]. > Apply check style to the build > -- > > Key: PHOENIX-1962 > URL: https://issues.apache.org/jira/browse/PHOENIX-1962 > Project: Phoenix > Issue Type: Task >Reporter: Nick Dimiduk >Assignee: Nick Dimiduk > Fix For: 5.0.0, 4.5.0 > > Attachments: PHOENIX-1962.00.patch, PHOENIX-1962.01.patch > > > Let's enforce our code style and structure at compile time in maven instead > of via IDE integration that isn't applied universally. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PHOENIX-1976) Improve PhoenixDriver registration when addShutdownHook fails
[
https://issues.apache.org/jira/browse/PHOENIX-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk resolved PHOENIX-1976.
---
Resolution: Fixed
Fix Version/s: 4.4.1
Master patch applied cleanly across the board. Thanks for keeping an eye out
[~elserj].
> Improve PhoenixDriver registration when addShutdownHook fails
> -
>
> Key: PHOENIX-1976
> URL: https://issues.apache.org/jira/browse/PHOENIX-1976
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments: PHOENIX-1976-master.patch
>
>
> Noticed this in running some tests. RegionServer was shutting down and
> MetaDataRegionObserver was just invoking {{postOpen}}
> When the {{Class.forName(PhoenixDriver.class.getName())}} gets called, the
> static initializer in {{PhoenixDriver}} gets invoked. Because the
> RegionServer is already stopping, the {{addShutdownHook}} fails with an
> {{IllegalArgumentException}}.
> It's not a _huge_ concern because we know the JVM is going down, but there
> are a few things we could handle better:
> * Ensure the PhoenixDriver gets closed if the shutdown hook fails to register
> * Avoid registering the PhoenixDriver instance if we're shutting down
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1976) Improve PhoenixDriver registration when addShutdownHook fails
[
https://issues.apache.org/jira/browse/PHOENIX-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567822#comment-14567822
]
Josh Elser commented on PHOENIX-1976:
-
LMK if the patch doesn't apply cleanly. Happy to send you a fresh one for
4.x-HBase-1.1 if needed.
> Improve PhoenixDriver registration when addShutdownHook fails
> -
>
> Key: PHOENIX-1976
> URL: https://issues.apache.org/jira/browse/PHOENIX-1976
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 5.0.0, 4.5.0
>
> Attachments: PHOENIX-1976-master.patch
>
>
> Noticed this in running some tests. RegionServer was shutting down and
> MetaDataRegionObserver was just invoking {{postOpen}}
> When the {{Class.forName(PhoenixDriver.class.getName())}} gets called, the
> static initializer in {{PhoenixDriver}} gets invoked. Because the
> RegionServer is already stopping, the {{addShutdownHook}} fails with an
> {{IllegalArgumentException}}.
> It's not a _huge_ concern because we know the JVM is going down, but there
> are a few things we could handle better:
> * Ensure the PhoenixDriver gets closed if the shutdown hook fails to register
> * Avoid registering the PhoenixDriver instance if we're shutting down
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (PHOENIX-1976) Improve PhoenixDriver registration when addShutdownHook fails
[
https://issues.apache.org/jira/browse/PHOENIX-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk reopened PHOENIX-1976:
---
Reopening for the 1.1 branches (it's not on 4.x-HBase-1.1) and 4.4 branches.
> Improve PhoenixDriver registration when addShutdownHook fails
> -
>
> Key: PHOENIX-1976
> URL: https://issues.apache.org/jira/browse/PHOENIX-1976
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 5.0.0, 4.5.0
>
> Attachments: PHOENIX-1976-master.patch
>
>
> Noticed this in running some tests. RegionServer was shutting down and
> MetaDataRegionObserver was just invoking {{postOpen}}
> When the {{Class.forName(PhoenixDriver.class.getName())}} gets called, the
> static initializer in {{PhoenixDriver}} gets invoked. Because the
> RegionServer is already stopping, the {{addShutdownHook}} fails with an
> {{IllegalArgumentException}}.
> It's not a _huge_ concern because we know the JVM is going down, but there
> are a few things we could handle better:
> * Ensure the PhoenixDriver gets closed if the shutdown hook fails to register
> * Avoid registering the PhoenixDriver instance if we're shutting down
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PHOENIX-1990) bin/queryserver makeWinServiceDesc doesn't actually work in Windows
[
https://issues.apache.org/jira/browse/PHOENIX-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk resolved PHOENIX-1990.
---
Resolution: Fixed
Fix Version/s: 4.4.1
Pushed to 4.4 branches. Thanks for the reminder [~chrajeshbab...@gmail.com].
> bin/queryserver makeWinServiceDesc doesn't actually work in Windows
> ---
>
> Key: PHOENIX-1990
> URL: https://issues.apache.org/jira/browse/PHOENIX-1990
> Project: Phoenix
> Issue Type: Bug
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments: win.patch
>
>
> This approach requires parsing {{hbase-env.cmd}}, which my previous patch
> didn't do at all.
> {noformat}
> C:\Users\ndimiduk>c:\phoenix\bin\queryserver.py makeWinServiceDesc
> Traceback (most recent call last):
> File "C:\phoenix\bin\queryserver.py", line 85, in
> p = subprocess.Popen(['bash', '-c', 'source %s && env' % hbase_env_path],
> stdout = subprocess.PIPE)
> File "C:\Python27\lib\subprocess.py", line 679, in __init__
> errread, errwrite)
> File "C:\Python27\lib\subprocess.py", line 896, in _execute_child
> startupinfo)
> WindowsError: [Error 2] The system cannot find the file specified
> {noformat}
> hat-tip to [~hhuang2014] for finding this one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (PHOENIX-1990) bin/queryserver makeWinServiceDesc doesn't actually work in Windows
[
https://issues.apache.org/jira/browse/PHOENIX-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk reopened PHOENIX-1990:
---
Reopening to apply to 4.4 branches.
> bin/queryserver makeWinServiceDesc doesn't actually work in Windows
> ---
>
> Key: PHOENIX-1990
> URL: https://issues.apache.org/jira/browse/PHOENIX-1990
> Project: Phoenix
> Issue Type: Bug
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
> Fix For: 5.0.0, 4.5.0
>
> Attachments: win.patch
>
>
> This approach requires parsing {{hbase-env.cmd}}, which my previous patch
> didn't do at all.
> {noformat}
> C:\Users\ndimiduk>c:\phoenix\bin\queryserver.py makeWinServiceDesc
> Traceback (most recent call last):
> File "C:\phoenix\bin\queryserver.py", line 85, in
> p = subprocess.Popen(['bash', '-c', 'source %s && env' % hbase_env_path],
> stdout = subprocess.PIPE)
> File "C:\Python27\lib\subprocess.py", line 679, in __init__
> errread, errwrite)
> File "C:\Python27\lib\subprocess.py", line 896, in _execute_child
> startupinfo)
> WindowsError: [Error 2] The system cannot find the file specified
> {noformat}
> hat-tip to [~hhuang2014] for finding this one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PHOENIX-1963) Irregular failures in ResultTest#testMonitorResult
[
https://issues.apache.org/jira/browse/PHOENIX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajeshbabu Chintaguntla updated PHOENIX-1963:
-
Fix Version/s: (was: 4.1.1)
4.4.1
> Irregular failures in ResultTest#testMonitorResult
> --
>
> Key: PHOENIX-1963
> URL: https://issues.apache.org/jira/browse/PHOENIX-1963
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.4.0
>Reporter: Gabriel Reid
>Assignee: Cody Marcel
> Fix For: 5.0.0, 4.4.0, 4.5.0, 4.4.1
>
> Attachments: PHOENIX-1963-master.patch, PHOENIX-1963.patch,
> PHOENIX-1963.patch
>
>
> While validating the 4.4.0 release candidates, I had to run the phoenix-pherf
> test cases a number of times to get them to pass.
> The offending test was ResultTest#testMonitorResult. I was running the test
> via {{maven clean install}}, and getting results such as the following:
> {code}
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 6.034 sec <<<
> FAILURE! - in org.apache.phoenix.pherf.ResultTest
> testMonitorResult(org.apache.phoenix.pherf.ResultTest) Time elapsed: 4.363
> sec <<< FAILURE!
> java.lang.AssertionError: Failed to get correct amount of CSV records.
> expected:<243> but was:<261>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.apache.phoenix.pherf.ResultTest.testMonitorResult(ResultTest.java:99)
> {code}
> An important thing to point out is that I was encountering this issue on a
> single-CPU virtual machine, so if there are some sensitive timing issues then
> they might be tickled by my setup.
> A quick look at the code doesn't show any directly obvious causes for this,
> but I did notice in the MonitorManager class that the resultHandler instance
> variable is protected via itself as a monitor in the run method, and
> protected by the this monitor in the readResults method. I'm not sure if this
> has anything to do with the underlying issue, but it does seem a bit
> questionable (i.e. different monitors are being used to lock access to a
> single variable).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1963) Irregular failures in ResultTest#testMonitorResult
[
https://issues.apache.org/jira/browse/PHOENIX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567785#comment-14567785
]
Rajeshbabu Chintaguntla commented on PHOENIX-1963:
--
[~cody.mar...@gmail.com] can you check whether it's committed to 4.4 branches
if not please commit. Thanks
> Irregular failures in ResultTest#testMonitorResult
> --
>
> Key: PHOENIX-1963
> URL: https://issues.apache.org/jira/browse/PHOENIX-1963
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.4.0
>Reporter: Gabriel Reid
>Assignee: Cody Marcel
> Fix For: 5.0.0, 4.4.0, 4.5.0, 4.4.1
>
> Attachments: PHOENIX-1963-master.patch, PHOENIX-1963.patch,
> PHOENIX-1963.patch
>
>
> While validating the 4.4.0 release candidates, I had to run the phoenix-pherf
> test cases a number of times to get them to pass.
> The offending test was ResultTest#testMonitorResult. I was running the test
> via {{maven clean install}}, and getting results such as the following:
> {code}
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 6.034 sec <<<
> FAILURE! - in org.apache.phoenix.pherf.ResultTest
> testMonitorResult(org.apache.phoenix.pherf.ResultTest) Time elapsed: 4.363
> sec <<< FAILURE!
> java.lang.AssertionError: Failed to get correct amount of CSV records.
> expected:<243> but was:<261>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.apache.phoenix.pherf.ResultTest.testMonitorResult(ResultTest.java:99)
> {code}
> An important thing to point out is that I was encountering this issue on a
> single-CPU virtual machine, so if there are some sensitive timing issues then
> they might be tickled by my setup.
> A quick look at the code doesn't show any directly obvious causes for this,
> but I did notice in the MonitorManager class that the resultHandler instance
> variable is protected via itself as a monitor in the run method, and
> protected by the this monitor in the readResults method. I'm not sure if this
> has anything to do with the underlying issue, but it does seem a bit
> questionable (i.e. different monitors are being used to lock access to a
> single variable).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
PhoenixIOException resolved only after compaction, is there a way to avoid it?
Hi Everyone, We load the data to Hbase tables through BulkImports. If the data set is small, we can query the imported data from phoenix with no issues. If data size is huge (with respect to our cluster, we have very small cluster), I m encountering the following error (org.apache.phoenix.exception.PhoenixIOException). 0: jdbc:phoenix:172.31.45.176:2181:/hbase> selectcount(*) . . . . . . . . . . . . . . . . . . . . .>from "ldll_compression" ldll join "ds_compression" ds on (ds."statusid" = ldll."statusid") . . . . . . . . . . . . . . . . . . . . .>where ldll."logdate" >= '2015-02-04' . . . . . . . . . . . . . . . . . . . . .>and ldll."logdate" <= '2015-02-06' . . . . . . . . . . . . . . . . . . . . .>and ldll."dbname" = 'lmguaranteedrate'; +--+ | COUNT(1) | +--+ java.lang.RuntimeException: org.apache.phoenix.exception.PhoenixIOException: org.apache.phoenix.exception.PhoenixIOException: Failed after attempts=36, exceptions: Mon Jun 01 13:50:57 EDT 2015, null, java.net.SocketTimeoutException: callTimeout=6, callDuration=62358: row '' on table 'ldll_compression' at region=ldll_compression,,1432851434288.1a8b511def7d0c9e69a5491c6330d715., hostname=ip-172-31-32-181.us-west-2.compute.internal,60020,1432768597149, seqNum=16566 at sqlline.SqlLine$IncrementalRows.hasNext(SqlLine.java:2440) at sqlline.SqlLine$TableOutputFormat.print(SqlLine.java:2074) at sqlline.SqlLine.print(SqlLine.java:1735) at sqlline.SqlLine$Commands.execute(SqlLine.java:3683) at sqlline.SqlLine$Commands.sql(SqlLine.java:3584) at sqlline.SqlLine.dispatch(SqlLine.java:821) at sqlline.SqlLine.begin(SqlLine.java:699) at sqlline.SqlLine.mainWithInputRedirection(SqlLine.java:441) at sqlline.SqlLine.main(SqlLine.java:424) I did the major compaction for "ldll_compression" through Hbase shell(major_compact 'ldll_compression'). Same query ran successfully after the compaction. 0: jdbc:phoenix:172.31.45.176:2181:/hbase> selectcount(*) . . . . . . . . . . . . . . . . . . . . .>from "ldll_compression" ldll join "ds_compression" ds on (ds."statusid" = ldll."statusid") . . . . . . . . . . . . . . . . . . . . .>where ldll."logdate" >= '2015-02-04' . . . . . . . . . . . . . . . . . . . . .>and ldll."logdate" <= '2015-02-06' . . . . . . . . . . . . . . . . . . . . .>and ldll."dbname" = 'lmguaranteedrate' . . . . . . . . . . . . . . . . . . . . .> ; +--+ | COUNT(1) | +--+ | 13480| +--+ 1 row selected (72.36 seconds) Did anyone face the similar issue? Is IO exception is because of Phoenix not able to read from multiple regions since error was resolved after the compaction? or Any other thoughts? Thanks, Siva.
[jira] [Updated] (PHOENIX-2020) Implement build-in math function EXP
[ https://issues.apache.org/jira/browse/PHOENIX-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuxiong Ye updated PHOENIX-2020: - Attachment: 0001-PHOENIX-2020-Implement-build-in-math-function-EXP.patch > Implement build-in math function EXP > > > Key: PHOENIX-2020 > URL: https://issues.apache.org/jira/browse/PHOENIX-2020 > Project: Phoenix > Issue Type: Sub-task >Reporter: Shuxiong Ye >Assignee: Shuxiong Ye > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: > 0001-PHOENIX-2020-Implement-build-in-math-function-EXP.patch > > > EXP is exponential function, and will be a special case of POWER function. > Examples show as below: > exp(dp) exponential exp(1.0)2.71828182845905 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2020) Implement build-in math function EXP
[ https://issues.apache.org/jira/browse/PHOENIX-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567534#comment-14567534 ] Shuxiong Ye commented on PHOENIX-2020: -- The patch above will firstly turn input to double type, and using java.lang.Math related functions to get the result. Note that, for both types BigDecimal and long, when type cast occurs from these two types to double, there will be a loss of precision. java.lang.Math is only support for double. > Implement build-in math function EXP > > > Key: PHOENIX-2020 > URL: https://issues.apache.org/jira/browse/PHOENIX-2020 > Project: Phoenix > Issue Type: Sub-task >Reporter: Shuxiong Ye >Assignee: Shuxiong Ye > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: > 0001-PHOENIX-2020-Implement-build-in-math-function-EXP.patch > > > EXP is exponential function, and will be a special case of POWER function. > Examples show as below: > exp(dp) exponential exp(1.0)2.71828182845905 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2022) BaseRegionScanner.next should be abstract
[ https://issues.apache.org/jira/browse/PHOENIX-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567531#comment-14567531 ] Hudson commented on PHOENIX-2022: - SUCCESS: Integrated in Phoenix-master #773 (See [https://builds.apache.org/job/Phoenix-master/773/]) PHOENIX-2022 Make BaseRegionScanner.next abstract (gabrielr: rev 583b5b1e115a81799cc3e6d0a20a0fe665f666e3) * phoenix-core/src/main/java/org/apache/phoenix/coprocessor/BaseRegionScanner.java > BaseRegionScanner.next should be abstract > - > > Key: PHOENIX-2022 > URL: https://issues.apache.org/jira/browse/PHOENIX-2022 > Project: Phoenix > Issue Type: Bug >Reporter: Gabriel Reid >Assignee: Gabriel Reid > Fix For: 4.5.0 > > Attachments: PHOENIX-2022.patch > > > As pointed out by Yuhao Bi on a [dev list mail|http://s.apache.org/y6b], > BaseRegionScanner implements next as a recursive call to itself. > All current subclasses of BaseRegionScanner implement next, but as soon as > there is an implementation that doesn't do this, it will end up with a stack > overflow. > Easy fix is to make this method abstract instead of having a default > recursive implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2018) Implement math build-in function SQRT
[ https://issues.apache.org/jira/browse/PHOENIX-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuxiong Ye updated PHOENIX-2018: - Attachment: (was: 0001-PHOENIX-2018-Implement-math-build-in-function-SQRT_v2.patch) > Implement math build-in function SQRT > - > > Key: PHOENIX-2018 > URL: https://issues.apache.org/jira/browse/PHOENIX-2018 > Project: Phoenix > Issue Type: Sub-task >Reporter: Shuxiong Ye >Assignee: Shuxiong Ye > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: > 0001-PHOENIX-2018-Implement-math-build-in-function-SQRT_v3.patch > > > # SQRT means square root. > # Return type will be PDouble > # OrderPreserving -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-777) Support null value for fixed length ARRAY
[ https://issues.apache.org/jira/browse/PHOENIX-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567494#comment-14567494 ] James Taylor commented on PHOENIX-777: -- +1. Thanks for the patch, [~Dumindux] & [~ram_krish]. > Support null value for fixed length ARRAY > - > > Key: PHOENIX-777 > URL: https://issues.apache.org/jira/browse/PHOENIX-777 > Project: Phoenix > Issue Type: Task >Reporter: James Taylor >Assignee: Dumindu Buddhika > Fix For: 4.4.0 > > Attachments: PHOENIX-777.patch > > > A null value for a fixed length array can be handled with a bitset tacked on > the end of the array. If an element is set to null, then the bit at that > index is set. Trailing nulls are not stored and an attempt to access an array > past the current size returns null. > Current behavior, > PBinaryArray - Throws an exception when a null is inserted. > PBooleanArray - null is considered as false when a null is inserted. > PCharArray - Throws an exception when a null is inserted. > PDateArray - Throws an exception when a null is inserted. > PDoubleArray - null is considered as 0.0 when a null is inserted. > PFloatArray - null is considered as 0.0 when a null is inserted. > PIntegerArray - null is considered as 0 when a null is inserted. > PLongArray - null is considered as 0 when a null is inserted. > PSmallIntArray - null is considered as 0 when a null is inserted. > PTimeArray - Throws an exception when a null is inserted. > PTimeStampArray - Throws an exception when a null is inserted. > PTinyIntArray - null is considered as 0 when a null is inserted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2018) Implement math build-in function SQRT
[ https://issues.apache.org/jira/browse/PHOENIX-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuxiong Ye updated PHOENIX-2018: - Attachment: 0001-PHOENIX-2018-Implement-math-build-in-function-SQRT_v3.patch > Implement math build-in function SQRT > - > > Key: PHOENIX-2018 > URL: https://issues.apache.org/jira/browse/PHOENIX-2018 > Project: Phoenix > Issue Type: Sub-task >Reporter: Shuxiong Ye >Assignee: Shuxiong Ye > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: > 0001-PHOENIX-2018-Implement-math-build-in-function-SQRT_v3.patch > > > # SQRT means square root. > # Return type will be PDouble > # OrderPreserving -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PHOENIX-2016) Some Phoenix tests failed with NPE
[ https://issues.apache.org/jira/browse/PHOENIX-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajeshbabu Chintaguntla resolved PHOENIX-2016. -- Resolution: Fixed Pushed to master and all 4.x,4.4 branches. > Some Phoenix tests failed with NPE > -- > > Key: PHOENIX-2016 > URL: https://issues.apache.org/jira/browse/PHOENIX-2016 > Project: Phoenix > Issue Type: Bug >Reporter: Alicia Ying Shu >Assignee: Alicia Ying Shu > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: Phoenix-2016.patch > > > Found a few NPEs in unit tests. > org.apache.phoenix.end2end.RegexpSplitFunctionIT Time elapsed: 0.002 sec <<< > ERROR! > java.lang.NullPointerException: null > at > org.apache.phoenix.query.BaseTest.disableAndDropNonSystemTables(BaseTest.java:1629) > at org.apache.phoenix.query.BaseTest.dropNonSystemTables(BaseTest.java:519) > at > org.apache.phoenix.end2end.BaseHBaseManagedTimeIT.doTeardown(BaseHBaseManagedTimeIT.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:107) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeLazy(JUnitCoreWrapper.java:88) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:57) > at > org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144) > at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2015) Implement Build-in math function CBRT
[ https://issues.apache.org/jira/browse/PHOENIX-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuxiong Ye updated PHOENIX-2015: - Attachment: (was: 0001-Implement-Build-in-math-function-CBRT.patch) > Implement Build-in math function CBRT > - > > Key: PHOENIX-2015 > URL: https://issues.apache.org/jira/browse/PHOENIX-2015 > Project: Phoenix > Issue Type: Sub-task >Reporter: Shuxiong Ye >Assignee: Shuxiong Ye > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: > 0001-PHOENIX-2015-Implement-Build-in-math-function-CBRT_v2.patch > > > Implement math build-in function cube root -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2016) Some Phoenix tests failed with NPE
[ https://issues.apache.org/jira/browse/PHOENIX-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajeshbabu Chintaguntla updated PHOENIX-2016: - Fix Version/s: 4.4.1 > Some Phoenix tests failed with NPE > -- > > Key: PHOENIX-2016 > URL: https://issues.apache.org/jira/browse/PHOENIX-2016 > Project: Phoenix > Issue Type: Bug >Reporter: Alicia Ying Shu >Assignee: Alicia Ying Shu > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: Phoenix-2016.patch > > > Found a few NPEs in unit tests. > org.apache.phoenix.end2end.RegexpSplitFunctionIT Time elapsed: 0.002 sec <<< > ERROR! > java.lang.NullPointerException: null > at > org.apache.phoenix.query.BaseTest.disableAndDropNonSystemTables(BaseTest.java:1629) > at org.apache.phoenix.query.BaseTest.dropNonSystemTables(BaseTest.java:519) > at > org.apache.phoenix.end2end.BaseHBaseManagedTimeIT.doTeardown(BaseHBaseManagedTimeIT.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:107) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeLazy(JUnitCoreWrapper.java:88) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:57) > at > org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144) > at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2015) Implement Build-in math function CBRT
[ https://issues.apache.org/jira/browse/PHOENIX-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuxiong Ye updated PHOENIX-2015: - Attachment: 0001-PHOENIX-2015-Implement-Build-in-math-function-CBRT_v2.patch > Implement Build-in math function CBRT > - > > Key: PHOENIX-2015 > URL: https://issues.apache.org/jira/browse/PHOENIX-2015 > Project: Phoenix > Issue Type: Sub-task >Reporter: Shuxiong Ye >Assignee: Shuxiong Ye > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: > 0001-PHOENIX-2015-Implement-Build-in-math-function-CBRT_v2.patch > > > Implement math build-in function cube root -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-777) Support null value for fixed length ARRAY
[ https://issues.apache.org/jira/browse/PHOENIX-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567465#comment-14567465 ] ramkrishna.s.vasudevan commented on PHOENIX-777: [~giacomotaylor] Want to have a look at this patch? > Support null value for fixed length ARRAY > - > > Key: PHOENIX-777 > URL: https://issues.apache.org/jira/browse/PHOENIX-777 > Project: Phoenix > Issue Type: Task >Reporter: James Taylor >Assignee: Dumindu Buddhika > Fix For: 4.4.0 > > Attachments: PHOENIX-777.patch > > > A null value for a fixed length array can be handled with a bitset tacked on > the end of the array. If an element is set to null, then the bit at that > index is set. Trailing nulls are not stored and an attempt to access an array > past the current size returns null. > Current behavior, > PBinaryArray - Throws an exception when a null is inserted. > PBooleanArray - null is considered as false when a null is inserted. > PCharArray - Throws an exception when a null is inserted. > PDateArray - Throws an exception when a null is inserted. > PDoubleArray - null is considered as 0.0 when a null is inserted. > PFloatArray - null is considered as 0.0 when a null is inserted. > PIntegerArray - null is considered as 0 when a null is inserted. > PLongArray - null is considered as 0 when a null is inserted. > PSmallIntArray - null is considered as 0 when a null is inserted. > PTimeArray - Throws an exception when a null is inserted. > PTimeStampArray - Throws an exception when a null is inserted. > PTinyIntArray - null is considered as 0 when a null is inserted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2018) Implement math build-in function SQRT
[ https://issues.apache.org/jira/browse/PHOENIX-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuxiong Ye updated PHOENIX-2018: - Attachment: (was: 0001-PHOENIX-2018-Implement-math-build-in-function-SQRT.patch) > Implement math build-in function SQRT > - > > Key: PHOENIX-2018 > URL: https://issues.apache.org/jira/browse/PHOENIX-2018 > Project: Phoenix > Issue Type: Sub-task >Reporter: Shuxiong Ye >Assignee: Shuxiong Ye > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: > 0001-PHOENIX-2018-Implement-math-build-in-function-SQRT_v2.patch > > > # SQRT means square root. > # Return type will be PDouble > # OrderPreserving -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2018) Implement math build-in function SQRT
[ https://issues.apache.org/jira/browse/PHOENIX-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuxiong Ye updated PHOENIX-2018: - Attachment: 0001-PHOENIX-2018-Implement-math-build-in-function-SQRT_v2.patch > Implement math build-in function SQRT > - > > Key: PHOENIX-2018 > URL: https://issues.apache.org/jira/browse/PHOENIX-2018 > Project: Phoenix > Issue Type: Sub-task >Reporter: Shuxiong Ye >Assignee: Shuxiong Ye > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: > 0001-PHOENIX-2018-Implement-math-build-in-function-SQRT_v2.patch > > > # SQRT means square root. > # Return type will be PDouble > # OrderPreserving -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2019) Implement Build-in math function ln and log
[ https://issues.apache.org/jira/browse/PHOENIX-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567436#comment-14567436 ] Shuxiong Ye commented on PHOENIX-2019: -- The patch above will firstly turn input to double type, and using java.lang.Math related functions to get the result. Note that, for both types BigDecimal and long, when type cast occurs from these two types to double, there will be a loss of precision. java.lang.Math is only support for double. > Implement Build-in math function ln and log > --- > > Key: PHOENIX-2019 > URL: https://issues.apache.org/jira/browse/PHOENIX-2019 > Project: Phoenix > Issue Type: Sub-task >Reporter: Shuxiong Ye >Assignee: Shuxiong Ye > Attachments: > 0001-PHOENIX-2019-Implement-Build-in-math-function-ln-and.patch > > > Implement math build-in function, ln and log. Example show as below: > ln(dp)natural logarithm ln(2.0) 0.693147180559945 > log(dp) base 10 logarithm log(100.0) 2 > log(b, x) numeric logarithm to base b log(2.0, 64.0) 6.00 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2019) Implement Build-in math function ln and log
[ https://issues.apache.org/jira/browse/PHOENIX-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuxiong Ye updated PHOENIX-2019: - Attachment: 0001-PHOENIX-2019-Implement-Build-in-math-function-ln-and.patch > Implement Build-in math function ln and log > --- > > Key: PHOENIX-2019 > URL: https://issues.apache.org/jira/browse/PHOENIX-2019 > Project: Phoenix > Issue Type: Sub-task >Reporter: Shuxiong Ye >Assignee: Shuxiong Ye > Attachments: > 0001-PHOENIX-2019-Implement-Build-in-math-function-ln-and.patch > > > Implement math build-in function, ln and log. Example show as below: > ln(dp)natural logarithm ln(2.0) 0.693147180559945 > log(dp) base 10 logarithm log(100.0) 2 > log(b, x) numeric logarithm to base b log(2.0, 64.0) 6.00 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2022) BaseRegionScanner.next should be abstract
[ https://issues.apache.org/jira/browse/PHOENIX-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Reid updated PHOENIX-2022: -- Fix Version/s: 4.5.0 > BaseRegionScanner.next should be abstract > - > > Key: PHOENIX-2022 > URL: https://issues.apache.org/jira/browse/PHOENIX-2022 > Project: Phoenix > Issue Type: Bug >Reporter: Gabriel Reid >Assignee: Gabriel Reid > Fix For: 4.5.0 > > Attachments: PHOENIX-2022.patch > > > As pointed out by Yuhao Bi on a [dev list mail|http://s.apache.org/y6b], > BaseRegionScanner implements next as a recursive call to itself. > All current subclasses of BaseRegionScanner implement next, but as soon as > there is an implementation that doesn't do this, it will end up with a stack > overflow. > Easy fix is to make this method abstract instead of having a default > recursive implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2007) java.sql.SQLException: Encountered exception in sub plan [0] execution
[ https://issues.apache.org/jira/browse/PHOENIX-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567422#comment-14567422 ] Maryann Xue commented on PHOENIX-2007: -- [~aliciashu] Thanks a lot for the finding and patch! Thank you, [~chrajeshbab...@gmail.com], for the review! > java.sql.SQLException: Encountered exception in sub plan [0] execution > -- > > Key: PHOENIX-2007 > URL: https://issues.apache.org/jira/browse/PHOENIX-2007 > Project: Phoenix > Issue Type: Bug >Reporter: Alicia Ying Shu >Assignee: Alicia Ying Shu > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: Phoenix-2007-v1.patch, Phoenix-2007.patch > > > During our tests, encountered NPE when there is no data in the table. > MainThread|2/2 SELECT * FROM (SELECT ID, BIG_ID, DATE_ID FROM > LARGE_TABLE AS A WHERE (A.ID % 5) = 0) AS A INNER JOIN (SELECT SEC_ID, > SEC_TINY_ID, SEC_UNSIG_FLOAT_ID FROM SECONDARY_LARGE_TABLE AS B WHERE > (B.SEC_ID % 5) = 0) AS B ON A.ID=B.SEC_ID WHERE A.DATE_ID > ALL (SELECT > SEC_DATE_ID FROM SECONDARY_LARGE_TABLE LIMIT 100) AND > B.SEC_UNSIG_FLOAT_ID = ANY (SELECT sec_unsig_float_id > FROM SECONDARY_LARGE_TABLE > WHERE SEC_ID > ALL (SELECT MIN (ID) FROM GRAMMAR_TABLE WHERE UNSIG_ID IS > NULL) AND SEC_UNSIG_ID < ANY > (SELECT DISTINCT(UNSIG_ID) FROM LARGE_TABLE WHERE UNSIG_ID<2500) LIMIT 1000) > AND A.ID < 1; > MainThread|[1;31mError: Encountered exception in sub plan [0] execution. > (state=,code=0)[m > MainThread|java.sql.SQLException: Encountered exception in sub plan [0] > execution. > MainThread|at > org.apache.phoenix.execute.HashJoinPlan.iterator(HashJoinPlan.java:156) > MainThread|at > org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:245) > MainThread|at > org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:235) > MainThread|at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53) > MainThread|at > org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:234) > MainThread|at > org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1158) > MainThread|at sqlline.Commands.execute(Commands.java:822) > MainThread|at sqlline.Commands.sql(Commands.java:732) > MainThread|at sqlline.SqlLine.dispatch(SqlLine.java:808) > MainThread|at sqlline.SqlLine.runCommands(SqlLine.java:1711) > MainThread|at sqlline.Commands.run(Commands.java:1285) > MainThread|at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > MainThread|at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > MainThread|at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > MainThread|at java.lang.reflect.Method.invoke(Method.java:606) > MainThread|at > sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:36) > MainThread|at sqlline.SqlLine.dispatch(SqlLine.java:804) > MainThread|at sqlline.SqlLine.initArgs(SqlLine.java:613) > MainThread|at sqlline.SqlLine.begin(SqlLine.java:656) > MainThread|at sqlline.SqlLine.start(SqlLine.java:398) > MainThread|at sqlline.SqlLine.main(SqlLine.java:292) > MainThread|Caused by: java.lang.NullPointerException > MainThread|at > org.apache.phoenix.schema.types.PDataType.instantiatePhoenixArray(PDataType.java:1119) > MainThread|at > org.apache.phoenix.schema.types.PArrayDataType.instantiatePhoenixArray(PArrayDataType.java:614) > MainThread|at > org.apache.phoenix.execute.HashJoinPlan$WhereClauseSubPlan.execute(HashJoinPlan.java:283) > MainThread|at > org.apache.phoenix.execute.HashJoinPlan$1.call(HashJoinPlan.java:135) > MainThread|at java.util.concurrent.FutureTask.run(FutureTask.java:262) > MainThread|at > org.apache.phoenix.job.JobManager$InstrumentedJobFutureTask.run(JobManager.java:172) > MainThread|at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > MainThread|at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > MainThread|at java.lang.Thread.run(Thread.java:745) > MainThread|[1;31mAborting command set because "force" is false and command > failed: "SELECT * FROM (SELECT ID, BIG_ID, DATE_ID FROM LARGE_TABLE AS A > WHERE (A.ID % 5) = 0) AS A INNER JOIN (SELECT SEC_ID, SEC_TINY_ID, > SEC_UNSIG_FLOAT_ID FROM SECONDARY_LARGE_TABLE AS B WHERE (B.SEC_ID % 5) = 0) > AS B ON A.ID=B.SEC_ID WHERE A.DATE_ID > ALL (SELECT SEC_DATE_ID FROM > SECONDARY_LARGE_TABLE LIMIT 100) AND B.SEC_UNSIG_FLOAT_ID = ANY (SELECT > sec_unsig_float_id FROM > SECONDARY_LARGE_TABLE WHERE SEC_I
[jira] [Resolved] (PHOENIX-2022) BaseRegionScanner.next should be abstract
[ https://issues.apache.org/jira/browse/PHOENIX-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Reid resolved PHOENIX-2022. --- Pushed to master and all 4.4 and 4.x branches. > BaseRegionScanner.next should be abstract > - > > Key: PHOENIX-2022 > URL: https://issues.apache.org/jira/browse/PHOENIX-2022 > Project: Phoenix > Issue Type: Bug >Reporter: Gabriel Reid >Assignee: Gabriel Reid > Attachments: PHOENIX-2022.patch > > > As pointed out by Yuhao Bi on a [dev list mail|http://s.apache.org/y6b], > BaseRegionScanner implements next as a recursive call to itself. > All current subclasses of BaseRegionScanner implement next, but as soon as > there is an implementation that doesn't do this, it will end up with a stack > overflow. > Easy fix is to make this method abstract instead of having a default > recursive implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2022) BaseRegionScanner.next should be abstract
[ https://issues.apache.org/jira/browse/PHOENIX-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567385#comment-14567385 ] James Taylor commented on PHOENIX-2022: --- +1. This was my thinking as well. Thanks for the patch. > BaseRegionScanner.next should be abstract > - > > Key: PHOENIX-2022 > URL: https://issues.apache.org/jira/browse/PHOENIX-2022 > Project: Phoenix > Issue Type: Bug >Reporter: Gabriel Reid >Assignee: Gabriel Reid > Attachments: PHOENIX-2022.patch > > > As pointed out by Yuhao Bi on a [dev list mail|http://s.apache.org/y6b], > BaseRegionScanner implements next as a recursive call to itself. > All current subclasses of BaseRegionScanner implement next, but as soon as > there is an implementation that doesn't do this, it will end up with a stack > overflow. > Easy fix is to make this method abstract instead of having a default > recursive implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
