[jira] [Updated] (CASSANDRA-15021) TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0 upgrade test is failing with TypeError
[
https://issues.apache.org/jira/browse/CASSANDRA-15021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15021:
-
Fix Version/s: 3.11.4
Since Version: 3.11.0
Status: Resolved (was: Ready to Commit)
Thanks for the review Ariel Weisberg
Committed as
[35b22f57a03ce9e14865e335b4eb30fc11645a5c|https://github.com/apache/cassandra-dtest/commit/35b22f57a03ce9e14865e335b4eb30fc11645a5c]
to cassandra-dtest repo
> TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0 upgrade
> test is failing with TypeError
>
>
> Key: CASSANDRA-15021
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15021
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Vinay Chella
>Priority: Low
> Labels: dtest, test, upgrade-dtest
> Fix For: 3.11.4
>
>
> While running upgrade tests for 3.11.4 candidate I noticed that
> {{upgrade_tests.storage_engine_upgrade_test.TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0}}
> is failing with TypeError.
> Example run with error:
> {code:java}
> self = object at 0x7f8db9908240>
> @since('3.0', max_version='3.99')
> def test_upgrade_with_range_tombstone_eoc_0(self):
> """
> Check sstable upgrading when the sstable contains a range
> tombstone with EOC=0.
>
> @jira_ticket CASSANDRA-12423
> """
> session = self._setup_cluster(cluster_options={'start_rpc': 'true'})
>
> session.execute("CREATE TABLE rt (id INT, c1 TEXT, c2 TEXT, v INT,
> PRIMARY KEY (id, c1, c2)) "
> "with compact storage and compression =
> {'sstable_compression': ''};")
>
> range_delete = {
> i32(1): {
> 'rt': [Mutation(deletion=Deletion(2470761440040513,
>
> predicate=SlicePredicate(slice_range=SliceRange(
> > start=composite('a',
> > eoc='\x00'),
> finish=composite('asd',
> eoc='\x00')]
> }
> }
> upgrade_tests/storage_engine_upgrade_test.py:434:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> item1 = b'a', item2 = None, eoc = '\x00'
> def composite(item1, item2=None, eoc=b'\x00'):
> if isinstance(item1, str):
> item1 = utf8encode(item1)
> if isinstance(item2, str):
> item2 = utf8encode(item2)
>
> > packed = _i16(len(item1)) + item1 + eoc
> E TypeError: can't concat str to bytes
> thrift_test.py:153: TypeError
> {code}
> This TypeError is from Python3 migration. Python 3's standard string type is
> Unicode based, and Python 3 adds a dedicated bytes type, but critically, no
> automatic coercion between bytes and unicode strings is provided -
> [context|https://www.python.org/dev/peps/pep-0404/#strings-and-bytes]
> This change in python3 is leading to "TypeError: can't concat str to bytes"
> while appending bytes to string.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch master updated: Fix TypeError for str and bytes concatenation in test_upgrade_with_range_tombstone_eoc_0 and thrift_test.py::composite
This is an automated email from the ASF dual-hosted git repository.
vinaychella pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/master by this push:
new 35b22f5 Fix TypeError for str and bytes concatenation in
test_upgrade_with_range_tombstone_eoc_0 and thrift_test.py::composite
35b22f5 is described below
commit 35b22f57a03ce9e14865e335b4eb30fc11645a5c
Author: Vinay Chella
AuthorDate: Wed Feb 13 12:54:06 2019 -0800
Fix TypeError for str and bytes concatenation in
test_upgrade_with_range_tombstone_eoc_0 and thrift_test.py::composite
Patch by Vinay Chella; reviewed by Ariel Weisberg for CASSANDRA-15021
---
thrift_test.py | 2 ++
upgrade_tests/storage_engine_upgrade_test.py | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/thrift_test.py b/thrift_test.py
index 1cf06ea..668b6cf 100644
--- a/thrift_test.py
+++ b/thrift_test.py
@@ -149,6 +149,8 @@ def composite(item1, item2=None, eoc=b'\x00'):
item1 = utf8encode(item1)
if isinstance(item2, str):
item2 = utf8encode(item2)
+if isinstance(eoc, str):
+eoc = utf8encode(eoc)
packed = _i16(len(item1)) + item1 + eoc
if item2 is not None:
diff --git a/upgrade_tests/storage_engine_upgrade_test.py
b/upgrade_tests/storage_engine_upgrade_test.py
index 88abb97..a63ef85 100644
--- a/upgrade_tests/storage_engine_upgrade_test.py
+++ b/upgrade_tests/storage_engine_upgrade_test.py
@@ -431,8 +431,8 @@ class TestStorageEngineUpgrade(Tester):
i32(1): {
'rt': [Mutation(deletion=Deletion(2470761440040513,
predicate=SlicePredicate(slice_range=SliceRange(
- start=composite('a',
eoc='\x00'),
- finish=composite('asd',
eoc='\x00')]
+ start=composite('a',
eoc=b'\x00'),
+ finish=composite('asd',
eoc=b'\x00')]
}
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15055) ReadTimeoutException: Operation timed out - received only 0 responses
GANGADHARA created CASSANDRA-15055: -- Summary: ReadTimeoutException: Operation timed out - received only 0 responses Key: CASSANDRA-15055 URL: https://issues.apache.org/jira/browse/CASSANDRA-15055 Project: Cassandra Issue Type: Bug Reporter: GANGADHARA we have Apache Cassandra 2.2.5 cluster with 05 nodes running on Ubuntu 8 core 64 gb memory server , in the system.log we are consistently seeing ReadTimeoutException, need help on understanding what could be the issue bombarding the log and fix the issue uname -a Linux subcass004A 4.4.0-128-generic #154~14.04.1-Ubuntu SMP Fri May 25 14:58:51 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux *free -g* *total used free shared buffers cached* *Mem: 55 54 0 0 1 16* *-/+ buffers/cache: 36 18* *Swap: 0 0 0* cat /proc/cpuinfo |grep -i process |wc -l 8 *cat /etc/cassandra/cassandra-env.sh |grep -i MAX_HEAP_SIZE* *MAX_HEAP_SIZE="32G"* ERROR [SharedPool-Worker-72] 2019-03-12 04:52:42,968 QueryMessage.java:136 - Unexpected error during query com.google.common.util.concurrent.UncheckedExecutionException: *java.lang.RuntimeException: org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - received only 0 responses.* at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2201) ~[guava-16.0.jar:na] at com.google.common.cache.LocalCache.get(LocalCache.java:3934) ~[guava-16.0.jar:na] at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3938) ~[guava-16.0.jar:na] at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4821) ~[guava-16.0.jar:na] at org.apache.cassandra.auth.PermissionsCache.getPermissions(PermissionsCache.java:72) ~[apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.auth.AuthenticatedUser.getPermissions(AuthenticatedUser.java:104) ~[apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.service.ClientState.authorize(ClientState.java:367) ~[apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.service.ClientState.checkPermissionOnResourceChain(ClientState.java:300) ~[apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.service.ClientState.ensureHasPermission(ClientState.java:277) ~[apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.service.ClientState.hasAccess(ClientState.java:264) ~[apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.service.ClientState.hasColumnFamilyAccess(ClientState.java:248) ~[apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.cql3.statements.SelectStatement.checkAccess(SelectStatement.java:153) ~[apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:223) ~[apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:257) ~[apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:242) ~[apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:123) ~[apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:507) [apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:401) [apache-cassandra-2.2.5.jar:2.2.5] at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32) [netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324) [netty-all-4.0.23.Final.jar:4.0.23.Final] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_181] at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164) [apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) [apache-cassandra-2.2.5.jar:2.2.5] at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181] Caused by: java.lang.RuntimeException: org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - received only 0 responses. at org.apache.cassandra.auth.CassandraRoleManager.getRole(CassandraRoleManager.java:497) ~[apache-cassandra-2.2.5.jar:2.2.5] at org.apache.cassandra.auth.CassandraRoleManage
[jira] [Updated] (CASSANDRA-8282) org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out while selecting query
[
https://issues.apache.org/jira/browse/CASSANDRA-8282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anonymous updated CASSANDRA-8282:
-
Status: Open (was: Resolved)
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out
> while selecting query
> ---
>
> Key: CASSANDRA-8282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8282
> Project: Cassandra
> Issue Type: Bug
> Environment: Ubuntu 12
> AWS network
> [cqlsh 5.0.1 | Cassandra 2.1.0 | CQL spec 3.2.0 | Native protocol v3]
> 4 cores and 15GB ram with 6 nodes.
>Reporter: murali
>Priority: Low
> Labels: performance
>
> Hi there,
> We are getting below error when we ran {{select count(*) from demo.songs}} on
> CQLSH ( [cqlsh 5.0.1 | Cassandra 2.1.0 | CQL spec 3.2.0 | Native protocol v3]
> ) and we are on AWS m3.large instances with 6 nodes in single DC.
> {noformat}
> ERROR [Thrift:15] 2014-11-10 09:27:52,613 CustomTThreadPoolServer.java:219 -
> Error occurred during processing of message.
> com.google.common.util.concurrent.UncheckedExecutionException:
> java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 0 responses.
> at
> com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2201)
> ~[guava-16.0.jar:na]
> at com.google.common.cache.LocalCache.get(LocalCache.java:3934)
> ~[guava-16.0.jar:na]
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3938)
> ~[guava-16.0.jar:na]
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4821)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.service.ClientState.authorize(ClientState.java:353)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.service.ClientState.ensureHasPermission(ClientState.java:225)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.service.ClientState.hasAccess(ClientState.java:219)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.service.ClientState.hasColumnFamilyAccess(ClientState.java:203)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.thrift.CassandraServer.multiget_slice(CassandraServer.java:370)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.thrift.Cassandra$Processor$multiget_slice.getResult(Cassandra.java:3716)
> ~[apache-cassandra-thrift-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.thrift.Cassandra$Processor$multiget_slice.getResult(Cassandra.java:3700)
> ~[apache-cassandra-thrift-2.1.0.jar:2.1.0]
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> ~[libthrift-0.9.1.jar:0.9.1]
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> ~[libthrift-0.9.1.jar:0.9.1]
> at
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:201)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> Caused by: java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out -
> received only 0 responses.
> at org.apache.cassandra.auth.Auth.selectUser(Auth.java:271)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at org.apache.cassandra.auth.Auth.isSuperuser(Auth.java:88)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.auth.AuthenticatedUser.isSuper(AuthenticatedUser.java:50)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.auth.CassandraAuthorizer.authorize(CassandraAuthorizer.java:67)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.service.ClientState$1.load(ClientState.java:339)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.service.ClientState$1.load(ClientState.java:336)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3524)
> ~[guava-16.0.jar:na]
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2317)
> ~[guava-16.0.jar:na]
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2280)
> ~[guava-16.0.jar:na]
> at
> com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2195)
> ~[guava-16.0.jar:na]
> ... 16 common frames omitted
> Caused by: org.apache.cassandra.exceptions.ReadTimeout
[jira] [Commented] (CASSANDRA-15053) Fix handling FS errors on writing and reading flat files - LogTransaction and hints
[ https://issues.apache.org/jira/browse/CASSANDRA-15053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793750#comment-16793750 ] Blake Eggleston commented on CASSANDRA-15053: - +1 > Fix handling FS errors on writing and reading flat files - LogTransaction and > hints > --- > > Key: CASSANDRA-15053 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15053 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Hints >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Normal > Fix For: 4.0, 3.0.x, 3.11.x > > > We currently fail to handle and propagate IO errors when dealing with > transaction log and hints. It's trivial to fix this behaviour to ensure that > disk failure policy is properly invoked in error scenarios. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15005) Configurable whilelist for UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-15005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793710#comment-16793710
]
A. Soroka commented on CASSANDRA-15005:
---
[~jmeredithco] I just realized that your branch being from the 3.0 line means
it runs up against the code freeze for that branch. I didn't understand what
you meant by writing "I'm also not sure what version this could land in with
the current freeze on trunk." but now I see that there's a problem there. I can
try rewriting this patch for {{trunk/4.0}} if you think that would be
feasible/better?
> Configurable whilelist for UDFs
> ---
>
> Key: CASSANDRA-15005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15005
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: A. Soroka
>Priority: Low
>
> I would like to use the UDF system to distribute some simple calculations on
> values. For some use cases, this would require access only to some Java API
> classes that aren't on the (hardcoded) whitelist (e.g.
> {{java.security.MessageDigest}}). In other cases, it would require access to
> a little non-C* library code, pre-distributed to nodes by out-of-band means.
> As I understand the situation now, the whitelist for types UDFs can use is
> hardcoded in java in
> [UDFunction|[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/UDFunction.java#L99].]
> This ticket, then, is a request for a facility that would allow that list to
> be extended via some kind of deployment-time configuration. I realize that
> serious security concerns immediately arise for this kind of functionality,
> but I hope that by restricting it (only used during startup, no exposing the
> whitelist for introspection, etc.) it could be quite practical.
> I'd like very much to assist with this ticket if it is accepted. (I believe I
> have sufficient Java skill to do that, but no real familiarity with C*'s
> codebase, yet. :) )
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15005) Configurable whilelist for UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-15005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793660#comment-16793660
]
A. Soroka commented on CASSANDRA-15005:
---
Ok, cool, thanks [~jmeredithco]! I'll take a crack at adding another test or
two to {{CustomFunctionCqlTest}} just to make sure I can, then once I think I
understand what's going on I can try and add something for the docs. Sound like
a useful way to spend time until the 23rd?
> Configurable whilelist for UDFs
> ---
>
> Key: CASSANDRA-15005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15005
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: A. Soroka
>Priority: Low
>
> I would like to use the UDF system to distribute some simple calculations on
> values. For some use cases, this would require access only to some Java API
> classes that aren't on the (hardcoded) whitelist (e.g.
> {{java.security.MessageDigest}}). In other cases, it would require access to
> a little non-C* library code, pre-distributed to nodes by out-of-band means.
> As I understand the situation now, the whitelist for types UDFs can use is
> hardcoded in java in
> [UDFunction|[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/UDFunction.java#L99].]
> This ticket, then, is a request for a facility that would allow that list to
> be extended via some kind of deployment-time configuration. I realize that
> serious security concerns immediately arise for this kind of functionality,
> but I hope that by restricting it (only used during startup, no exposing the
> whitelist for introspection, etc.) it could be quite practical.
> I'd like very much to assist with this ticket if it is accepted. (I believe I
> have sufficient Java skill to do that, but no real familiarity with C*'s
> codebase, yet. :) )
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15053) Fix handling FS errors on writing and reading flat files - LogTransaction and hints
[ https://issues.apache.org/jira/browse/CASSANDRA-15053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793652#comment-16793652 ] Marcus Eriksson commented on CASSANDRA-15053: - +1 > Fix handling FS errors on writing and reading flat files - LogTransaction and > hints > --- > > Key: CASSANDRA-15053 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15053 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Hints >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Normal > Fix For: 4.0, 3.0.x, 3.11.x > > > We currently fail to handle and propagate IO errors when dealing with > transaction log and hints. It's trivial to fix this behaviour to ensure that > disk failure policy is properly invoked in error scenarios. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15005) Configurable whilelist for UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-15005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793650#comment-16793650
]
Jon Meredith commented on CASSANDRA-15005:
--
Apologies for the lack of instructions, I was rushing yesterday.
The custom functions are enabled in the config file under ‘custom_fcts’,
very similar to your list of whitelisted functions.
There’s a couple of examples under test/unit/com/example and the
test/conf/cassandra.conf file has been updated to enable them. The
functions appear in the system keyspace.
You should be able to scan through the files in
https://github.com/jonmeredith/cassandra/tree/CASSANDRA-15005-3.0/src/java/org/apache/cassandra/cql3/functions
for examples of functions and how to serialize/deserialize the byte buffers
for the arguments.
I’m going to be mostly offline until 23rd March, but would be happy to help
when I’m back if you get stuck.
> Configurable whilelist for UDFs
> ---
>
> Key: CASSANDRA-15005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15005
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: A. Soroka
>Priority: Low
>
> I would like to use the UDF system to distribute some simple calculations on
> values. For some use cases, this would require access only to some Java API
> classes that aren't on the (hardcoded) whitelist (e.g.
> {{java.security.MessageDigest}}). In other cases, it would require access to
> a little non-C* library code, pre-distributed to nodes by out-of-band means.
> As I understand the situation now, the whitelist for types UDFs can use is
> hardcoded in java in
> [UDFunction|[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/UDFunction.java#L99].]
> This ticket, then, is a request for a facility that would allow that list to
> be extended via some kind of deployment-time configuration. I realize that
> serious security concerns immediately arise for this kind of functionality,
> but I hope that by restricting it (only used during startup, no exposing the
> whitelist for introspection, etc.) it could be quite practical.
> I'd like very much to assist with this ticket if it is accepted. (I believe I
> have sufficient Java skill to do that, but no real familiarity with C*'s
> codebase, yet. :) )
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15053) Fix handling FS errors on writing and reading flat files - LogTransaction and hints
[ https://issues.apache.org/jira/browse/CASSANDRA-15053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793645#comment-16793645 ] Ariel Weisberg commented on CASSANDRA-15053: +1 > Fix handling FS errors on writing and reading flat files - LogTransaction and > hints > --- > > Key: CASSANDRA-15053 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15053 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Hints >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Normal > Fix For: 4.0, 3.0.x, 3.11.x > > > We currently fail to handle and propagate IO errors when dealing with > transaction log and hints. It's trivial to fix this behaviour to ensure that > disk failure policy is properly invoked in error scenarios. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15053) Fix handling FS errors on writing and reading flat files - LogTransaction and hints
[ https://issues.apache.org/jira/browse/CASSANDRA-15053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-15053: -- Severity: Normal Complexity: Low Hanging Fruit Discovered By: User Report Bug Category: Parent values: Correctness(12982)Level 1 values: Semantic Failure(12988) Status: Open (was: Triage) > Fix handling FS errors on writing and reading flat files - LogTransaction and > hints > --- > > Key: CASSANDRA-15053 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15053 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Hints >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Normal > Fix For: 4.0, 3.0.x, 3.11.x > > > We currently fail to handle and propagate IO errors when dealing with > transaction log and hints. It's trivial to fix this behaviour to ensure that > disk failure policy is properly invoked in error scenarios. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15053) Fix handling FS errors on writing and reading flat files - LogTransaction and hints
[ https://issues.apache.org/jira/browse/CASSANDRA-15053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-15053: -- Test and Documentation Plan: NA Status: Patch Available (was: Open) > Fix handling FS errors on writing and reading flat files - LogTransaction and > hints > --- > > Key: CASSANDRA-15053 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15053 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Hints >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Normal > Fix For: 4.0, 3.0.x, 3.11.x > > > We currently fail to handle and propagate IO errors when dealing with > transaction log and hints. It's trivial to fix this behaviour to ensure that > disk failure policy is properly invoked in error scenarios. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15053) Fix handling FS errors on writing and reading flat files - LogTransaction and hints
[ https://issues.apache.org/jira/browse/CASSANDRA-15053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793634#comment-16793634 ] Aleksey Yeschenko commented on CASSANDRA-15053: --- Branches: [3.0|https://github.com/iamaleksey/cassandra/tree/15053-3.0], [3.11|https://github.com/iamaleksey/cassandra/tree/15053-3.11], [trunk|https://github.com/iamaleksey/cassandra/tree/15053-4.0]; CI: [3.0|https://circleci.com/workflow-run/60adf75c-2eb8-4ae6-bf6e-28c0ce6b16ea], [3.11|https://circleci.com/workflow-run/911b0a0a-935f-4172-b110-a92a32993906], [trunk|https://circleci.com/workflow-run/04cd6f87-1567-48f0-8bbc-d52029fa4efc]. > Fix handling FS errors on writing and reading flat files - LogTransaction and > hints > --- > > Key: CASSANDRA-15053 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15053 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Hints >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Normal > Fix For: 4.0, 3.0.x, 3.11.x > > > We currently fail to handle and propagate IO errors when dealing with > transaction log and hints. It's trivial to fix this behaviour to ensure that > disk failure policy is properly invoked in error scenarios. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15005) Configurable whilelist for UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-15005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793632#comment-16793632
]
A. Soroka commented on CASSANDRA-15005:
---
I'm really glad to see that, because I would have had to find out about those
idioms for testing and so forth the hard way.
But I'm not quite sure how the {{CustomFcts}} get connected into CQL. Or have I
been misunderstanding the whole time and you haven't been proposing a design in
which {{CREATE FUNCTION}} would be used at all, instead a design where the
custom functions would just appear in any keyspace alongside built-ins like the
ones in {{TimeFcts}}?
> Configurable whilelist for UDFs
> ---
>
> Key: CASSANDRA-15005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15005
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: A. Soroka
>Priority: Low
>
> I would like to use the UDF system to distribute some simple calculations on
> values. For some use cases, this would require access only to some Java API
> classes that aren't on the (hardcoded) whitelist (e.g.
> {{java.security.MessageDigest}}). In other cases, it would require access to
> a little non-C* library code, pre-distributed to nodes by out-of-band means.
> As I understand the situation now, the whitelist for types UDFs can use is
> hardcoded in java in
> [UDFunction|[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/UDFunction.java#L99].]
> This ticket, then, is a request for a facility that would allow that list to
> be extended via some kind of deployment-time configuration. I realize that
> serious security concerns immediately arise for this kind of functionality,
> but I hope that by restricting it (only used during startup, no exposing the
> whitelist for introspection, etc.) it could be quite practical.
> I'd like very much to assist with this ticket if it is accepted. (I believe I
> have sufficient Java skill to do that, but no real familiarity with C*'s
> codebase, yet. :) )
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15045) Fix index summary redistribution compaction cancellation issues
[
https://issues.apache.org/jira/browse/CASSANDRA-15045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15045:
Reviewers: Jordan West
> Fix index summary redistribution compaction cancellation issues
> ---
>
> Key: CASSANDRA-15045
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15045
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> We can't cancel ongoing index summary redistributions currently due to
> {{CompactionInfo}} returning null for {{getTableMetadata/getCFMetaData}}
> [here|https://github.com/apache/cassandra/blob/67d613204fa4fb9584f11ec9886a0e7a0d622e92/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L1814]
> for index summary redistributions
> CASSANDRA-14935 also introduced a bug where we track the wrong sstables for
> index summary redistributions
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15054) COPY DATETIMEFORMAT is applicable for all DATE/TS columns in a given file, instead it should be able to be specified per column
Devopam Mittra created CASSANDRA-15054: -- Summary: COPY DATETIMEFORMAT is applicable for all DATE/TS columns in a given file, instead it should be able to be specified per column Key: CASSANDRA-15054 URL: https://issues.apache.org/jira/browse/CASSANDRA-15054 Project: Cassandra Issue Type: Improvement Components: CQL/Syntax Reporter: Devopam Mittra Fix For: 3.0.x Currently we have an ability to specify a custom date/timestamp format per file load/extract using COPY utility via DATETIMEFORMAT option. This puts a limitation that all date/ts columns in a particular csv have to conform to the same format. e.g. my file has DOB and incorporation_date for an employee. But the format for both is not same since they come from different systems. So, I don't have the ability yet in C* to handle this situation (which is quite common given a disparate ecosystem of extracts). We should be able to rather specifiy the format for each date/ts field separately instead for ease of ingestion especially. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15053) Fix handling FS errors on writing and reading flat files - LogTransaction and hints
[ https://issues.apache.org/jira/browse/CASSANDRA-15053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-15053: -- Reviewers: Ariel Weisberg, Blake Eggleston, Marcus Eriksson > Fix handling FS errors on writing and reading flat files - LogTransaction and > hints > --- > > Key: CASSANDRA-15053 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15053 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Hints >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Normal > Fix For: 4.0, 3.0.x, 3.11.x > > > We currently fail to handle and propagate IO errors when dealing with > transaction log and hints. It's trivial to fix this behaviour to ensure that > disk failure policy is properly invoked in error scenarios. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15053) Fix handling FS errors on writing and reading flat files - LogTransaction and hints
Aleksey Yeschenko created CASSANDRA-15053: - Summary: Fix handling FS errors on writing and reading flat files - LogTransaction and hints Key: CASSANDRA-15053 URL: https://issues.apache.org/jira/browse/CASSANDRA-15053 Project: Cassandra Issue Type: Bug Components: Consistency/Hints Reporter: Jeff Jirsa Assignee: Jeff Jirsa Fix For: 4.0, 3.0.x, 3.11.x We currently fail to handle and propagate IO errors when dealing with transaction log and hints. It's trivial to fix this behaviour to ensure that disk failure policy is properly invoked in error scenarios. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14806) CircleCI workflow improvements and Java 11 support
[
https://issues.apache.org/jira/browse/CASSANDRA-14806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14806:
Status: Resolved (was: Ready to Commit)
> CircleCI workflow improvements and Java 11 support
> --
>
> Key: CASSANDRA-14806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14806
> Project: Cassandra
> Issue Type: Improvement
> Components: Build, Legacy/Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
> Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0
>
>
> The current CircleCI config could use some cleanup and improvements. First of
> all, the config has been made more modular by using the new CircleCI 2.1
> executors and command elements. Based on CASSANDRA-14713, there's now also a
> Java 11 executor that will allow running tests under Java 11. The {{build}}
> step will be done using Java 11 in all cases, so we can catch any regressions
> for that and also test the Java 11 multi-jar artifact during dtests, that
> we'd also create during the release process.
> The job workflow has now also been changed to make use of the [manual job
> approval|https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval]
> feature, which now allows running dtest jobs only on request and not
> automatically with every commit. The Java8 unit tests still do, but that
> could also be easily changed if needed. See [example
> workflow|https://circleci.com/workflow-run/be25579d-3cbb-4258-9e19-b1f571873850]
> with start_ jobs being triggers needed manual approval for starting the
> actual jobs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14806) CircleCI workflow improvements and Java 11 support
[
https://issues.apache.org/jira/browse/CASSANDRA-14806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14806:
Fix Version/s: 4.0
3.11.5
3.0.19
2.2.15
> CircleCI workflow improvements and Java 11 support
> --
>
> Key: CASSANDRA-14806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14806
> Project: Cassandra
> Issue Type: Improvement
> Components: Build, Legacy/Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
> Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0
>
>
> The current CircleCI config could use some cleanup and improvements. First of
> all, the config has been made more modular by using the new CircleCI 2.1
> executors and command elements. Based on CASSANDRA-14713, there's now also a
> Java 11 executor that will allow running tests under Java 11. The {{build}}
> step will be done using Java 11 in all cases, so we can catch any regressions
> for that and also test the Java 11 multi-jar artifact during dtests, that
> we'd also create during the release process.
> The job workflow has now also been changed to make use of the [manual job
> approval|https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval]
> feature, which now allows running dtest jobs only on request and not
> automatically with every commit. The Java8 unit tests still do, but that
> could also be easily changed if needed. See [example
> workflow|https://circleci.com/workflow-run/be25579d-3cbb-4258-9e19-b1f571873850]
> with start_ jobs being triggers needed manual approval for starting the
> actual jobs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7423) Allow updating individual subfields of UDT
[ https://issues.apache.org/jira/browse/CASSANDRA-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-7423: Status: Resolved (was: Open) > Allow updating individual subfields of UDT > -- > > Key: CASSANDRA-7423 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7423 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Tupshin Harper >Assignee: Tyler Hobbs >Priority: Normal > Labels: LWT, client-impacting, cql, docs-impacting > Fix For: 3.6 > > > Since user defined types were implemented in CASSANDRA-5590 as blobs (you > have to rewrite the entire type in order to make any modifications), they > can't be safely used without LWT for any operation that wants to modify a > subset of the UDT's fields by any client process that is not authoritative > for the entire blob. > When trying to use UDTs to model complex records (particularly with nesting), > this is not an exceptional circumstance, this is the totally expected normal > situation. > The use of UDTs for anything non-trivial is harmful to either performance or > consistency or both. > edit: to clarify, i believe that most potential uses of UDTs should be > considered anti-patterns until/unless we have field-level r/w access to > individual elements of the UDT, with individual timestamps and standard LWW > semantics -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7396) Allow selecting Map values and Set elements
[ https://issues.apache.org/jira/browse/CASSANDRA-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-7396: Status: Resolved (was: Open) > Allow selecting Map values and Set elements > --- > > Key: CASSANDRA-7396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7396 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/CQL >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne >Priority: Normal > Labels: cql, docs-impacting > Fix For: 4.0 > > Attachments: 7396_unit_tests.txt > > > Allow "SELECT map['key]" and "SELECT list[index]." (Selecting a UDT subfield > is already supported.) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12749) Update a specific property of a UDT in list, from a table.
[
https://issues.apache.org/jira/browse/CASSANDRA-12749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taranbir Singh updated CASSANDRA-12749:
---
Status: Open (was: Resolved)
Requirement is:
Update "displayType:" of the TemplateParameter whose name='X_PARAM' and
templateId=afd01de6-bba9-4417-ab79-6851077f2f84.
where as in the solution the name in the table CustomTemplate is checked
instead of the one in TemplateParameters. This runs the query in the outermost
table's column hence it seems like this is not resolved
> Update a specific property of a UDT in list, from a table.
> ---
>
> Key: CASSANDRA-12749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12749
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
> Environment: Development
>Reporter: Rajashekhar Sheela
>Priority: Urgent
> Fix For: 3.0.6
>
>
> I have a table with set as following...
> CREATE TABLE IF NOT EXISTS CustomTemplate (
> name text,
> templateId uuid,
> serviceId uuid,
> tenants set,
> templateXml text,
> xpath text,
> parameters list>,
> PRIMARY KEY (templateId)
> );
> CREATE TYPE IF NOT EXISTS TemplateParameter (
> name text,
> label text,
> type text,
> displayType text,
> allowedValues list
> );
> Sample Data:
> cqlsh:skyfall_customtemplate> select * from customtemplate ;
> templateid | name| parameters
> |
> serviceid| templatexml | tenants | xpath
> --+-+--+--+-+-+
> afd01de6-bba9-4417-ab79-6851077f2f84 | testMyTemplate2 | [{name: 'X_PARAM',
> label: null, type: 'String', displaytype: null, allowedvalues: null}] |
> 82d565cb-d286-4523-a377-add72af9b23f | xml |null | /xpath
> Requirement is:
>
> Update "displayType:" of the TemplateParameter whose name='X_PARAM' and
> templateId=afd01de6-bba9-4417-ab79-6851077f2f84.
> Not able to do this, please let know, how it can be done, if it is already
> possible.
> Thanks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14806) CircleCI workflow improvements and Java 11 support
[
https://issues.apache.org/jira/browse/CASSANDRA-14806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793506#comment-16793506
]
Marcus Eriksson commented on CASSANDRA-14806:
-
committed to 2.2 {{7333c2b04d6a876ff9734ca576caecace843fdab}} and merged up,
thanks!
> CircleCI workflow improvements and Java 11 support
> --
>
> Key: CASSANDRA-14806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14806
> Project: Cassandra
> Issue Type: Improvement
> Components: Build, Legacy/Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
>
> The current CircleCI config could use some cleanup and improvements. First of
> all, the config has been made more modular by using the new CircleCI 2.1
> executors and command elements. Based on CASSANDRA-14713, there's now also a
> Java 11 executor that will allow running tests under Java 11. The {{build}}
> step will be done using Java 11 in all cases, so we can catch any regressions
> for that and also test the Java 11 multi-jar artifact during dtests, that
> we'd also create during the release process.
> The job workflow has now also been changed to make use of the [manual job
> approval|https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval]
> feature, which now allows running dtest jobs only on request and not
> automatically with every commit. The Java8 unit tests still do, but that
> could also be easily changed if needed. See [example
> workflow|https://circleci.com/workflow-run/be25579d-3cbb-4258-9e19-b1f571873850]
> with start_ jobs being triggers needed manual approval for starting the
> actual jobs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14806) CircleCI workflow improvements and Java 11 support
[
https://issues.apache.org/jira/browse/CASSANDRA-14806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14806:
Status: Ready to Commit (was: Review In Progress)
> CircleCI workflow improvements and Java 11 support
> --
>
> Key: CASSANDRA-14806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14806
> Project: Cassandra
> Issue Type: Improvement
> Components: Build, Legacy/Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
>
> The current CircleCI config could use some cleanup and improvements. First of
> all, the config has been made more modular by using the new CircleCI 2.1
> executors and command elements. Based on CASSANDRA-14713, there's now also a
> Java 11 executor that will allow running tests under Java 11. The {{build}}
> step will be done using Java 11 in all cases, so we can catch any regressions
> for that and also test the Java 11 multi-jar artifact during dtests, that
> we'd also create during the release process.
> The job workflow has now also been changed to make use of the [manual job
> approval|https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval]
> feature, which now allows running dtest jobs only on request and not
> automatically with every commit. The Java8 unit tests still do, but that
> could also be easily changed if needed. See [example
> workflow|https://circleci.com/workflow-run/be25579d-3cbb-4258-9e19-b1f571873850]
> with start_ jobs being triggers needed manual approval for starting the
> actual jobs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14806) CircleCI workflow improvements and Java 11 support
[
https://issues.apache.org/jira/browse/CASSANDRA-14806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14806:
Status: Review In Progress (was: Patch Available)
> CircleCI workflow improvements and Java 11 support
> --
>
> Key: CASSANDRA-14806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14806
> Project: Cassandra
> Issue Type: Improvement
> Components: Build, Legacy/Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
>
> The current CircleCI config could use some cleanup and improvements. First of
> all, the config has been made more modular by using the new CircleCI 2.1
> executors and command elements. Based on CASSANDRA-14713, there's now also a
> Java 11 executor that will allow running tests under Java 11. The {{build}}
> step will be done using Java 11 in all cases, so we can catch any regressions
> for that and also test the Java 11 multi-jar artifact during dtests, that
> we'd also create during the release process.
> The job workflow has now also been changed to make use of the [manual job
> approval|https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval]
> feature, which now allows running dtest jobs only on request and not
> automatically with every commit. The Java8 unit tests still do, but that
> could also be easily changed if needed. See [example
> workflow|https://circleci.com/workflow-run/be25579d-3cbb-4258-9e19-b1f571873850]
> with start_ jobs being triggers needed manual approval for starting the
> actual jobs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (84fc68c -> 0c2d992)
This is an automated email from the ASF dual-hosted git repository. marcuse pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 84fc68c Fix copyright years in generated apidocs and in the NOTICE file new 7333c2b Refactor Circle CI configuration new 7bda2a0 Merge branch 'cassandra-2.2' into cassandra-3.0 new 0c2d992 Merge branch 'cassandra-3.0' into cassandra-3.11 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .circleci/config-2_1.yml| 463 ++ .circleci/config-2_1.yml.high_res.patch | 16 + .circleci/config.yml| 1528 +++ .circleci/config.yml.HIGHRES| 1160 +++ .circleci/config.yml.LOWRES | 1160 +++ .circleci/generate.sh |9 + .circleci/readme.md | 32 + CHANGES.txt |1 + build.xml | 11 + 9 files changed, 3978 insertions(+), 402 deletions(-) create mode 100644 .circleci/config-2_1.yml create mode 100644 .circleci/config-2_1.yml.high_res.patch create mode 100644 .circleci/config.yml.HIGHRES create mode 100644 .circleci/config.yml.LOWRES create mode 100755 .circleci/generate.sh create mode 100644 .circleci/readme.md - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (67d6132 -> 7bda2a0)
This is an automated email from the ASF dual-hosted git repository. marcuse pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 67d6132 ninja fix: Remove unnecessary CHANGES.txt entry from CASSANDRA-15012 new 7333c2b Refactor Circle CI configuration new 7bda2a0 Merge branch 'cassandra-2.2' into cassandra-3.0 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .circleci/config-2_1.yml| 448 ++ .circleci/config-2_1.yml.high_res.patch | 16 + .circleci/config.yml| 1471 ++- .circleci/config.yml.HIGHRES| 1095 +++ .circleci/config.yml.LOWRES | 1095 +++ .circleci/generate.sh |9 + .circleci/readme.md | 32 + CHANGES.txt |1 + build.xml | 11 + 9 files changed, 3772 insertions(+), 406 deletions(-) create mode 100644 .circleci/config-2_1.yml create mode 100644 .circleci/config-2_1.yml.high_res.patch create mode 100644 .circleci/config.yml.HIGHRES create mode 100644 .circleci/config.yml.LOWRES create mode 100755 .circleci/generate.sh create mode 100644 .circleci/readme.md - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (fd860b9 -> a851962)
This is an automated email from the ASF dual-hosted git repository. marcuse pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from fd860b9 Make TableCQLHelper reuse the single quote pattern new 7333c2b Refactor Circle CI configuration new 7bda2a0 Merge branch 'cassandra-2.2' into cassandra-3.0 new 0c2d992 Merge branch 'cassandra-3.0' into cassandra-3.11 new a851962 Merge branch 'cassandra-3.11' into trunk The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .circleci/config-2_1.yml | 558 ++ .circleci/config-2_1.yml.high_res.patch| 22 + .circleci/config.yml | 1996 .circleci/config.yml.HIGHRES | 1630 .circleci/config.yml.LOWRES| 1630 .circleci/generate.sh |9 + .circleci/readme.md| 32 + CHANGES.txt|1 + build.xml | 46 + .../dht/tokenallocator/TokenAllocatorTestBase.java |6 + 10 files changed, 5529 insertions(+), 401 deletions(-) create mode 100644 .circleci/config-2_1.yml create mode 100644 .circleci/config-2_1.yml.high_res.patch create mode 100644 .circleci/config.yml.HIGHRES create mode 100644 .circleci/config.yml.LOWRES create mode 100755 .circleci/generate.sh create mode 100644 .circleci/readme.md - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7396) Allow selecting Map values and Set elements
[ https://issues.apache.org/jira/browse/CASSANDRA-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anonymous updated CASSANDRA-7396: - Status: Open (was: Resolved) > Allow selecting Map values and Set elements > --- > > Key: CASSANDRA-7396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7396 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/CQL >Reporter: Jonathan Ellis >Assignee: Sylvain Lebresne >Priority: Normal > Labels: cql, docs-impacting > Fix For: 4.0 > > Attachments: 7396_unit_tests.txt > > > Allow "SELECT map['key]" and "SELECT list[index]." (Selecting a UDT subfield > is already supported.) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7423) Allow updating individual subfields of UDT
[ https://issues.apache.org/jira/browse/CASSANDRA-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anonymous updated CASSANDRA-7423: - Status: Open (was: Resolved) > Allow updating individual subfields of UDT > -- > > Key: CASSANDRA-7423 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7423 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Tupshin Harper >Assignee: Tyler Hobbs >Priority: Normal > Labels: LWT, client-impacting, cql, docs-impacting > Fix For: 3.6 > > > Since user defined types were implemented in CASSANDRA-5590 as blobs (you > have to rewrite the entire type in order to make any modifications), they > can't be safely used without LWT for any operation that wants to modify a > subset of the UDT's fields by any client process that is not authoritative > for the entire blob. > When trying to use UDTs to model complex records (particularly with nesting), > this is not an exceptional circumstance, this is the totally expected normal > situation. > The use of UDTs for anything non-trivial is harmful to either performance or > consistency or both. > edit: to clarify, i believe that most potential uses of UDTs should be > considered anti-patterns until/unless we have field-level r/w access to > individual elements of the UDT, with individual timestamps and standard LWW > semantics -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
