[jira] [Commented] (CASSANDRA-10331) Establish and implement canonical bulk reading workload(s)
[
https://issues.apache.org/jira/browse/CASSANDRA-10331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182702#comment-15182702
]
Stefania commented on CASSANDRA-10331:
--
The cassandra-stress tool has been extended with a new user defined operation
to perform bulk read queries. Here are the links to the patch and CI results:
|[patch|https://github.com/stef1927/cassandra/commits/10331]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10331-testall/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10331-dtest/]|
Each query sweeps an entire token range using the following CQL syntax:
{code}
SELECT token(pk), a, b, c FROM table WHERE token(pk) > X AND token(pk) <= Y
{code}
Here a,b and c are the columns selected by the user and pk is the partition
key. {{token(pk)}} is added in order to count partitions.
Users define a schema and add token range queries as follows:
{code}
token_range_queries:
all_columns_tr_query:
columns: '*'
page_size: 5000
split_factor: 1
{code}
For each query the columns must be specified. Optionally, the page size and
split factor can be specified. Each stress operation retrieves one page of a
token range according to the page size specified by the user. The split factor
can be used to split token ranges. This may be useful when VNODES are not used
or to exploit thread parallelism further.
The test cycles across token ranges, and each thread picks a token range. Two
threads may download the same range in parallel if there aren't enough ranges
to cycle through, but they will not share a token range retrieval. Each thread
will download the token range page by page, with each stress operation
downloading a single page. Once all pages have been retrieved, the thread moves
on to the next range. If we run out of ranges we start again with the first
one. When all iterations have been performed, or the test duration has been
reached, the test halts.
I've created some user defined schemas in [this
benchmark|https://github.com/stef1927/cstar_bulk_read_test] where the row size
changes from 100 bytes to 10 MB and the clustering size changes from 1 to 1000
rows. We can use these schemas as a starting point to measure bulk reading
performance.
> Establish and implement canonical bulk reading workload(s)
> --
>
> Key: CASSANDRA-10331
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10331
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Ariel Weisberg
>Assignee: Stefania
> Fix For: 3.x
>
>
> Implement a client, use stress, or extend stress to a bulk reading workload
> that is indicative of the performance we are trying to improve.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11293) NPE when using CQLSSTableWriter
[
https://issues.apache.org/jira/browse/CASSANDRA-11293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182621#comment-15182621
]
Will Hayworth commented on CASSANDRA-11293:
---
Just a note that going singlethreaded magically fixed everything. I'm guessing
something isn't synchronized that needs to be? :S
> NPE when using CQLSSTableWriter
> ---
>
> Key: CASSANDRA-11293
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11293
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: C* 3.3, C* trunk
>Reporter: Will Hayworth
>
> Hi all!
> I'm trying to using CQLSSTableWriter to load a bunch of historical data into
> my cluster and I'm getting NullPointerExceptions consistently after having
> written a few million rows (anywhere from 0.5 to 1.5 GB of data).
> {code}
> java.lang.NullPointerException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at
> java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598)
> at java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677)
> at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735) at
> java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233) at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:583)
> at
> com.atlassian.engagementengine.segmentation.helenus.Daemon.main(Daemon.java:24)
> Caused by: java.lang.NullPointerException at
> org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:126)
> at
> org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:44)
> at
> java.util.TimSort.binarySort(TimSort.java:296) at
> java.util.TimSort.sort(TimSort.java:239) at
> java.util.Arrays.sort(Arrays.java:1512) at
> org.apache.cassandra.utils.btree.BTree$Builder.sort(BTree.java:1027) at
> org.apache.cassandra.utils.btree.BTree$Builder.autoEnforce(BTree.java:1036)
> at org.apache.cassandra.utils.btree.BTree$Builder.build(BTree.java:1075) at
> org.apache.cassandra.db.partitions.PartitionUpdate.build(PartitionUpdate.java:572)
> at
> org.apache.cassandra.db.partitions.PartitionUpdate.maybeBuild(PartitionUpdate.java:562)
> at
> org.apache.cassandra.db.partitions.PartitionUpdate.holder(PartitionUpdate.java:370)
> at
> org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:177)
> at
> org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:172)
> at
> org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter$DiskWriter.run(SSTableSimpleUnsortedWriter.java:209)
> {code}
> This may be a red herring, but I started encountering this when I
> parallelized writes. (I wasn't aware that doing so was safe until I saw
> CASSANDRA-7463; I Googled in vain for a while before that.) I'm also
> definitely not passing any nulls in my {{addRow}} calls.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10112) Refuse to start and print txn log information in case of disk corruption
[
https://issues.apache.org/jira/browse/CASSANDRA-10112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182468#comment-15182468
]
Stefania edited comment on CASSANDRA-10112 at 3/7/16 2:19 AM:
--
Thank you for the review.
bq. Can you verify that the failing
{{org.apache.cassandra.io.sstable.SSTableWriterTest.testAbortTxnWithOpenEarlyShouldRemoveSSTable}}
utest is not a regression?
It passes locally and it failed on trunk as well, see [build
751|http://cassci.datastax.com/job/trunk_testall/751/testReport/org.apache.cassandra.io.sstable/SSTableWriterTest/testAbortTxnWithOpenEarlyShouldRemoveSSTable].
bq. It would be nice to use constants instead of magic numbers for
{{StartupException}} exit status codes.
I've introduced 3 generic constants (1: wrong machine state, 3: wrong disk
state, 100: wrong config). I had to change the JNA unavailable exit error from
3 to 1. We could make the constants more specific but we'd have to change more
exit codes.
bq. In {{LogRecord.make()}}, why do we catch {{Throwable}}? Should we be
passing that through {{JVMStabilityInspector}}?
To catch the exceptions thrown by the {{valueOf()}} methods as far as I
remember. I don't see anything else that could throw so I've replaced
{{Throwable}} with {{IllegalArgumentException}}.
bq. {{removeUnfinishedCompactionLeftovers()}} could use some javadocs
(especially explaining the return value).
Added some comments to {{LogTransaction.removeUnfinishedLeftovers()}}.
bq. I have a slight for using the term "directories" instead of "folders" (but
it's not worth changing existing code for this)
You're quite right, folder is a Windows Explorer concept and it is not
necessarily a directory. It didn't take long so I've changed the mentions to
folder that I could find in the {{Log*}} files in {{db.lifecycle}}.
bq. I think this ticket needs a {{doc-impacting}} label
Added.
--
I've restarted one more CI run.
was (Author: stefania):
Thank you for the review.
bq. Can you verify that the failing
{{org.apache.cassandra.io.sstable.SSTableWriterTest.testAbortTxnWithOpenEarlyShouldRemoveSSTable}}
utest is not a regression?
It passes locally and it failed on trunk as well, see [build
751|http://cassci.datastax.com/job/trunk_testall/751/testReport/org.apache.cassandra.io.sstable/SSTableWriterTest/testAbortTxnWithOpenEarlyShouldRemoveSSTable].
bq. It would be nice to use constants instead of magic numbers for
{{StartupException}} exit status codes.
I've introduced 3 generic constants (1: wrong machine state, 3: wrong disk
state, 100: wrong config). I had to change the JNA unavailable exit error from
3 to 1. We could make the constants more specific but we'd have to change more
exit codes.
bq. In {{LogRecord.make()}}, why do we catch {{Throwable}}? Should we be
passing that through {{JVMStabilityInspector}}?
To catch the exceptions thrown by the {{valueOf()}} methods as far as I
remember. I don't see anything else that could throw so I've replaced
{{Throwable}} with {{IllegalArgumentException}}.
bq. {{removeUnfinishedCompactionLeftovers()}} could use some javadocs
(especially explaining the return value).
Added some comments to {{LogTransaction.removeUnfinishedLeftovers()}}.
bq. I have a slight for using the term "directories" instead of "folders" (but
it's not worth changing existing code for this)
You're quite right, folder is a Windows Explorer concept and it is not
necessarily a directory. It didn't take long so I've changed the mentions to
folder that I could find in the {{Log*}} files in {{db.lifecycle}}.
bq. I think this ticket needs a {doc-impacting}} label
Added.
I've restarted one more CI run.
> Refuse to start and print txn log information in case of disk corruption
>
>
> Key: CASSANDRA-10112
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10112
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
>Reporter: Stefania
>Assignee: Stefania
> Labels: doc-impacting
> Fix For: 3.x
>
>
> Transaction logs were introduced by CASSANDRA-7066 and are read during
> start-up. In case of file system errors, such as disk corruption, we
> currently log a panic error and leave the sstable files and transaction logs
> as they are; this is to avoid rolling back a transaction (i.e. deleting
> files) by mistake.
> We should instead look at the {{disk_failure_policy}} and refuse to start
> unless the failure policy is {{ignore}}.
> We should also consider stashing files that cannot be read during startup,
> either transaction logs or sstables, by moving them to a dedicated
> sub-folder.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10112) Refuse to start and print txn log information in case of disk corruption
[
https://issues.apache.org/jira/browse/CASSANDRA-10112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182468#comment-15182468
]
Stefania commented on CASSANDRA-10112:
--
Thank you for the review.
bq. Can you verify that the failing
{{org.apache.cassandra.io.sstable.SSTableWriterTest.testAbortTxnWithOpenEarlyShouldRemoveSSTable}}
utest is not a regression?
It passes locally and it failed on trunk as well, see [build
751|http://cassci.datastax.com/job/trunk_testall/751/testReport/org.apache.cassandra.io.sstable/SSTableWriterTest/testAbortTxnWithOpenEarlyShouldRemoveSSTable].
bq. It would be nice to use constants instead of magic numbers for
{{StartupException}} exit status codes.
I've introduced 3 generic constants (1: wrong machine state, 3: wrong disk
state, 100: wrong config). I had to change the JNA unavailable exit error from
3 to 1. We could make the constants more specific but we'd have to change more
exit codes.
bq. In {{LogRecord.make()}}, why do we catch {{Throwable}}? Should we be
passing that through {{JVMStabilityInspector}}?
To catch the exceptions thrown by the {{valueOf()}} methods as far as I
remember. I don't see anything else that could throw so I've replaced
{{Throwable}} with {{IllegalArgumentException}}.
bq. {{removeUnfinishedCompactionLeftovers()}} could use some javadocs
(especially explaining the return value).
Added some comments to {{LogTransaction.removeUnfinishedLeftovers()}}.
bq. I have a slight for using the term "directories" instead of "folders" (but
it's not worth changing existing code for this)
You're quite right, folder is a Windows Explorer concept and it is not
necessarily a directory. It didn't take long so I've changed the mentions to
folder that I could find in the {{Log*}} files in {{db.lifecycle}}.
bq. I think this ticket needs a {doc-impacting}} label
Added.
I've restarted one more CI run.
> Refuse to start and print txn log information in case of disk corruption
>
>
> Key: CASSANDRA-10112
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10112
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
>Reporter: Stefania
>Assignee: Stefania
> Labels: doc-impacting
> Fix For: 3.x
>
>
> Transaction logs were introduced by CASSANDRA-7066 and are read during
> start-up. In case of file system errors, such as disk corruption, we
> currently log a panic error and leave the sstable files and transaction logs
> as they are; this is to avoid rolling back a transaction (i.e. deleting
> files) by mistake.
> We should instead look at the {{disk_failure_policy}} and refuse to start
> unless the failure policy is {{ignore}}.
> We should also consider stashing files that cannot be read during startup,
> either transaction logs or sstables, by moving them to a dedicated
> sub-folder.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10112) Refuse to start and print txn log information in case of disk corruption
[
https://issues.apache.org/jira/browse/CASSANDRA-10112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-10112:
-
Labels: doc-impacting (was: )
> Refuse to start and print txn log information in case of disk corruption
>
>
> Key: CASSANDRA-10112
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10112
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
>Reporter: Stefania
>Assignee: Stefania
> Labels: doc-impacting
> Fix For: 3.x
>
>
> Transaction logs were introduced by CASSANDRA-7066 and are read during
> start-up. In case of file system errors, such as disk corruption, we
> currently log a panic error and leave the sstable files and transaction logs
> as they are; this is to avoid rolling back a transaction (i.e. deleting
> files) by mistake.
> We should instead look at the {{disk_failure_policy}} and refuse to start
> unless the failure policy is {{ignore}}.
> We should also consider stashing files that cannot be read during startup,
> either transaction logs or sstables, by moving them to a dedicated
> sub-folder.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10750) Minor code improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-10750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182414#comment-15182414 ] Stefania commented on CASSANDRA-10750: -- 3.2. Should we ninja fix CHANGES.txt? > Minor code improvements > --- > > Key: CASSANDRA-10750 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10750 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Minor > Fix For: 3.2 > > > Went though several IDE inspections and found some places in the code that > could be improved. These are just minor improvements and no bug fixes (except > one minor "theoretical" thing). > The [branch on github against > trunk|https://github.com/snazy/cassandra/tree/10750-code-opts-trunk] contains > a series of commits: > * simplify Mutation.apply to remove the casts > * "minor code improvements" just replaces some expressions that are > effectively constant > * remove unused assignments (probably just cosmetic) > * collapse identical if-branches (probably just cosmetic) > * empty array constants > * fix printf usage (could potentially raise an exception in printf) > * replace tail-recursion in some critical sections (as the JVM cannot > optimize that AFAIK) > * remove methods identical to their super methods (probably just cosmetic) > [cassci results > here|http://cassci.datastax.com/view/Dev/view/snazy/search/?q=snazy-10750-] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10750) Minor code improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-10750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefania updated CASSANDRA-10750: - Fix Version/s: 3.2 > Minor code improvements > --- > > Key: CASSANDRA-10750 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10750 > Project: Cassandra > Issue Type: Improvement >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Minor > Fix For: 3.2 > > > Went though several IDE inspections and found some places in the code that > could be improved. These are just minor improvements and no bug fixes (except > one minor "theoretical" thing). > The [branch on github against > trunk|https://github.com/snazy/cassandra/tree/10750-code-opts-trunk] contains > a series of commits: > * simplify Mutation.apply to remove the casts > * "minor code improvements" just replaces some expressions that are > effectively constant > * remove unused assignments (probably just cosmetic) > * collapse identical if-branches (probably just cosmetic) > * empty array constants > * fix printf usage (could potentially raise an exception in printf) > * replace tail-recursion in some critical sections (as the JVM cannot > optimize that AFAIK) > * remove methods identical to their super methods (probably just cosmetic) > [cassci results > here|http://cassci.datastax.com/view/Dev/view/snazy/search/?q=snazy-10750-] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8928) Add downgradesstables
[ https://issues.apache.org/jira/browse/CASSANDRA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15174611#comment-15174611 ] Kaide Mu edited comment on CASSANDRA-8928 at 3/6/16 5:54 PM: - Hi, [~yukim] Thanks for the quick replay, I had been looking for SSTable formats on branch 2.2(la), 2.1(ka) and 2.0(jb). I'm not sure if I'm in the right way, but I had been looking for following stuffs: - Regarding to changelog on [BIgVersion|https://github.com/apache/cassandra/blob/cassandra-3.3/src/java/org/apache/cassandra/io/sstable/format/big/BigFormat.java#L116]: -- There's some change with checksums such as adler32 for compression check sum. -- In version 2.1 introduces Statistics, but I found it as component of SSTable in version 2.0(?) -- Vesion 2.2 only introduces a new file name format, "la". - Respect to "Formats", I had been looking for [SSTableFormat|https://github.com/apache/cassandra/blob/trunk/src%2Fjava%2Forg%2Fapache%2Fcassandra%2Fio%2Fsstable%2Fformat%2FSSTableFormat.java#L35] available on branch 2.2, that contains table format type, which is "big", but I didn't find any information about that on branch 2.1 and 2.0. Also there's no indication of this thing in its [Descriptors|https://github.com/apache/cassandra/blob/cassandra-2.1/src%2Fjava%2Forg%2Fapache%2Fcassandra%2Fio%2Fsstable%2FDescriptor.java#L39]. Also as I mentioned before I had been looking for [Components|https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/io/sstable/Component.java#L32] of each branch and seems the main differences are: -- They use different hash functions for digest 2.2 uses adler32, 2.1 and 2.0 uses sha-1 -- 2.0 version has COMPACTED_MARKER, which is removed in forward versions. I'm not sure if i missed something. - Therefore, if I'm correct, please correct me if not, if we want to write (I have a question about this terminology, when we say write in this context do we mean write, or create? Because I found that SSTable is immutable after creation) an older version of SSTable we should have proper Digest and COMPACTED_MARKER also in case of jb. My sincerest apologies for making this comment this way long, If above considerations are correct, I'll continue looking for code base and SSTable API, also would you mind tell me where can I find implementation of changes proposed in the BigVersion and implementation of SSTable, I had been looking for [SSTable|https://github.com/apache/cassandra/blob/cassandra-2.2/src%2Fjava%2Forg%2Fapache%2Fcassandra%2Fio%2Fsstable%2FSSTable.java#L57] but I don't know if it's the right one. Best regards, Kaide Mu was (Author: kdmu): Hi, dear Yuki. Thanks for the quick replay, I had been looking for SSTable formats on branch 2.2(la), 2.1(ka) and 2.0(jb). I'm not sure if I'm in the right way, but I had been looking for following stuffs: - Regarding to changelog on [BIgVersion|https://github.com/apache/cassandra/blob/cassandra-3.3/src/java/org/apache/cassandra/io/sstable/format/big/BigFormat.java#L116]: -- There's some change with checksums such as adler32 for compression check sum. -- In version 2.1 introduces Statistics, but I found it as component of SSTable in version 2.0(?) -- Vesion 2.2 only introduces a new file name format, "la". - Respect to "Formats", I had been looking for [SSTableFormat|https://github.com/apache/cassandra/blob/trunk/src%2Fjava%2Forg%2Fapache%2Fcassandra%2Fio%2Fsstable%2Fformat%2FSSTableFormat.java#L35] available on branch 2.2, that contains table format type, which is "big", but I didn't find any information about that on branch 2.1 and 2.0. Also there's no indication of this thing in its [Descriptors|https://github.com/apache/cassandra/blob/cassandra-2.1/src%2Fjava%2Forg%2Fapache%2Fcassandra%2Fio%2Fsstable%2FDescriptor.java#L39]. Also as I mentioned before I had been looking for [Components|https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/io/sstable/Component.java#L32] of each branch and seems the main differences are: -- They use different hash functions for digest 2.2 uses adler32, 2.1 and 2.0 uses sha-1 -- 2.0 version has COMPACTED_MARKER, which is removed in forward versions. I'm not sure if i missed something. - Therefore, if I'm correct, please correct me if not, if we want to write (I have a question about this terminology, when we say write in this context do we mean write, or create? Because I found that SSTable is immutable after creation) an older version of SSTable we should have proper Digest and COMPACTED_MARKER also in case of jb. My sincerest apologies for making this comment this way long, If above considerations are correct, I'll continue looking for code base and SSTable API, also would you mind tell me where can I find implementation of changes proposed in the BigVersion and implementation of SSTable, I had been looking for
[jira] [Commented] (CASSANDRA-11309) Generic Java UDF types broken for RETURNS NULL ON NULL INPUT
[
https://issues.apache.org/jira/browse/CASSANDRA-11309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182147#comment-15182147
]
Robert Stupp commented on CASSANDRA-11309:
--
[Git
branch|https://github.com/apache/cassandra/compare/trunk...snazy:11309-generic-udf-broken-trunk?expand=1]
[cassci
utests|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11309-generic-udf-broken-trunk-testall/]
[cassci
dtests|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-11309-generic-udf-broken-trunk-dtest/]
> Generic Java UDF types broken for RETURNS NULL ON NULL INPUT
>
>
> Key: CASSANDRA-11309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11309
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.5
>
>
> The Java source generated for Java UDFs as introduced by CASSANDRA-10819 is
> broken for {{RETURNS NULL ON NULL INPUT}} (not for {{CALLED ON NULL INPUT}}).
> This means that the generic types are lost for RETURNS NULL ON NULL INPUT but
> work as expected for CALLED ON NULL INPUT.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11309) Generic Java UDF types broken for RETURNS NULL ON NULL INPUT
[
https://issues.apache.org/jira/browse/CASSANDRA-11309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-11309:
-
Status: Patch Available (was: Open)
> Generic Java UDF types broken for RETURNS NULL ON NULL INPUT
>
>
> Key: CASSANDRA-11309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11309
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.5
>
>
> The Java source generated for Java UDFs as introduced by CASSANDRA-10819 is
> broken for {{RETURNS NULL ON NULL INPUT}} (not for {{CALLED ON NULL INPUT}}).
> This means that the generic types are lost for RETURNS NULL ON NULL INPUT but
> work as expected for CALLED ON NULL INPUT.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11309) Generic Java UDF types broken for RETURNS NULL ON NULL INPUT
Robert Stupp created CASSANDRA-11309:
Summary: Generic Java UDF types broken for RETURNS NULL ON NULL
INPUT
Key: CASSANDRA-11309
URL: https://issues.apache.org/jira/browse/CASSANDRA-11309
Project: Cassandra
Issue Type: Bug
Reporter: Robert Stupp
Assignee: Robert Stupp
Priority: Minor
Fix For: 3.5
The Java source generated for Java UDFs as introduced by CASSANDRA-10819 is
broken for {{RETURNS NULL ON NULL INPUT}} (not for {{CALLED ON NULL INPUT}}).
This means that the generic types are lost for RETURNS NULL ON NULL INPUT but
work as expected for CALLED ON NULL INPUT.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
