[jira] [Commented] (CASSANDRA-13090) Coalescing strategy sleeps too much

2017-02-09 Thread Ariel Weisberg (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860606#comment-15860606
 ] 

Ariel Weisberg commented on CASSANDRA-13090:


Get set up with cassci anyways, but I rolled it again because I realized we 
should do this back to 2.2. 2.1 is critical fixes only and I don't think this 
counts. It's off by default in 2.1.

> Coalescing strategy sleeps too much
> ---
>
> Key: CASSANDRA-13090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13090
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
> Attachments: 0001-Fix-wait-time-coalescing-CASSANDRA-13090-2.patch, 
> 0001-Fix-wait-time-coalescing-CASSANDRA-13090.patch
>
>
> With the current code maybeSleep is called even if we managed to take 
> maxItems out of the backlog. In this case we should really avoid sleeping 
> because it means that backlog is building up.
> I'll send a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (CASSANDRA-13090) Coalescing strategy sleeps too much

2017-02-09 Thread Ariel Weisberg (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15845655#comment-15845655
 ] 

Ariel Weisberg edited comment on CASSANDRA-13090 at 2/10/17 3:10 AM:
-

||code|utests|dtests||
|[2.2|https://github.com/apache/cassandra/compare/cassandra-2.2...aweisberg:cassandra-13090-2.2?expand=1]|[utest|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-2.2-testall/1]|[dtest|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-2.2-dtest/1]|
|[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...aweisberg:cassandra-13090-3.0?expand=1]|[utest|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-3.0-testall/4]|[dtest|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-3.0-dtest/4]|
|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...aweisberg:cassandra-13090-3.11?expand=1]|[utest|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-3.11-testall/5]|[dtest|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-3.11-dtest/5]|
|[trunk|https://github.com/apache/cassandra/compare/trunk...aweisberg:cassandra-13090-trunk?expand=1]|[utest|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-trunk-testall/5]|[dtest|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-3.11-dtest/5]|

Seem to be a few test failures in 3.11 and on. Maybe I messed up the merge 
forward? [~iksaif] can you take a look?


was (Author: aweisberg):
||code|utests|dtests||
|[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...aweisberg:cassandra-13090-3.0?expand=1]|[utest|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-3.0-testall/4]|[dtest|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-3.0-dtest/4]|
|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...aweisberg:cassandra-13090-3.11?expand=1]|[utest|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-3.11-testall/5]|[dtest|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-3.11-dtest/5]|
|[trunk|https://github.com/apache/cassandra/compare/trunk...aweisberg:cassandra-13090-trunk?expand=1]|[utest|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-trunk-testall/5]|[dtest|https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-3.11-dtest/5]|

Seem to be a few test failures in 3.11 and on. Maybe I messed up the merge 
forward? [~iksaif] can you take a look?

> Coalescing strategy sleeps too much
> ---
>
> Key: CASSANDRA-13090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13090
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
> Attachments: 0001-Fix-wait-time-coalescing-CASSANDRA-13090-2.patch, 
> 0001-Fix-wait-time-coalescing-CASSANDRA-13090.patch
>
>
> With the current code maybeSleep is called even if we managed to take 
> maxItems out of the backlog. In this case we should really avoid sleeping 
> because it means that backlog is building up.
> I'll send a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (CASSANDRA-13204) Thread Leak in OutboundTcpConnection

2017-02-09 Thread Ariel Weisberg (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860572#comment-15860572
 ] 

Ariel Weisberg edited comment on CASSANDRA-13204 at 2/10/17 3:07 AM:
-

* [Did you finish this 
comment?|https://github.com/apache/cassandra/compare/trunk...jasobrown:13204-trunk?expand=1#diff-c7ef124561c4cde1c906f28ad3883a88R184]
* --[This would cause a concurrent modification exception with the 
iterator|https://github.com/apache/cassandra/compare/cassandra-2.1...jasobrown:13204-2.1?expand=1#diff-c7ef124561c4cde1c906f28ad3883a88R225]--
 Never mind forgot about the jump.
* [It's not clear to me that you need to move the 
backlog.clear()?|https://github.com/apache/cassandra/compare/cassandra-2.1...jasobrown:13204-2.1?expand=1#diff-c7ef124561c4cde1c906f28ad3883a88L164]

I think I understand the issue. A failed connection clobbers the sentinel with 
backlog.clear(). You fixed the clobbering by relegating the sentinel to just a 
tool to wake up the thread. The flag is controlling the loop and the break will 
make it out to check the loop condition if a connection fails.


was (Author: aweisberg):
* [Did you finish this 
comment?|https://github.com/apache/cassandra/compare/trunk...jasobrown:13204-trunk?expand=1#diff-c7ef124561c4cde1c906f28ad3883a88R184]
* [This would cause a concurrent modification exception with the 
iterator|https://github.com/apache/cassandra/compare/cassandra-2.1...jasobrown:13204-2.1?expand=1#diff-c7ef124561c4cde1c906f28ad3883a88R225]
* [It's not clear to me that you need to move the 
backlog.clear()?|https://github.com/apache/cassandra/compare/cassandra-2.1...jasobrown:13204-2.1?expand=1#diff-c7ef124561c4cde1c906f28ad3883a88L164]

I think I understand the issue. A failed connection clobbers the sentinel with 
backlog.clear(). You fixed the clobbering by relegating the sentinel to just a 
tool to wake up the thread. The flag is controlling the loop and the break will 
make it out to check the loop condition if a connection fails.

> Thread Leak in OutboundTcpConnection
> 
>
> Key: CASSANDRA-13204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13204
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jason Brown
> Fix For: 3.0.11, 2.1.x, 2.2.x, 3.11.x
>
>
> We found threads leaking from OutboundTcpConnection to machines which are not 
> part of the cluster and still in Gossip for some reason. There are two issues 
> here, this JIRA will cover the second one which is most important. 
> 1) First issue is that Gossip has information about machines not in the ring 
> which has been replaced out. It causes Cassandra to connect to those machines 
> but due to internode auth, it wont be able to connect to them at the socket 
> level.  
> 2) Second issue is a race between creating a connection and closing a 
> connections which is triggered by the gossip bug explained above. Let me try 
> to explain it using the code
> In OutboundTcpConnection, we are calling closeSocket(true) which will set 
> isStopped=true and also put a close sentinel into the queue to exit the 
> thread. On the ack connection, Gossip tries to send a message which calls 
> connect() which will block for 10 seconds which is RPC timeout. The reason we 
> will block is because Cassandra might not be running there or internode auth 
> will not let it connect. During this 10 seconds, if Gossip calls closeSocket, 
> it will put close sentinel into the queue. When we return from the connect 
> method after 10 seconds, we will clear the backlog queue causing this thread 
> to leak. 
> Proofs from the heap dump of the affected machine which is leaking threads 
> 1. Only ack connection is leaking and not the command connection which is not 
> used by Gossip. 
> 2. We see thread blocked on the backlog queue, isStopped=true and backlog 
> queue is empty. This is happening on the threads which have already leaked. 
> 3. A running thread was blocked on the connect waiting for timeout(10 
> seconds) and we see backlog queue to contain the close sentinel. Once the 
> connect will return false, we will clear the backlog and this thread will 
> have leaked.  
> Interesting bits from j stack 
> 1282 number of threads for "MessagingService-Outgoing-/"
> Thread which is about to leak:
> "MessagingService-Outgoing-/" 
>java.lang.Thread.State: RUNNABLE
>   at sun.nio.ch.Net.connect0(Native Method)
>   at sun.nio.ch.Net.connect(Net.java:454)
>   at sun.nio.ch.Net.connect(Net.java:446)
>   at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   at 
> 

[jira] [Updated] (CASSANDRA-13090) Coalescing strategy sleeps too much

2017-02-09 Thread Ariel Weisberg (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ariel Weisberg updated CASSANDRA-13090:
---
Fix Version/s: 4.x
   3.0.x
   2.2.x

> Coalescing strategy sleeps too much
> ---
>
> Key: CASSANDRA-13090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13090
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
> Attachments: 0001-Fix-wait-time-coalescing-CASSANDRA-13090-2.patch, 
> 0001-Fix-wait-time-coalescing-CASSANDRA-13090.patch
>
>
> With the current code maybeSleep is called even if we managed to take 
> maxItems out of the backlog. In this case we should really avoid sleeping 
> because it means that backlog is building up.
> I'll send a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13204) Thread Leak in OutboundTcpConnection

2017-02-09 Thread Ariel Weisberg (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860572#comment-15860572
 ] 

Ariel Weisberg commented on CASSANDRA-13204:


* [Did you finish this 
comment?|https://github.com/apache/cassandra/compare/trunk...jasobrown:13204-trunk?expand=1#diff-c7ef124561c4cde1c906f28ad3883a88R184]
* [This would cause a concurrent modification exception with the 
iterator|https://github.com/apache/cassandra/compare/cassandra-2.1...jasobrown:13204-2.1?expand=1#diff-c7ef124561c4cde1c906f28ad3883a88R225]
* [It's not clear to me that you need to move the 
backlog.clear()?|https://github.com/apache/cassandra/compare/cassandra-2.1...jasobrown:13204-2.1?expand=1#diff-c7ef124561c4cde1c906f28ad3883a88L164]

I think I understand the issue. A failed connection clobbers the sentinel with 
backlog.clear(). You fixed the clobbering by relegating the sentinel to just a 
tool to wake up the thread. The flag is controlling the loop and the break will 
make it out to check the loop condition if a connection fails.

> Thread Leak in OutboundTcpConnection
> 
>
> Key: CASSANDRA-13204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13204
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jason Brown
> Fix For: 3.0.11, 2.1.x, 2.2.x, 3.11.x
>
>
> We found threads leaking from OutboundTcpConnection to machines which are not 
> part of the cluster and still in Gossip for some reason. There are two issues 
> here, this JIRA will cover the second one which is most important. 
> 1) First issue is that Gossip has information about machines not in the ring 
> which has been replaced out. It causes Cassandra to connect to those machines 
> but due to internode auth, it wont be able to connect to them at the socket 
> level.  
> 2) Second issue is a race between creating a connection and closing a 
> connections which is triggered by the gossip bug explained above. Let me try 
> to explain it using the code
> In OutboundTcpConnection, we are calling closeSocket(true) which will set 
> isStopped=true and also put a close sentinel into the queue to exit the 
> thread. On the ack connection, Gossip tries to send a message which calls 
> connect() which will block for 10 seconds which is RPC timeout. The reason we 
> will block is because Cassandra might not be running there or internode auth 
> will not let it connect. During this 10 seconds, if Gossip calls closeSocket, 
> it will put close sentinel into the queue. When we return from the connect 
> method after 10 seconds, we will clear the backlog queue causing this thread 
> to leak. 
> Proofs from the heap dump of the affected machine which is leaking threads 
> 1. Only ack connection is leaking and not the command connection which is not 
> used by Gossip. 
> 2. We see thread blocked on the backlog queue, isStopped=true and backlog 
> queue is empty. This is happening on the threads which have already leaked. 
> 3. A running thread was blocked on the connect waiting for timeout(10 
> seconds) and we see backlog queue to contain the close sentinel. Once the 
> connect will return false, we will clear the backlog and this thread will 
> have leaked.  
> Interesting bits from j stack 
> 1282 number of threads for "MessagingService-Outgoing-/"
> Thread which is about to leak:
> "MessagingService-Outgoing-/" 
>java.lang.Thread.State: RUNNABLE
>   at sun.nio.ch.Net.connect0(Native Method)
>   at sun.nio.ch.Net.connect(Net.java:454)
>   at sun.nio.ch.Net.connect(Net.java:446)
>   at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:137)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:119)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.connect(OutboundTcpConnection.java:381)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:217)
> Thread already leaked:
> "MessagingService-Outgoing-/"
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> 

[jira] [Created] (CASSANDRA-13207) test failure in org.apache.cassandra.db.compaction.PendingRepairManagerTest.maximalTaskNeedsCleanup

2017-02-09 Thread Michael Shuler (JIRA)
Michael Shuler created CASSANDRA-13207:
--

 Summary: test failure in 
org.apache.cassandra.db.compaction.PendingRepairManagerTest.maximalTaskNeedsCleanup
 Key: CASSANDRA-13207
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13207
 Project: Cassandra
  Issue Type: Bug
Reporter: Michael Shuler


example failure:

http://cassci.datastax.com/job/trunk_testall/1396/testReport/org.apache.cassandra.db.compaction/PendingRepairManagerTest/maximalTaskNeedsCleanup

{noformat}
Stacktrace

java.lang.NullPointerException
at 
org.apache.cassandra.db.compaction.PendingRepairManagerTest.maximalTaskNeedsCleanup(PendingRepairManagerTest.java:182)
Standard Output

ERROR [main] 2017-02-09 23:00:16,661 ?:? - SLF4J: stderr
INFO  [main] 2017-02-09 23:00:16,881 ?:? - Configuration location: 
file:/home/automaton/cassandra/test/conf/cassandra.yaml
DEBUG [main] 2017-02-09 23:00:16,884 ?:? - Loading settings from 
file:/home/automaton/cassandra/test/conf/cassandra.yaml
INFO  [main] 2017-02-09 23:00:17,550 ?:? - Node 
configuration:[allocate_tokens_for_keyspace=null; authenticator=null; 
authorizer=null; auto_bootstrap=true; auto_snapshot=true; 
back_pressure_enabled=false; back_pressure_strategy=null; 
batch_size_fail_threshold_in_kb=50; batch_size_warn_threshold_in_kb=5; 
batchlog_replay_throttle_in_kb=1024; broadcast_address=null; 
broadcast_rpc_address=null; buffer_pool_use_heap_if_exhausted=true; 
cas_contention_timeout_in_ms=1000; cdc_enabled=false; 
cdc_free_space_check_interval_ms=250; 
cdc_raw_directory=build/test/cassandra/cdc_raw:165; cdc_total_space_in_mb=0; 
client_encryption_options=; cluster_name=Test Cluster; 
column_index_cache_size_in_kb=2; column_index_size_in_kb=4; 
commit_failure_policy=stop; commitlog_compression=null; 
commitlog_directory=build/test/cassandra/commitlog:165; 
commitlog_max_compression_buffers_in_pool=3; commitlog_periodic_queue_size=-1; 
commitlog_segment_size_in_mb=5; commitlog_sync=batch; 
commitlog_sync_batch_window_in_ms=1.0; commitlog_sync_period_in_ms=0; 
commitlog_total_space_in_mb=null; 
compaction_large_partition_warning_threshold_mb=100; 
compaction_throughput_mb_per_sec=0; concurrent_compactors=4; 
concurrent_counter_writes=32; concurrent_materialized_view_writes=32; 
concurrent_reads=32; concurrent_replicates=null; concurrent_writes=32; 
counter_cache_keys_to_save=2147483647; counter_cache_save_period=7200; 
counter_cache_size_in_mb=null; counter_write_request_timeout_in_ms=5000; 
credentials_cache_max_entries=1000; credentials_update_interval_in_ms=-1; 
credentials_validity_in_ms=2000; cross_node_timeout=false; 
data_file_directories=[Ljava.lang.String;@1757cd72; disk_access_mode=mmap; 
disk_failure_policy=ignore; disk_optimization_estimate_percentile=0.95; 
disk_optimization_page_cross_chance=0.1; disk_optimization_strategy=ssd; 
dynamic_snitch=true; dynamic_snitch_badness_threshold=0.1; 
dynamic_snitch_reset_interval_in_ms=60; 
dynamic_snitch_update_interval_in_ms=100; 
enable_scripted_user_defined_functions=true; 
enable_user_defined_functions=true; enable_user_defined_functions_threads=true; 
encryption_options=null; 
endpoint_snitch=org.apache.cassandra.locator.SimpleSnitch; 
file_cache_size_in_mb=null; gc_log_threshold_in_ms=200; 
gc_warn_threshold_in_ms=0; hinted_handoff_disabled_datacenters=[]; 
hinted_handoff_enabled=true; hinted_handoff_throttle_in_kb=1024; 
hints_compression=null; hints_directory=build/test/cassandra/hints:165; 
hints_flush_period_in_ms=1; incremental_backups=true; index_interval=null; 
index_summary_capacity_in_mb=null; index_summary_resize_interval_in_minutes=60; 
initial_token=null; inter_dc_stream_throughput_outbound_megabits_per_sec=200; 
inter_dc_tcp_nodelay=true; internode_authenticator=null; 
internode_compression=none; internode_recv_buff_size_in_bytes=0; 
internode_send_buff_size_in_bytes=0; key_cache_keys_to_save=2147483647; 
key_cache_save_period=14400; key_cache_size_in_mb=null; 
listen_address=127.0.0.1; listen_interface=null; 
listen_interface_prefer_ipv6=false; listen_on_broadcast_address=false; 
max_hint_window_in_ms=1080; max_hints_delivery_threads=2; 
max_hints_file_size_in_mb=128; max_mutation_size_in_kb=null; 
max_streaming_retries=3; max_value_size_in_mb=256; 
memtable_allocation_type=offheap_objects; memtable_cleanup_threshold=null; 
memtable_flush_writers=0; memtable_heap_space_in_mb=null; 
memtable_offheap_space_in_mb=null; min_free_space_per_drive_in_mb=50; 
native_transport_max_concurrent_connections=-1; 
native_transport_max_concurrent_connections_per_ip=-1; 
native_transport_max_frame_size_in_mb=256; native_transport_max_threads=128; 
native_transport_port=9207; native_transport_port_ssl=null; num_tokens=1; 
otc_coalescing_strategy=TIMEHORIZON; otc_coalescing_window_us=200; 
partitioner=org.apache.cassandra.dht.ByteOrderedPartitioner; 
permissions_cache_max_entries=1000; 

[jira] [Created] (CASSANDRA-13206) test failure in org.apache.cassandra.db.compaction.CompactionStrategyManagerPendingRepairTest.cleanupCompactionFinalized-compression

2017-02-09 Thread Michael Shuler (JIRA)
Michael Shuler created CASSANDRA-13206:
--

 Summary: test failure in 
org.apache.cassandra.db.compaction.CompactionStrategyManagerPendingRepairTest.cleanupCompactionFinalized-compression
 Key: CASSANDRA-13206
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13206
 Project: Cassandra
  Issue Type: Bug
Reporter: Michael Shuler


example failure:

http://cassci.datastax.com/job/trunk_testall/1396/testReport/org.apache.cassandra.db.compaction/CompactionStrategyManagerPendingRepairTest/cleanupCompactionFinalized_compression

{noformat}
Error Message

Index: 0, Size: 0
Stacktrace

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at 
org.apache.cassandra.db.compaction.PendingRepairManager.getNextBackgroundTask(PendingRepairManager.java:285)
at 
org.apache.cassandra.db.compaction.CompactionStrategyManager.lambda$getNextBackgroundTask$175(CompactionStrategyManager.java:152)
at 
org.apache.cassandra.db.compaction.CompactionStrategyManager$$Lambda$171/1299262669.get(Unknown
 Source)
at 
org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:163)
at 
org.apache.cassandra.db.compaction.CompactionStrategyManagerPendingRepairTest.cleanupCompactionFinalized(CompactionStrategyManagerPendingRepairTest.java:238)
Standard Output

ERROR [main] 2017-02-09 22:59:29,222 ?:? - SLF4J: stderr
INFO  [main] 2017-02-09 22:59:29,469 ?:? - Configuration location: 
file:/home/automaton/cassandra/test/conf/cassandra.yaml
DEBUG [main] 2017-02-09 22:59:29,472 ?:? - Loading settings from 
file:/home/automaton/cassandra/test/conf/cassandra.yaml
INFO  [main] 2017-02-09 22:59:30,552 ?:? - Node 
configuration:[allocate_tokens_for_keyspace=null; authenticator=null; 
authorizer=null; auto_bootstrap=true; auto_snapshot=true; 
back_pressure_enabled=f
...[truncated 58459 chars]...
7324.tbl compaction strategy for pending repair: 
6e3dd400-ef1b-11e6-a349-8bda75118b8f
DEBUG [main] 2017-02-09 22:59:37,470 ?:? - Setting repairedAt to 0 on 
BigTableReader(path='/home/automaton/cassandra/build/test/cassandra/data:157/ks_1486681177324/tbl-6e3129d0ef1b11e6a3498bda75118b8f/md-1-big-Data.db')
 for 6e3dd400-ef1b-11e6-a349-8bda75118b8f
DEBUG [main] 2017-02-09 22:59:37,472 ?:? - Removing compaction strategy for 
pending repair 6e3dd400-ef1b-11e6-a349-8bda75118b8f on  ks_1486681177324.tbl
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (CASSANDRA-12814) Batch read requests to same physical host

2017-02-09 Thread Dikang Gu (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dikang Gu reassigned CASSANDRA-12814:
-

Assignee: Dikang Gu

> Batch read requests to same physical host
> -
>
> Key: CASSANDRA-12814
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12814
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>  Labels: performance
>
> We have couple use cases that are doing fanout read for their data, means one 
> single read request from client contains multiple keys which live on 
> different physical hosts. (I know it's not recommended way to access C*).
> Right now, on the coordinator, it will issue separate read commands even 
> though they will go to the same physical host, which I think is causing a lot 
> of overheads.
> I think it's valuable to provide a new read command, that coordinator can 
> batch the reads to one datanode, and send to it in one message, and datanode 
> will return the results for all keys belong to it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13205) Hint related logging should include the IP address of the destination in addition to host ID

2017-02-09 Thread Blake Eggleston (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Blake Eggleston updated CASSANDRA-13205:

Status: Ready to Commit  (was: Patch Available)

> Hint related logging should include the IP address of the destination in 
> addition to host ID
> 
>
> Key: CASSANDRA-13205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13205
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Trivial
> Fix For: 3.0.x
>
>
> After the hint rewrite in 3.0, many of the hint related logs now use hostId 
> UUIDs rather than endpoint addresses. This complicates debugging 
> unnecessarily. We should include both.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13205) Hint related logging should include the IP address of the destination in addition to host ID

2017-02-09 Thread Blake Eggleston (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860435#comment-15860435
 ] 

Blake Eggleston commented on CASSANDRA-13205:
-

ok +1 then

> Hint related logging should include the IP address of the destination in 
> addition to host ID
> 
>
> Key: CASSANDRA-13205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13205
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Trivial
> Fix For: 3.0.x
>
>
> After the hint rewrite in 3.0, many of the hint related logs now use hostId 
> UUIDs rather than endpoint addresses. This complicates debugging 
> unnecessarily. We should include both.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13204) Thread Leak in OutboundTcpConnection

2017-02-09 Thread Jason Brown (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Brown updated CASSANDRA-13204:

Status: Patch Available  (was: Open)

> Thread Leak in OutboundTcpConnection
> 
>
> Key: CASSANDRA-13204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13204
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jason Brown
> Fix For: 3.0.11, 2.1.x, 2.2.x, 3.11.x
>
>
> We found threads leaking from OutboundTcpConnection to machines which are not 
> part of the cluster and still in Gossip for some reason. There are two issues 
> here, this JIRA will cover the second one which is most important. 
> 1) First issue is that Gossip has information about machines not in the ring 
> which has been replaced out. It causes Cassandra to connect to those machines 
> but due to internode auth, it wont be able to connect to them at the socket 
> level.  
> 2) Second issue is a race between creating a connection and closing a 
> connections which is triggered by the gossip bug explained above. Let me try 
> to explain it using the code
> In OutboundTcpConnection, we are calling closeSocket(true) which will set 
> isStopped=true and also put a close sentinel into the queue to exit the 
> thread. On the ack connection, Gossip tries to send a message which calls 
> connect() which will block for 10 seconds which is RPC timeout. The reason we 
> will block is because Cassandra might not be running there or internode auth 
> will not let it connect. During this 10 seconds, if Gossip calls closeSocket, 
> it will put close sentinel into the queue. When we return from the connect 
> method after 10 seconds, we will clear the backlog queue causing this thread 
> to leak. 
> Proofs from the heap dump of the affected machine which is leaking threads 
> 1. Only ack connection is leaking and not the command connection which is not 
> used by Gossip. 
> 2. We see thread blocked on the backlog queue, isStopped=true and backlog 
> queue is empty. This is happening on the threads which have already leaked. 
> 3. A running thread was blocked on the connect waiting for timeout(10 
> seconds) and we see backlog queue to contain the close sentinel. Once the 
> connect will return false, we will clear the backlog and this thread will 
> have leaked.  
> Interesting bits from j stack 
> 1282 number of threads for "MessagingService-Outgoing-/"
> Thread which is about to leak:
> "MessagingService-Outgoing-/" 
>java.lang.Thread.State: RUNNABLE
>   at sun.nio.ch.Net.connect0(Native Method)
>   at sun.nio.ch.Net.connect(Net.java:454)
>   at sun.nio.ch.Net.connect(Net.java:446)
>   at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:137)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:119)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.connect(OutboundTcpConnection.java:381)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:217)
> Thread already leaked:
> "MessagingService-Outgoing-/"
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$DisabledCoalescingStrategy.coalesceInternal(CoalescingStrategies.java:482)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$CoalescingStrategy.coalesce(CoalescingStrategies.java:213)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:190)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (CASSANDRA-13205) Hint related logging should include the IP address of the destination in addition to host ID

2017-02-09 Thread Jeff Jirsa (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860375#comment-15860375
 ] 

Jeff Jirsa edited comment on CASSANDRA-13205 at 2/9/17 11:20 PM:
-

Thanks [~bdeggleston]

{quote}
There are also a couple of log messages here and here in HintsReader that refer 
to hostId, and not endpoint
{quote}

Done.

{quote}
there's a warning in the 3.0 version of the HintVerbHandler that intends to log 
the table id here but does not
{quote}

In 
[3.11|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/hints/HintVerbHandler.java#L71],
 that warning no longer includes the table ID, so I've made the 3.0 version 
match that (removed the empty table ID, but added the endpoint address).



was (Author: jjirsa):
Thanks [~bdeggleston]

{quote}
There are also a couple of log messages here and here in HintsReader that refer 
to hostId, and not endpoint
{quote}

Done.

{quote}
there's a warning in the 3.0 version of the HintVerbHandler that intends to log 
the table id here but does not
{quote}

In 3.11, that warning no longer includes the table ID, so I've made the 3.0 
version match that (removed the empty table ID, but added the endpoint address).


> Hint related logging should include the IP address of the destination in 
> addition to host ID
> 
>
> Key: CASSANDRA-13205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13205
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Trivial
> Fix For: 3.0.x
>
>
> After the hint rewrite in 3.0, many of the hint related logs now use hostId 
> UUIDs rather than endpoint addresses. This complicates debugging 
> unnecessarily. We should include both.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13205) Hint related logging should include the IP address of the destination in addition to host ID

2017-02-09 Thread Jeff Jirsa (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860375#comment-15860375
 ] 

Jeff Jirsa commented on CASSANDRA-13205:


Thanks [~bdeggleston]

{quote}
There are also a couple of log messages here and here in HintsReader that refer 
to hostId, and not endpoint
{quote}

Done.

{quote}
there's a warning in the 3.0 version of the HintVerbHandler that intends to log 
the table id here but does not
{quote}

In 3.11, that warning no longer includes the table ID, so I've made the 3.0 
version match that (removed the empty table ID, but added the endpoint address).


> Hint related logging should include the IP address of the destination in 
> addition to host ID
> 
>
> Key: CASSANDRA-13205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13205
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Trivial
> Fix For: 3.0.x
>
>
> After the hint rewrite in 3.0, many of the hint related logs now use hostId 
> UUIDs rather than endpoint addresses. This complicates debugging 
> unnecessarily. We should include both.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (CASSANDRA-13204) Thread Leak in OutboundTcpConnection

2017-02-09 Thread Jason Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860348#comment-15860348
 ] 

Jason Brown edited comment on CASSANDRA-13204 at 2/9/17 10:52 PM:
--

A small change in the branches linked below should resolve the race condition. 
(The change identical across the branches as not much has changed in 
{{OutboundTcpConnection}} in quite a while).

Also fixed another minor problem: when we fail to connect ({{#connect()}} 
returns {{false}}), we want to drop *all* messages. Currently we clear the 
{{backlog}}, but if there's any remaining messages in the {{drainedMessages}}, 
we'll keep trying to process those. We should drop those messages, as well. 

Note: I thought about how to try to test this via a unit test, but as the 
interweaving of the of the shared state occurs in spots that are not easy to 
inject to, I'm not sure how best to test this change :-/ , Lacking anything 
else, running the standard unit tests and dtests on cassci:

||2.1||2.2||3.0||3.11||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/13204-2.1]|[branch|https://github.com/jasobrown/cassandra/tree/13204-2.2]|[branch|https://github.com/jasobrown/cassandra/tree/13204-3.0]|[branch|https://github.com/jasobrown/cassandra/tree/13204-3.11]|[branch|https://github.com/jasobrown/cassandra/tree/13204-trunk]|
|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-2.1-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-2.2-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-3.11-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-trunk-dtest/]|
|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-2.1-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-2.2-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-3.11-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-trunk-testall/]|



was (Author: jasobrown):
A small change in the branches linked below should resolve the race condition. 
(The change identical across the branches as not much has changed in 
{{OutboundTcpConnection}} in quite a while).

Also fixed another minor problem: when we fail to connect ({{#connect()}} 
return {{false}}), we want to drop *all* messages. Currently we clear the 
{{backlog}}, but if there's any remaining messages in the {{drainedMessages}}, 
we'll keep trying to process those. We should drop those messages, as well. 

Note: I thought about how to try to test this via a unit test, but as the 
interweaving of the of the shared state occurs in spots that are not easy to 
inject to, I'm not sure how best to test this change :-/ , Lacking anything 
else, running the standard unit tests and dtests on cassci:

||2.1||2.2||3.0||3.11||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/13204-2.1]|[branch|https://github.com/jasobrown/cassandra/tree/13204-2.2]|[branch|https://github.com/jasobrown/cassandra/tree/13204-3.0]|[branch|https://github.com/jasobrown/cassandra/tree/13204-3.11]|[branch|https://github.com/jasobrown/cassandra/tree/13204-trunk]|
|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-2.1-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-2.2-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-3.11-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-trunk-dtest/]|
|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-2.1-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-2.2-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-3.11-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-trunk-testall/]|


> Thread Leak in OutboundTcpConnection
> 
>
> Key: CASSANDRA-13204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13204
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jason Brown
> Fix For: 3.0.11, 2.1.x, 2.2.x, 3.11.x
>
>
> We found threads leaking from OutboundTcpConnection to machines which are not 
> part of the cluster and still in Gossip for some 

[jira] [Commented] (CASSANDRA-13204) Thread Leak in OutboundTcpConnection

2017-02-09 Thread Jason Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860348#comment-15860348
 ] 

Jason Brown commented on CASSANDRA-13204:
-

A small change in the branches linked below should resolve the race condition. 
(The change identical across the branches as not much has changed in 
{{OutboundTcpConnection}} in quite a while).

Also fixed another minor problem: when we fail to connect ({{#connect()}} 
return {{false}}), we want to drop *all* messages. Currently we clear the 
{{backlog}}, but if there's any remaining messages in the {{drainedMessages}}, 
we'll keep trying to process those. We should drop those messages, as well. 

Note: I thought about how to try to test this via a unit test, but as the 
interweaving of the of the shared state occurs in spots that are not easy to 
inject to, I'm not sure how best to test this change :-/ , Lacking anything 
else, running the standard unit tests and dtests on cassci:

||2.1||2.2||3.0||3.11||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/13204-2.1]|[branch|https://github.com/jasobrown/cassandra/tree/13204-2.2]|[branch|https://github.com/jasobrown/cassandra/tree/13204-3.0]|[branch|https://github.com/jasobrown/cassandra/tree/13204-3.11]|[branch|https://github.com/jasobrown/cassandra/tree/13204-trunk]|
|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-2.1-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-2.2-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-3.11-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-trunk-dtest/]|
|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-2.1-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-2.2-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-3.11-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-13204-trunk-testall/]|


> Thread Leak in OutboundTcpConnection
> 
>
> Key: CASSANDRA-13204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13204
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jason Brown
> Fix For: 3.0.11, 2.1.x, 2.2.x, 3.11.x
>
>
> We found threads leaking from OutboundTcpConnection to machines which are not 
> part of the cluster and still in Gossip for some reason. There are two issues 
> here, this JIRA will cover the second one which is most important. 
> 1) First issue is that Gossip has information about machines not in the ring 
> which has been replaced out. It causes Cassandra to connect to those machines 
> but due to internode auth, it wont be able to connect to them at the socket 
> level.  
> 2) Second issue is a race between creating a connection and closing a 
> connections which is triggered by the gossip bug explained above. Let me try 
> to explain it using the code
> In OutboundTcpConnection, we are calling closeSocket(true) which will set 
> isStopped=true and also put a close sentinel into the queue to exit the 
> thread. On the ack connection, Gossip tries to send a message which calls 
> connect() which will block for 10 seconds which is RPC timeout. The reason we 
> will block is because Cassandra might not be running there or internode auth 
> will not let it connect. During this 10 seconds, if Gossip calls closeSocket, 
> it will put close sentinel into the queue. When we return from the connect 
> method after 10 seconds, we will clear the backlog queue causing this thread 
> to leak. 
> Proofs from the heap dump of the affected machine which is leaking threads 
> 1. Only ack connection is leaking and not the command connection which is not 
> used by Gossip. 
> 2. We see thread blocked on the backlog queue, isStopped=true and backlog 
> queue is empty. This is happening on the threads which have already leaked. 
> 3. A running thread was blocked on the connect waiting for timeout(10 
> seconds) and we see backlog queue to contain the close sentinel. Once the 
> connect will return false, we will clear the backlog and this thread will 
> have leaked.  
> Interesting bits from j stack 
> 1282 number of threads for "MessagingService-Outgoing-/"
> Thread which is about to leak:
> "MessagingService-Outgoing-/" 
>java.lang.Thread.State: RUNNABLE
>   at sun.nio.ch.Net.connect0(Native Method)
>   at sun.nio.ch.Net.connect(Net.java:454)
>   at sun.nio.ch.Net.connect(Net.java:446)
>   at 

[jira] [Commented] (CASSANDRA-13205) Hint related logging should include the IP address of the destination in addition to host ID

2017-02-09 Thread Blake Eggleston (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860341#comment-15860341
 ] 

Blake Eggleston commented on CASSANDRA-13205:
-

There are also a couple of log messages 
[here|https://github.com/bdeggleston/cassandra/blob/af3fe39dcabd9ef77a00309ce6741268423206df/src/java/org/apache/cassandra/hints/HintsReader.java#L229-L229]
 and 
[here|https://github.com/bdeggleston/cassandra/blob/af3fe39dcabd9ef77a00309ce6741268423206df/src/java/org/apache/cassandra/hints/HintsReader.java#L242-L242]
 in HintsReader that refer to hostId, and not endpoint. Also, while you're in 
the area, there's a warning in the 3.0 version of the HintVerbHandler that 
intends to log the table id 
[here|https://github.com/jeffjirsa/cassandra/blob/033596b8174493d0840969fa15624c6c1426a0fc/src/java/org/apache/cassandra/hints/HintVerbHandler.java#L71]
 but does not.

> Hint related logging should include the IP address of the destination in 
> addition to host ID
> 
>
> Key: CASSANDRA-13205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13205
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Trivial
> Fix For: 3.0.x
>
>
> After the hint rewrite in 3.0, many of the hint related logs now use hostId 
> UUIDs rather than endpoint addresses. This complicates debugging 
> unnecessarily. We should include both.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13004) Corruption while adding a column to a table

2017-02-09 Thread Aleksey Yeschenko (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860307#comment-15860307
 ] 

Aleksey Yeschenko commented on CASSANDRA-13004:
---

I’ve looked at various code paths that could plausibly introduce corruption 
wtih {{CFMetaData changing during the request cycle}}:

1. Prepared statement execution ({{EXECUTE}} message, positionally matching 
byte buffers to types)
2. Write to the memtable, with {{CFMetaData}} changing during the update
3.  {{Memtable}} flush into sstable
4. sstable read

1. This yielded nothing. Our prepared {{ModificationStatement}} -s hold final 
immutable {{PartitionColumns}} in {{updatedColumns}}, and {{Operations}}. An 
added column at any point in the process should not trigger corruption - we do 
not use the consult {{CFMetaData}} to build {{PartitionUpdate}} objects for 
insertion.
2. {{AtomicBTreePartition}} constructor has an outdated comment back from 3.0.0 
beta days, reading as {{involved in potential bug? partition columns may be a 
subset if we alter columns while it's in memtable}}. It has, however, been 
addressed in CASSANDRA-10220. More importantly, it wouldn’t cause corruption in 
this case anyway, even if unaddressed. {{PartitionColumns}} object in the 
{{Holder}} is not used for sstable serialization.
3. {{UnfilteredSerializer.serialize()}} method has some logic that initially 
seemed dodgy to me, and that was the check for {{hasAllColumns}} merely 
comparing sizes of the row and of the known column set. I believe that that 
check is not completely solid, in case of column additions mixed with column 
removals, and can cause false positives. That said, we ‘d still error out later 
in the process, with an NPE when trying to get the type from 
{{SerializationHeader}} and fail the flush.
4. Likewise, nothing really relevant here. 

One reason that schema propagation might cause corruption is altering a column 
type. That is something we already handled, by disabling that capability in 
CASSANDRA-12443 (in the upcoming 3.0.11 release). Until then, I would advise 
strongly against using {{ALTER TABLE ALTER}} commands. But {{ALTER TABLE ADD}} 
should be safe, even with our rather imperfect schema code.

I have a feeling I’m not seeing the full story here. Without any new 
information, after a couple of us failed to replicate and/or analyse by 
following the code paths, I don’t think there is much we can do.

If you do by any chance have the corrupted sstables remaining from the 
incident, however, I will have another look.

Sorry for not being able to help.

> Corruption while adding a column to a table
> ---
>
> Key: CASSANDRA-13004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13004
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stanislav Vishnevskiy
>
> We had the following schema in production. 
> {code:none}
> CREATE TYPE IF NOT EXISTS discord_channels.channel_recipient (
> nick text
> );
> CREATE TYPE IF NOT EXISTS discord_channels.channel_permission_overwrite (
> id bigint,
> type int,
> allow_ int,
> deny int
> );
> CREATE TABLE IF NOT EXISTS discord_channels.channels (
> id bigint,
> guild_id bigint,
> type tinyint,
> name text,
> topic text,
> position int,
> owner_id bigint,
> icon_hash text,
> recipients map,
> permission_overwrites map,
> bitrate int,
> user_limit int,
> last_pin_timestamp timestamp,
> last_message_id bigint,
> PRIMARY KEY (id)
> );
> {code}
> And then we executed the following alter.
> {code:none}
> ALTER TABLE discord_channels.channels ADD application_id bigint;
> {code}
> And one row (that we can tell) got corrupted at the same time and could no 
> longer be read from the Python driver. 
> {code:none}
> [E 161206 01:56:58 geventreactor:141] Error decoding response from Cassandra. 
> ver(4); flags(); stream(27); op(8); offset(9); len(887); buffer: 
> 

[jira] [Commented] (CASSANDRA-12539) Empty CommitLog prevents restart

2017-02-09 Thread Joshua McKenzie (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860269#comment-15860269
 ] 

Joshua McKenzie commented on CASSANDRA-12539:
-

+1

> Empty CommitLog prevents restart
> 
>
> Key: CASSANDRA-12539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12539
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefano Ortolani
>Assignee: Benjamin Lerer
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> A node just crashed (known cause: CASSANDRA-11594) but to my surprise (unlike 
> other time) restarting simply fails.
> Checking the logs showed:
> {noformat}
> ERROR [main] 2016-08-25 17:05:22,611 JVMStabilityInspector.java:82 - Exiting 
> due to error while processing commit log during initialization.
> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
> Could not read commit log descriptor in file 
> /data/cassandra/commitlog/CommitLog-6-1468235564433.log
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:650)
>  [apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:327)
>  [apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:148)
>  [apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:181) 
> [apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:161) 
> [apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:289) 
> [apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:557)
>  [apache-cassandra-3.0.8.jar:3.0.8]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:685) 
> [apache-cassandra-3.0.8.jar:3.0.8]
> INFO  [main] 2016-08-25 17:08:56,944 YamlConfigurationLoader.java:85 - 
> Configuration location: file:/etc/cassandra/cassandra.yaml
> {noformat}
> Deleting the empty file fixes the problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13159) Coalescing strategy can enter infinite loop

2017-02-09 Thread Jeff Jirsa (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860246#comment-15860246
 ] 

Jeff Jirsa commented on CASSANDRA-13159:


[~iksaif] - I made a very minor logic change to your patch. Can you confirm 
you're OK with it?  {{!sleep}} became {{sleep <= 0}} . Also kicked off CI again 
on a few of the runs that showed failures, just to see if jenkins was unhappy 
or if we've somehow introduced something real.

> Coalescing strategy can enter infinite loop
> ---
>
> Key: CASSANDRA-13159
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13159
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 3.0.11, 2.1.x, 2.2.x, 3.11.x
>
>
> {code}boolean maybeSleep(int messages, long averageGap, long 
> maxCoalesceWindow, Parker parker){code} 
> maybeSleep() can enter an infinite loop if messages or averageGap ends up 
> being 0 because sleep will be 0 and the while loop will never exit. I've 
> noticed that on one of my clusters twice this week.
> This can happen if in averageGap() sum is bigger than MEASURED_INTERVAL, 
> which should be pretty rare but apparently happen to me.
> Even if the diagnostic is wrong (and I'm pretty sure that this thread was 
> using 100% CPU doing nothing), the fix seems pretty safe to apply.
> {code}
> diff --git a/src/java/org/apache/cassandra/utils/CoalescingStrategies.java 
> b/src/java/org/apache/cassandra/utils/CoalescingStrategies.java
> index 0aa980f..982d4a6 100644
> --- a/src/java/org/apache/cassandra/utils/CoalescingStrategies.java
> +++ b/src/java/org/apache/cassandra/utils/CoalescingStrategies.java
> @@ -100,7 +100,7 @@ public class CoalescingStrategies
>  {
>  // only sleep if we can expect to double the number of messages 
> we're sending in the time interval
>  long sleep = messages * averageGap;
> -if (sleep > maxCoalesceWindow)
> +if (!sleep || sleep > maxCoalesceWindow)
>  return false;
>  
>  // assume we receive as many messages as we expect; apply the same 
> logic to the future batch:
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13067) Integer overflows with file system size reported by Amazon Elastic File System (EFS)

2017-02-09 Thread Jeff Jirsa (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860230#comment-15860230
 ] 

Jeff Jirsa commented on CASSANDRA-13067:


Not assigned - nobody's currently looking at it. Patches are welcome, though.

> Integer overflows with file system size reported by Amazon Elastic File 
> System (EFS)
> 
>
> Key: CASSANDRA-13067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13067
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra in OpenShift running on Amazon EC2 instance 
> with EFS mounted for data
>Reporter: Michael Hanselmann
>
> When not explicitly configured Cassandra uses 
> [{{nio.FileStore.getTotalSpace}}|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html]
>  to determine the total amount of available space in order to [calculate the 
> preferred commit log 
> size|https://github.com/apache/cassandra/blob/cassandra-3.9/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L553].
>  [Amazon EFS|https://aws.amazon.com/efs/] instances report a filesystem size 
> of 8 EiB when empty. [{{getTotalSpace}} causes an integer overflow 
> (JDK-8162520)|https://bugs.openjdk.java.net/browse/JDK-8162520] and returns a 
> negative number, resulting in a negative preferred size and causing the 
> checked integer to throw.
> Overriding {{commitlog_total_space_in_mb}} is not sufficient as 
> [{{DataDirectory.getAvailableSpace}}|https://github.com/apache/cassandra/blob/cassandra-3.9/src/java/org/apache/cassandra/db/Directories.java#L550]
>  makes use of {{nio.FileStore.getUsableSpace}}.
> [AMQ-6441] is a comparable issue in ActiveMQ.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13067) Integer overflows with file system size reported by Amazon Elastic File System (EFS)

2017-02-09 Thread Matt Wringe (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860191#comment-15860191
 ] 

Matt Wringe commented on CASSANDRA-13067:
-

This also affects the 3.0 branch: 
https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L538

Is anyone looking into this?

> Integer overflows with file system size reported by Amazon Elastic File 
> System (EFS)
> 
>
> Key: CASSANDRA-13067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13067
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra in OpenShift running on Amazon EC2 instance 
> with EFS mounted for data
>Reporter: Michael Hanselmann
>
> When not explicitly configured Cassandra uses 
> [{{nio.FileStore.getTotalSpace}}|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html]
>  to determine the total amount of available space in order to [calculate the 
> preferred commit log 
> size|https://github.com/apache/cassandra/blob/cassandra-3.9/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L553].
>  [Amazon EFS|https://aws.amazon.com/efs/] instances report a filesystem size 
> of 8 EiB when empty. [{{getTotalSpace}} causes an integer overflow 
> (JDK-8162520)|https://bugs.openjdk.java.net/browse/JDK-8162520] and returns a 
> negative number, resulting in a negative preferred size and causing the 
> checked integer to throw.
> Overriding {{commitlog_total_space_in_mb}} is not sufficient as 
> [{{DataDirectory.getAvailableSpace}}|https://github.com/apache/cassandra/blob/cassandra-3.9/src/java/org/apache/cassandra/db/Directories.java#L550]
>  makes use of {{nio.FileStore.getUsableSpace}}.
> [AMQ-6441] is a comparable issue in ActiveMQ.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13173) Reloading logback.xml does not work

2017-02-09 Thread Robert Stupp (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-13173:
-
   Resolution: Fixed
Fix Version/s: (was: 3.0.x)
   4.0
   3.11.0
   3.0.11
   Status: Resolved  (was: Ready to Commit)

Thanks!

Committed as 
[e885886d5c92bfd8d2fa1596bfa86d6a5a8d89bb|https://github.com/apache/cassandra/commit/e885886d5c92bfd8d2fa1596bfa86d6a5a8d89bb]
 to [cassandra-3.0|https://github.com/apache/cassandra/tree/cassandra-3.0] and 
merged to trunk.

> Reloading logback.xml does not work
> ---
>
> Key: CASSANDRA-13173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13173
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.0.11, 3.11.0, 4.0
>
>
> Regression of CASSANDRA-12535
> Reloading of logback.xml is broken by CASSANDRA-12535 because the delegate 
> {{ReconfigureOnChangeFilter}} is not properly initialized.
> (Broken in 3.0.11 + 3.10)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[3/6] cassandra git commit: Reloading logback.xml does not work

2017-02-09 Thread snazy
Reloading logback.xml does not work

patch by Robert Stupp; reviewed by Yuki Morishita for CASSANDRA-13173


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e885886d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e885886d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e885886d

Branch: refs/heads/trunk
Commit: e885886d5c92bfd8d2fa1596bfa86d6a5a8d89bb
Parents: a696ab3
Author: Robert Stupp 
Authored: Thu Feb 9 21:43:43 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 21:45:44 2017 +0100

--
 CHANGES.txt   | 1 +
 .../cassandra/cql3/functions/ThreadAwareSecurityManager.java  | 7 +++
 2 files changed, 8 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e885886d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d8c1625..ae7b069 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.11
+ * Reloading logback.xml does not work (CASSANDRA-13173)
  * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
  * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
  * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e885886d/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java 
b/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java
index 676117d..3d97790 100644
--- 
a/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java
+++ 
b/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java
@@ -105,6 +105,13 @@ public final class ThreadAwareSecurityManager extends 
SecurityManager
 SMAwareReconfigureOnChangeFilter(ReconfigureOnChangeFilter 
reconfigureOnChangeFilter)
 {
 setRefreshPeriod(reconfigureOnChangeFilter.getRefreshPeriod());
+setName(reconfigureOnChangeFilter.getName());
+setContext(reconfigureOnChangeFilter.getContext());
+if (reconfigureOnChangeFilter.isStarted())
+{
+reconfigureOnChangeFilter.stop();
+start();
+}
 }
 
 protected boolean changeDetected(long now)



[6/6] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

2017-02-09 Thread snazy
Merge branch 'cassandra-3.11' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1ade491b
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1ade491b
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1ade491b

Branch: refs/heads/trunk
Commit: 1ade491bd4070a9e64a06aa699dd8a6edc3b66b1
Parents: 0811824 41393de
Author: Robert Stupp 
Authored: Thu Feb 9 21:46:06 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 21:46:06 2017 +0100

--
 CHANGES.txt   | 1 +
 .../cassandra/cql3/functions/ThreadAwareSecurityManager.java  | 7 +++
 2 files changed, 8 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1ade491b/CHANGES.txt
--



[1/6] cassandra git commit: Reloading logback.xml does not work

2017-02-09 Thread snazy
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 a696ab33b -> e885886d5
  refs/heads/cassandra-3.11 6d5cd2d45 -> 41393ded1
  refs/heads/trunk 0811824ab -> 1ade491bd


Reloading logback.xml does not work

patch by Robert Stupp; reviewed by Yuki Morishita for CASSANDRA-13173


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e885886d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e885886d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e885886d

Branch: refs/heads/cassandra-3.0
Commit: e885886d5c92bfd8d2fa1596bfa86d6a5a8d89bb
Parents: a696ab3
Author: Robert Stupp 
Authored: Thu Feb 9 21:43:43 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 21:45:44 2017 +0100

--
 CHANGES.txt   | 1 +
 .../cassandra/cql3/functions/ThreadAwareSecurityManager.java  | 7 +++
 2 files changed, 8 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e885886d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d8c1625..ae7b069 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.11
+ * Reloading logback.xml does not work (CASSANDRA-13173)
  * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
  * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
  * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e885886d/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java 
b/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java
index 676117d..3d97790 100644
--- 
a/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java
+++ 
b/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java
@@ -105,6 +105,13 @@ public final class ThreadAwareSecurityManager extends 
SecurityManager
 SMAwareReconfigureOnChangeFilter(ReconfigureOnChangeFilter 
reconfigureOnChangeFilter)
 {
 setRefreshPeriod(reconfigureOnChangeFilter.getRefreshPeriod());
+setName(reconfigureOnChangeFilter.getName());
+setContext(reconfigureOnChangeFilter.getContext());
+if (reconfigureOnChangeFilter.isStarted())
+{
+reconfigureOnChangeFilter.stop();
+start();
+}
 }
 
 protected boolean changeDetected(long now)



[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

2017-02-09 Thread snazy
Merge branch 'cassandra-3.0' into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/41393ded
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/41393ded
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/41393ded

Branch: refs/heads/cassandra-3.11
Commit: 41393ded1fc934620b3fc48cf17c4bc9580dee14
Parents: 6d5cd2d e885886
Author: Robert Stupp 
Authored: Thu Feb 9 21:46:02 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 21:46:02 2017 +0100

--
 CHANGES.txt   | 1 +
 .../cassandra/cql3/functions/ThreadAwareSecurityManager.java  | 7 +++
 2 files changed, 8 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/41393ded/CHANGES.txt
--
diff --cc CHANGES.txt
index 3073fd7,ae7b069..0e5700f
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,11 -1,5 +1,12 @@@
 -3.0.11
 +3.11.0
 + * Move to FastThreadLocalThread and FastThreadLocal (CASSANDRA-13034)
 + * nodetool stopdaemon errors out (CASSANDRA-13030)
 + * Tables in system_distributed should not use gcgs of 0 (CASSANDRA-12954)
 + * Fix primary index calculation for SASI (CASSANDRA-12910)
 + * More fixes to the TokenAllocator (CASSANDRA-12990)
 + * NoReplicationTokenAllocator should work with zero replication factor 
(CASSANDRA-12983)
 +Merged from 3.0:
+  * Reloading logback.xml does not work (CASSANDRA-13173)
   * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
   * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
   * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/41393ded/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java
--



[2/6] cassandra git commit: Reloading logback.xml does not work

2017-02-09 Thread snazy
Reloading logback.xml does not work

patch by Robert Stupp; reviewed by Yuki Morishita for CASSANDRA-13173


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/e885886d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/e885886d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/e885886d

Branch: refs/heads/cassandra-3.11
Commit: e885886d5c92bfd8d2fa1596bfa86d6a5a8d89bb
Parents: a696ab3
Author: Robert Stupp 
Authored: Thu Feb 9 21:43:43 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 21:45:44 2017 +0100

--
 CHANGES.txt   | 1 +
 .../cassandra/cql3/functions/ThreadAwareSecurityManager.java  | 7 +++
 2 files changed, 8 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e885886d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index d8c1625..ae7b069 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.11
+ * Reloading logback.xml does not work (CASSANDRA-13173)
  * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
  * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
  * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e885886d/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java 
b/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java
index 676117d..3d97790 100644
--- 
a/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java
+++ 
b/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java
@@ -105,6 +105,13 @@ public final class ThreadAwareSecurityManager extends 
SecurityManager
 SMAwareReconfigureOnChangeFilter(ReconfigureOnChangeFilter 
reconfigureOnChangeFilter)
 {
 setRefreshPeriod(reconfigureOnChangeFilter.getRefreshPeriod());
+setName(reconfigureOnChangeFilter.getName());
+setContext(reconfigureOnChangeFilter.getContext());
+if (reconfigureOnChangeFilter.isStarted())
+{
+reconfigureOnChangeFilter.stop();
+start();
+}
 }
 
 protected boolean changeDetected(long now)



[4/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

2017-02-09 Thread snazy
Merge branch 'cassandra-3.0' into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/41393ded
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/41393ded
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/41393ded

Branch: refs/heads/trunk
Commit: 41393ded1fc934620b3fc48cf17c4bc9580dee14
Parents: 6d5cd2d e885886
Author: Robert Stupp 
Authored: Thu Feb 9 21:46:02 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 21:46:02 2017 +0100

--
 CHANGES.txt   | 1 +
 .../cassandra/cql3/functions/ThreadAwareSecurityManager.java  | 7 +++
 2 files changed, 8 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/41393ded/CHANGES.txt
--
diff --cc CHANGES.txt
index 3073fd7,ae7b069..0e5700f
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,11 -1,5 +1,12 @@@
 -3.0.11
 +3.11.0
 + * Move to FastThreadLocalThread and FastThreadLocal (CASSANDRA-13034)
 + * nodetool stopdaemon errors out (CASSANDRA-13030)
 + * Tables in system_distributed should not use gcgs of 0 (CASSANDRA-12954)
 + * Fix primary index calculation for SASI (CASSANDRA-12910)
 + * More fixes to the TokenAllocator (CASSANDRA-12990)
 + * NoReplicationTokenAllocator should work with zero replication factor 
(CASSANDRA-12983)
 +Merged from 3.0:
+  * Reloading logback.xml does not work (CASSANDRA-13173)
   * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
   * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
   * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/41393ded/src/java/org/apache/cassandra/cql3/functions/ThreadAwareSecurityManager.java
--



[jira] [Updated] (CASSANDRA-10540) RangeAwareCompaction

2017-02-09 Thread Marcus Eriksson (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-10540:

Fix Version/s: (was: 3.11.x)
   4.x

> RangeAwareCompaction
> 
>
> Key: CASSANDRA-10540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10540
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>  Labels: compaction, lcs, vnodes
> Fix For: 4.x
>
>
> Broken out from CASSANDRA-6696, we should split sstables based on ranges 
> during compaction.
> Requirements;
> * dont create tiny sstables - keep them bunched together until a single vnode 
> is big enough (configurable how big that is)
> * make it possible to run existing compaction strategies on the per-range 
> sstables
> We should probably add a global compaction strategy parameter that states 
> whether this should be enabled or not.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13114) Upgrade netty to 4.0.44 to fix memory leak with client encryption

2017-02-09 Thread Robert Stupp (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-13114:
-
   Resolution: Fixed
Fix Version/s: 4.0
   3.11.0
   2.2.9
   2.1.17
   Status: Resolved  (was: Patch Available)

Alright, committed as eb0f443705425bac93f92a5e7e04ea5def77b1d8 to 2.1 and 
merged up to trunk.

> Upgrade netty to 4.0.44 to fix memory leak with client encryption
> -
>
> Key: CASSANDRA-13114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13114
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van der Woerdt
>Assignee: Stefan Podkowinski
>Priority: Blocker
> Fix For: 2.1.17, 2.2.9, 3.0.11, 3.11.0, 4.0
>
> Attachments: 13114_netty-4.0.44_2.x-3.0.patch, 
> 13114_netty-4.0.44_3.11.patch
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-12032 updated netty for 
> Cassandra 3.8, but this wasn't backported. Netty 4.0.23, which ships with 
> Cassandra 3.0.x, has some serious bugs around memory handling for SSL 
> connections.
> It would be nice if both were updated to 4.0.42, a version released this year.
> 4.0.23 makes it impossible for me to run SSL, because nodes run out of memory 
> every ~30 minutes. This was fixed in 4.0.27.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[5/5] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

2017-02-09 Thread snazy
Merge branch 'cassandra-3.11' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0811824a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0811824a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0811824a

Branch: refs/heads/trunk
Commit: 0811824abbf46182005c5c54cee7b08243f2057a
Parents: 4550734 6d5cd2d
Author: Robert Stupp 
Authored: Thu Feb 9 21:13:14 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 21:13:14 2017 +0100

--
 CHANGES.txt |   2 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.39.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.39.Final.jar  | Bin 2271610 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |   6 +-
 7 files changed, 209 insertions(+), 205 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0811824a/CHANGES.txt
--
diff --cc CHANGES.txt
index 2217659,3073fd7..38f1209
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -44,6 -13,6 +44,8 @@@ Merged from 3.0
 live rows in sstabledump (CASSANDRA-13177)
   * Provide user workaround when system_schema.columns does not contain entries
 for a table that's in system_schema.tables (CASSANDRA-13180)
++Merged from 2.1:
++ * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
  
  
  3.10

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0811824a/build.xml
--



[2/5] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

2017-02-09 Thread snazy
Merge branch 'cassandra-2.1' into cassandra-2.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f0f9cf23
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f0f9cf23
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f0f9cf23

Branch: refs/heads/trunk
Commit: f0f9cf232bf51107c855062c8b5b0196d0e90246
Parents: 2593809 eb0f443
Author: Robert Stupp 
Authored: Thu Feb 9 20:37:32 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 20:37:32 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.23.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.23.Final.jar  | Bin 1779991 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |  12 +-
 7 files changed, 212 insertions(+), 207 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0f9cf23/CHANGES.txt
--
diff --cc CHANGES.txt
index 086e0e5,0c7d129..c8419ab
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,33 -1,5 +1,34 @@@
 -2.1.17
 +2.2.9
 + * Fix speculative retry bugs (CASSANDRA-13009)
 + * Fix handling of nulls and unsets in IN conditions (CASSANDRA-12981) 
 + * Remove support for non-JavaScript UDFs (CASSANDRA-12883)
 + * Fix DynamicEndpointSnitch noop in multi-datacenter situations 
(CASSANDRA-13074)
 + * cqlsh copy-from: encode column names to avoid primary key parsing errors 
(CASSANDRA-12909)
 + * Temporarily fix bug that creates commit log when running offline tools 
(CASSANDRA-8616)
 + * Reduce granuality of OpOrder.Group during index build (CASSANDRA-12796)
 + * Test bind parameters and unset parameters in InsertUpdateIfConditionTest 
(CASSANDRA-12980)
 + * Do not specify local address on outgoing connection when 
listen_on_broadcast_address is set (CASSANDRA-12673)
 + * Use saved tokens when setting local tokens on StorageService.joinRing 
(CASSANDRA-12935)
 + * cqlsh: fix DESC TYPES errors (CASSANDRA-12914)
 + * Fix leak on skipped SSTables in sstableupgrade (CASSANDRA-12899)
 + * Avoid blocking gossip during pending range calculation (CASSANDRA-12281)
 + * Fix purgeability of tombstones with max timestamp (CASSANDRA-12792)
 + * Fail repair if participant dies during sync or anticompaction 
(CASSANDRA-12901)
 + * cqlsh COPY: unprotected pk values before converting them if not using 
prepared statements (CASSANDRA-12863)
 + * Fix Util.spinAssertEquals (CASSANDRA-12283)
 + * Fix potential NPE for compactionstats (CASSANDRA-12462)
 + * Prepare legacy authenticate statement if credentials table initialised 
after node startup (CASSANDRA-12813)
 + * Change cassandra.wait_for_tracing_events_timeout_secs default to 0 
(CASSANDRA-12754)
 + * Clean up permissions when a UDA is dropped (CASSANDRA-12720)
 + * Limit colUpdateTimeDelta histogram updates to reasonable deltas 
(CASSANDRA-7)
 + * Fix leak errors and execution rejected exceptions when draining 
(CASSANDRA-12457)
 + * Fix merkle tree depth calculation (CASSANDRA-12580)
 + * Make Collections deserialization more robust (CASSANDRA-12618)
 + * Better handle invalid system roles table (CASSANDRA-12700)
 + * Split consistent range movement flag correction (CASSANDRA-12786)
 + * CompactionTasks now correctly drops sstables out of compaction when not 
enough disk space is available (CASSANDRA-12979)
 +Merged from 2.1:
+  * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
   * Fix paging for DISTINCT queries on partition keys and static columns 
(CASSANDRA-13017)
   * Fix race causing infinite loop if Thrift server is stopped before it 
starts listening (CASSANDRA-12856)
   * cqlsh copy-from: sort user type fields in csv (CASSANDRA-12959)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0f9cf23/build.xml
--
diff --cc build.xml
index d9f8198,91dc34b..94e4723
--- a/build.xml
+++ b/build.xml
@@@ -402,26 -400,16 +402,26 @@@
  


 -  
 -  
 +  
 +  
 +  


-   
+   


 -  
 +  
 +  
 +  

  
 +  
 +  
 +  
 +  
 +  
  
  
  

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0f9cf23/src/java/org/apache/cassandra/transport/Message.java
--



[3/5] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

2017-02-09 Thread snazy
Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a696ab33
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a696ab33
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a696ab33

Branch: refs/heads/trunk
Commit: a696ab33ba17672efa125ae137458c1abcf9c116
Parents: 74fdfe0 f0f9cf2
Author: Robert Stupp 
Authored: Thu Feb 9 20:38:17 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 20:38:17 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.23.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.23.Final.jar  | Bin 1779991 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |  12 +-
 7 files changed, 212 insertions(+), 207 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a696ab33/CHANGES.txt
--
diff --cc CHANGES.txt
index 1f638da,c8419ab..d8c1625
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -49,47 -12,6 +49,48 @@@ Merged from 2.2
   * cqlsh: fix DESC TYPES errors (CASSANDRA-12914)
   * Fix leak on skipped SSTables in sstableupgrade (CASSANDRA-12899)
   * Avoid blocking gossip during pending range calculation (CASSANDRA-12281)
 +Merged from 2.1:
++ * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
 + * cqlsh copy-from: sort user type fields in csv (CASSANDRA-12959)
 +
 +
 +
 +3.0.10
 + * Disallow offheap_buffers memtable allocation (CASSANDRA-11039)
 + * Fix CommitLogSegmentManagerTest (CASSANDRA-12283)
 + * Pass root cause to CorruptBlockException when uncompression failed 
(CASSANDRA-12889)
 + * Fix partition count log during compaction (CASSANDRA-12184)
 + * Batch with multiple conditional updates for the same partition causes 
AssertionError (CASSANDRA-12867)
 + * Make AbstractReplicationStrategy extendable from outside its package 
(CASSANDRA-12788)
 + * Fix CommitLogTest.testDeleteIfNotDirty (CASSANDRA-12854)
 + * Don't tell users to turn off consistent rangemovements during rebuild. 
(CASSANDRA-12296)
 + * Avoid deadlock due to materialized view lock contention (CASSANDRA-12689)
 + * Fix for KeyCacheCqlTest flakiness (CASSANDRA-12801)
 + * Include SSTable filename in compacting large row message (CASSANDRA-12384)
 + * Fix potential socket leak (CASSANDRA-12329, CASSANDRA-12330)
 + * Fix ViewTest.testCompaction (CASSANDRA-12789)
 + * Improve avg aggregate functions (CASSANDRA-12417)
 + * Preserve quoted reserved keyword column names in MV creation 
(CASSANDRA-11803)
 + * nodetool stopdaemon errors out (CASSANDRA-12646)
 + * Split materialized view mutations on build to prevent OOM (CASSANDRA-12268)
 + * mx4j does not work in 3.0.8 (CASSANDRA-12274)
 + * Abort cqlsh copy-from in case of no answer after prolonged period of time 
(CASSANDRA-12740)
 + * Avoid sstable corrupt exception due to dropped static column 
(CASSANDRA-12582)
 + * Make stress use client mode to avoid checking commit log size on startup 
(CASSANDRA-12478)
 + * Fix exceptions with new vnode allocation (CASSANDRA-12715)
 + * Unify drain and shutdown processes (CASSANDRA-12509)
 + * Fix NPE in ComponentOfSlice.isEQ() (CASSANDRA-12706)
 + * Fix failure in LogTransactionTest (CASSANDRA-12632)
 + * Fix potentially incomplete non-frozen UDT values when querying with the
 +   full primary key specified (CASSANDRA-12605)
 + * Skip writing MV mutations to commitlog on mutation.applyUnsafe() 
(CASSANDRA-11670)
 + * Establish consistent distinction between non-existing partition and NULL 
value for LWTs on static columns (CASSANDRA-12060)
 + * Extend ColumnIdentifier.internedInstances key to include the type that 
generated the byte buffer (CASSANDRA-12516)
 + * Backport CASSANDRA-10756 (race condition in NativeTransportService 
shutdown) (CASSANDRA-12472)
 + * If CF has no clustering columns, any row cache is full partition cache 
(CASSANDRA-12499)
 + * Correct log message for statistics of offheap memtable flush 
(CASSANDRA-12776)
 + * Explicitly set locale for string validation 
(CASSANDRA-12541,CASSANDRA-12542,CASSANDRA-12543,CASSANDRA-12545)
 +Merged from 2.2:
   * Fix purgeability of tombstones with max timestamp (CASSANDRA-12792)
   * Fail repair if participant dies during sync or anticompaction 
(CASSANDRA-12901)
   * cqlsh COPY: unprotected pk values before converting them if not using 
prepared statements (CASSANDRA-12863)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a696ab33/build.xml

[1/5] cassandra git commit: Upgrade netty to 4.0.44 to fix memory leak with client encryption

2017-02-09 Thread snazy
Repository: cassandra
Updated Branches:
  refs/heads/trunk 4550734c2 -> 0811824ab


Upgrade netty to 4.0.44 to fix memory leak with client encryption

patch by Stefan Podkowinski; reviewed by Robert Stupp for CASSANDRA-13114


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/eb0f4437
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/eb0f4437
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/eb0f4437

Branch: refs/heads/trunk
Commit: eb0f443705425bac93f92a5e7e04ea5def77b1d8
Parents: 70e8b39
Author: Stefan Podkowinski 
Authored: Thu Feb 9 20:35:39 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 20:36:07 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.23.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.23.Final.jar  | Bin 1779991 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |  12 +-
 7 files changed, 212 insertions(+), 207 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 414d6ed..0c7d129 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.17
+ * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
  * Fix paging for DISTINCT queries on partition keys and static columns 
(CASSANDRA-13017)
  * Fix race causing infinite loop if Thrift server is stopped before it starts 
listening (CASSANDRA-12856)
  * cqlsh copy-from: sort user type fields in csv (CASSANDRA-12959)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/build.xml
--
diff --git a/build.xml b/build.xml
index f949aec..91dc34b 100644
--- a/build.xml
+++ b/build.xml
@@ -404,7 +404,7 @@
   
   
   
-  
+  
   
   
   

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/lib/licenses/netty-all-4.0.23.Final.txt
--
diff --git a/lib/licenses/netty-all-4.0.23.Final.txt 
b/lib/licenses/netty-all-4.0.23.Final.txt
deleted file mode 100644
index d645695..000
--- a/lib/licenses/netty-all-4.0.23.Final.txt
+++ /dev/null
@@ -1,202 +0,0 @@
-
- Apache License
-   Version 2.0, January 2004
-http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-  "License" shall mean the terms and conditions for use, reproduction,
-  and distribution as defined by Sections 1 through 9 of this document.
-
-  "Licensor" shall mean the copyright owner or entity authorized by
-  the copyright owner that is granting the License.
-
-  "Legal Entity" shall mean the union of the acting entity and all
-  other entities that control, are controlled by, or are under common
-  control with that entity. For the purposes of this definition,
-  "control" means (i) the power, direct or indirect, to cause the
-  direction or management of such entity, whether by contract or
-  otherwise, or (ii) ownership of fifty percent (50%) or more of the
-  outstanding shares, or (iii) beneficial ownership of such entity.
-
-  "You" (or "Your") shall mean an individual or Legal Entity
-  exercising permissions granted by this License.
-
-  "Source" form shall mean the preferred form for making modifications,
-  including but not limited to software source code, documentation
-  source, and configuration files.
-
-  "Object" form shall mean any form resulting from mechanical
-  transformation or translation of a Source form, including but
-  not limited to compiled object code, generated documentation,
-  and conversions to other media types.
-
-  "Work" shall mean the work of authorship, whether in Source or
-  Object form, made available under the License, as indicated by a
-  copyright notice that is included in or attached to the work
-  (an example is provided in the Appendix below).
-
-  "Derivative Works" shall mean any work, whether in Source or Object
-  form, that is based on (or derived from) the Work and for which the
-  editorial revisions, annotations, elaborations, or other modifications
-  represent, as a whole, an original work of authorship. For 

[4/5] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

2017-02-09 Thread snazy
Merge branch 'cassandra-3.0' into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6d5cd2d4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6d5cd2d4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6d5cd2d4

Branch: refs/heads/trunk
Commit: 6d5cd2d459940f37dd1bb629b37add33d8f7272f
Parents: 6a504f4 a696ab3
Author: Robert Stupp 
Authored: Thu Feb 9 20:50:41 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 20:50:41 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.39.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.39.Final.jar  | Bin 2271610 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |   6 +-
 7 files changed, 208 insertions(+), 205 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6d5cd2d4/CHANGES.txt
--
diff --cc CHANGES.txt
index eb10bad,d8c1625..3073fd7
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -235,13 -107,10 +235,14 @@@ Merged from 2.2
   * Fix exceptions when enabling gossip on nodes that haven't joined the ring 
(CASSANDRA-12253)
   * Fix authentication problem when invoking cqlsh copy from a SOURCE command 
(CASSANDRA-12642)
   * Decrement pending range calculator jobs counter in finally block
 -  (CASSANDRA-12554)
 + * cqlshlib tests: increase default execute timeout (CASSANDRA-12481)
 + * Forward writes to replacement node when replace_address != 
broadcast_address (CASSANDRA-8523)
 + * Fail repair on non-existing table (CASSANDRA-12279)
 + * Enable repair -pr and -local together (fix regression of CASSANDRA-7450) 
(CASSANDRA-12522)
   * Split consistent range movement flag correction (CASSANDRA-12786)
  Merged from 2.1:
 - * Add system property to set the max number of native transport requests in 
queue (CASSANDRA-11363)
++ * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
 + * cqlsh copy-from: sort user type fields in csv (CASSANDRA-12959)
   * Don't skip sstables based on maxLocalDeletionTime (CASSANDRA-12765)
  
  

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6d5cd2d4/build.xml
--
diff --cc build.xml
index 0fdf5f3,a182f45..49dd95a
--- a/build.xml
+++ b/build.xml
@@@ -426,21 -396,16 +426,21 @@@



 -  
 +  


-   
+   


 -  
 +  
 +
 +
 +
 +
 +  

 -  
 -  
 +  
 +  




http://git-wip-us.apache.org/repos/asf/cassandra/blob/6d5cd2d4/src/java/org/apache/cassandra/transport/Message.java
--



[07/10] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

2017-02-09 Thread snazy
Merge branch 'cassandra-2.1' into cassandra-2.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f0f9cf23
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f0f9cf23
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f0f9cf23

Branch: refs/heads/cassandra-3.11
Commit: f0f9cf232bf51107c855062c8b5b0196d0e90246
Parents: 2593809 eb0f443
Author: Robert Stupp 
Authored: Thu Feb 9 20:37:32 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 20:37:32 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.23.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.23.Final.jar  | Bin 1779991 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |  12 +-
 7 files changed, 212 insertions(+), 207 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0f9cf23/CHANGES.txt
--
diff --cc CHANGES.txt
index 086e0e5,0c7d129..c8419ab
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,33 -1,5 +1,34 @@@
 -2.1.17
 +2.2.9
 + * Fix speculative retry bugs (CASSANDRA-13009)
 + * Fix handling of nulls and unsets in IN conditions (CASSANDRA-12981) 
 + * Remove support for non-JavaScript UDFs (CASSANDRA-12883)
 + * Fix DynamicEndpointSnitch noop in multi-datacenter situations 
(CASSANDRA-13074)
 + * cqlsh copy-from: encode column names to avoid primary key parsing errors 
(CASSANDRA-12909)
 + * Temporarily fix bug that creates commit log when running offline tools 
(CASSANDRA-8616)
 + * Reduce granuality of OpOrder.Group during index build (CASSANDRA-12796)
 + * Test bind parameters and unset parameters in InsertUpdateIfConditionTest 
(CASSANDRA-12980)
 + * Do not specify local address on outgoing connection when 
listen_on_broadcast_address is set (CASSANDRA-12673)
 + * Use saved tokens when setting local tokens on StorageService.joinRing 
(CASSANDRA-12935)
 + * cqlsh: fix DESC TYPES errors (CASSANDRA-12914)
 + * Fix leak on skipped SSTables in sstableupgrade (CASSANDRA-12899)
 + * Avoid blocking gossip during pending range calculation (CASSANDRA-12281)
 + * Fix purgeability of tombstones with max timestamp (CASSANDRA-12792)
 + * Fail repair if participant dies during sync or anticompaction 
(CASSANDRA-12901)
 + * cqlsh COPY: unprotected pk values before converting them if not using 
prepared statements (CASSANDRA-12863)
 + * Fix Util.spinAssertEquals (CASSANDRA-12283)
 + * Fix potential NPE for compactionstats (CASSANDRA-12462)
 + * Prepare legacy authenticate statement if credentials table initialised 
after node startup (CASSANDRA-12813)
 + * Change cassandra.wait_for_tracing_events_timeout_secs default to 0 
(CASSANDRA-12754)
 + * Clean up permissions when a UDA is dropped (CASSANDRA-12720)
 + * Limit colUpdateTimeDelta histogram updates to reasonable deltas 
(CASSANDRA-7)
 + * Fix leak errors and execution rejected exceptions when draining 
(CASSANDRA-12457)
 + * Fix merkle tree depth calculation (CASSANDRA-12580)
 + * Make Collections deserialization more robust (CASSANDRA-12618)
 + * Better handle invalid system roles table (CASSANDRA-12700)
 + * Split consistent range movement flag correction (CASSANDRA-12786)
 + * CompactionTasks now correctly drops sstables out of compaction when not 
enough disk space is available (CASSANDRA-12979)
 +Merged from 2.1:
+  * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
   * Fix paging for DISTINCT queries on partition keys and static columns 
(CASSANDRA-13017)
   * Fix race causing infinite loop if Thrift server is stopped before it 
starts listening (CASSANDRA-12856)
   * cqlsh copy-from: sort user type fields in csv (CASSANDRA-12959)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0f9cf23/build.xml
--
diff --cc build.xml
index d9f8198,91dc34b..94e4723
--- a/build.xml
+++ b/build.xml
@@@ -402,26 -400,16 +402,26 @@@
  


 -  
 -  
 +  
 +  
 +  


-   
+   


 -  
 +  
 +  
 +  

  
 +  
 +  
 +  
 +  
 +  
  
  
  

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0f9cf23/src/java/org/apache/cassandra/transport/Message.java
--



[03/10] cassandra git commit: Upgrade netty to 4.0.44 to fix memory leak with client encryption

2017-02-09 Thread snazy
Upgrade netty to 4.0.44 to fix memory leak with client encryption

patch by Stefan Podkowinski; reviewed by Robert Stupp for CASSANDRA-13114


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/eb0f4437
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/eb0f4437
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/eb0f4437

Branch: refs/heads/cassandra-3.0
Commit: eb0f443705425bac93f92a5e7e04ea5def77b1d8
Parents: 70e8b39
Author: Stefan Podkowinski 
Authored: Thu Feb 9 20:35:39 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 20:36:07 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.23.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.23.Final.jar  | Bin 1779991 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |  12 +-
 7 files changed, 212 insertions(+), 207 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 414d6ed..0c7d129 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.17
+ * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
  * Fix paging for DISTINCT queries on partition keys and static columns 
(CASSANDRA-13017)
  * Fix race causing infinite loop if Thrift server is stopped before it starts 
listening (CASSANDRA-12856)
  * cqlsh copy-from: sort user type fields in csv (CASSANDRA-12959)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/build.xml
--
diff --git a/build.xml b/build.xml
index f949aec..91dc34b 100644
--- a/build.xml
+++ b/build.xml
@@ -404,7 +404,7 @@
   
   
   
-  
+  
   
   
   

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/lib/licenses/netty-all-4.0.23.Final.txt
--
diff --git a/lib/licenses/netty-all-4.0.23.Final.txt 
b/lib/licenses/netty-all-4.0.23.Final.txt
deleted file mode 100644
index d645695..000
--- a/lib/licenses/netty-all-4.0.23.Final.txt
+++ /dev/null
@@ -1,202 +0,0 @@
-
- Apache License
-   Version 2.0, January 2004
-http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-  "License" shall mean the terms and conditions for use, reproduction,
-  and distribution as defined by Sections 1 through 9 of this document.
-
-  "Licensor" shall mean the copyright owner or entity authorized by
-  the copyright owner that is granting the License.
-
-  "Legal Entity" shall mean the union of the acting entity and all
-  other entities that control, are controlled by, or are under common
-  control with that entity. For the purposes of this definition,
-  "control" means (i) the power, direct or indirect, to cause the
-  direction or management of such entity, whether by contract or
-  otherwise, or (ii) ownership of fifty percent (50%) or more of the
-  outstanding shares, or (iii) beneficial ownership of such entity.
-
-  "You" (or "Your") shall mean an individual or Legal Entity
-  exercising permissions granted by this License.
-
-  "Source" form shall mean the preferred form for making modifications,
-  including but not limited to software source code, documentation
-  source, and configuration files.
-
-  "Object" form shall mean any form resulting from mechanical
-  transformation or translation of a Source form, including but
-  not limited to compiled object code, generated documentation,
-  and conversions to other media types.
-
-  "Work" shall mean the work of authorship, whether in Source or
-  Object form, made available under the License, as indicated by a
-  copyright notice that is included in or attached to the work
-  (an example is provided in the Appendix below).
-
-  "Derivative Works" shall mean any work, whether in Source or Object
-  form, that is based on (or derived from) the Work and for which the
-  editorial revisions, annotations, elaborations, or other modifications
-  represent, as a whole, an original work of authorship. For the purposes
-  of this License, Derivative Works shall not include works 

[08/10] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

2017-02-09 Thread snazy
Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a696ab33
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a696ab33
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a696ab33

Branch: refs/heads/cassandra-3.0
Commit: a696ab33ba17672efa125ae137458c1abcf9c116
Parents: 74fdfe0 f0f9cf2
Author: Robert Stupp 
Authored: Thu Feb 9 20:38:17 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 20:38:17 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.23.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.23.Final.jar  | Bin 1779991 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |  12 +-
 7 files changed, 212 insertions(+), 207 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a696ab33/CHANGES.txt
--
diff --cc CHANGES.txt
index 1f638da,c8419ab..d8c1625
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -49,47 -12,6 +49,48 @@@ Merged from 2.2
   * cqlsh: fix DESC TYPES errors (CASSANDRA-12914)
   * Fix leak on skipped SSTables in sstableupgrade (CASSANDRA-12899)
   * Avoid blocking gossip during pending range calculation (CASSANDRA-12281)
 +Merged from 2.1:
++ * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
 + * cqlsh copy-from: sort user type fields in csv (CASSANDRA-12959)
 +
 +
 +
 +3.0.10
 + * Disallow offheap_buffers memtable allocation (CASSANDRA-11039)
 + * Fix CommitLogSegmentManagerTest (CASSANDRA-12283)
 + * Pass root cause to CorruptBlockException when uncompression failed 
(CASSANDRA-12889)
 + * Fix partition count log during compaction (CASSANDRA-12184)
 + * Batch with multiple conditional updates for the same partition causes 
AssertionError (CASSANDRA-12867)
 + * Make AbstractReplicationStrategy extendable from outside its package 
(CASSANDRA-12788)
 + * Fix CommitLogTest.testDeleteIfNotDirty (CASSANDRA-12854)
 + * Don't tell users to turn off consistent rangemovements during rebuild. 
(CASSANDRA-12296)
 + * Avoid deadlock due to materialized view lock contention (CASSANDRA-12689)
 + * Fix for KeyCacheCqlTest flakiness (CASSANDRA-12801)
 + * Include SSTable filename in compacting large row message (CASSANDRA-12384)
 + * Fix potential socket leak (CASSANDRA-12329, CASSANDRA-12330)
 + * Fix ViewTest.testCompaction (CASSANDRA-12789)
 + * Improve avg aggregate functions (CASSANDRA-12417)
 + * Preserve quoted reserved keyword column names in MV creation 
(CASSANDRA-11803)
 + * nodetool stopdaemon errors out (CASSANDRA-12646)
 + * Split materialized view mutations on build to prevent OOM (CASSANDRA-12268)
 + * mx4j does not work in 3.0.8 (CASSANDRA-12274)
 + * Abort cqlsh copy-from in case of no answer after prolonged period of time 
(CASSANDRA-12740)
 + * Avoid sstable corrupt exception due to dropped static column 
(CASSANDRA-12582)
 + * Make stress use client mode to avoid checking commit log size on startup 
(CASSANDRA-12478)
 + * Fix exceptions with new vnode allocation (CASSANDRA-12715)
 + * Unify drain and shutdown processes (CASSANDRA-12509)
 + * Fix NPE in ComponentOfSlice.isEQ() (CASSANDRA-12706)
 + * Fix failure in LogTransactionTest (CASSANDRA-12632)
 + * Fix potentially incomplete non-frozen UDT values when querying with the
 +   full primary key specified (CASSANDRA-12605)
 + * Skip writing MV mutations to commitlog on mutation.applyUnsafe() 
(CASSANDRA-11670)
 + * Establish consistent distinction between non-existing partition and NULL 
value for LWTs on static columns (CASSANDRA-12060)
 + * Extend ColumnIdentifier.internedInstances key to include the type that 
generated the byte buffer (CASSANDRA-12516)
 + * Backport CASSANDRA-10756 (race condition in NativeTransportService 
shutdown) (CASSANDRA-12472)
 + * If CF has no clustering columns, any row cache is full partition cache 
(CASSANDRA-12499)
 + * Correct log message for statistics of offheap memtable flush 
(CASSANDRA-12776)
 + * Explicitly set locale for string validation 
(CASSANDRA-12541,CASSANDRA-12542,CASSANDRA-12543,CASSANDRA-12545)
 +Merged from 2.2:
   * Fix purgeability of tombstones with max timestamp (CASSANDRA-12792)
   * Fail repair if participant dies during sync or anticompaction 
(CASSANDRA-12901)
   * cqlsh COPY: unprotected pk values before converting them if not using 
prepared statements (CASSANDRA-12863)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a696ab33/build.xml

[06/10] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

2017-02-09 Thread snazy
Merge branch 'cassandra-2.1' into cassandra-2.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f0f9cf23
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f0f9cf23
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f0f9cf23

Branch: refs/heads/cassandra-2.2
Commit: f0f9cf232bf51107c855062c8b5b0196d0e90246
Parents: 2593809 eb0f443
Author: Robert Stupp 
Authored: Thu Feb 9 20:37:32 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 20:37:32 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.23.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.23.Final.jar  | Bin 1779991 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |  12 +-
 7 files changed, 212 insertions(+), 207 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0f9cf23/CHANGES.txt
--
diff --cc CHANGES.txt
index 086e0e5,0c7d129..c8419ab
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,33 -1,5 +1,34 @@@
 -2.1.17
 +2.2.9
 + * Fix speculative retry bugs (CASSANDRA-13009)
 + * Fix handling of nulls and unsets in IN conditions (CASSANDRA-12981) 
 + * Remove support for non-JavaScript UDFs (CASSANDRA-12883)
 + * Fix DynamicEndpointSnitch noop in multi-datacenter situations 
(CASSANDRA-13074)
 + * cqlsh copy-from: encode column names to avoid primary key parsing errors 
(CASSANDRA-12909)
 + * Temporarily fix bug that creates commit log when running offline tools 
(CASSANDRA-8616)
 + * Reduce granuality of OpOrder.Group during index build (CASSANDRA-12796)
 + * Test bind parameters and unset parameters in InsertUpdateIfConditionTest 
(CASSANDRA-12980)
 + * Do not specify local address on outgoing connection when 
listen_on_broadcast_address is set (CASSANDRA-12673)
 + * Use saved tokens when setting local tokens on StorageService.joinRing 
(CASSANDRA-12935)
 + * cqlsh: fix DESC TYPES errors (CASSANDRA-12914)
 + * Fix leak on skipped SSTables in sstableupgrade (CASSANDRA-12899)
 + * Avoid blocking gossip during pending range calculation (CASSANDRA-12281)
 + * Fix purgeability of tombstones with max timestamp (CASSANDRA-12792)
 + * Fail repair if participant dies during sync or anticompaction 
(CASSANDRA-12901)
 + * cqlsh COPY: unprotected pk values before converting them if not using 
prepared statements (CASSANDRA-12863)
 + * Fix Util.spinAssertEquals (CASSANDRA-12283)
 + * Fix potential NPE for compactionstats (CASSANDRA-12462)
 + * Prepare legacy authenticate statement if credentials table initialised 
after node startup (CASSANDRA-12813)
 + * Change cassandra.wait_for_tracing_events_timeout_secs default to 0 
(CASSANDRA-12754)
 + * Clean up permissions when a UDA is dropped (CASSANDRA-12720)
 + * Limit colUpdateTimeDelta histogram updates to reasonable deltas 
(CASSANDRA-7)
 + * Fix leak errors and execution rejected exceptions when draining 
(CASSANDRA-12457)
 + * Fix merkle tree depth calculation (CASSANDRA-12580)
 + * Make Collections deserialization more robust (CASSANDRA-12618)
 + * Better handle invalid system roles table (CASSANDRA-12700)
 + * Split consistent range movement flag correction (CASSANDRA-12786)
 + * CompactionTasks now correctly drops sstables out of compaction when not 
enough disk space is available (CASSANDRA-12979)
 +Merged from 2.1:
+  * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
   * Fix paging for DISTINCT queries on partition keys and static columns 
(CASSANDRA-13017)
   * Fix race causing infinite loop if Thrift server is stopped before it 
starts listening (CASSANDRA-12856)
   * cqlsh copy-from: sort user type fields in csv (CASSANDRA-12959)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0f9cf23/build.xml
--
diff --cc build.xml
index d9f8198,91dc34b..94e4723
--- a/build.xml
+++ b/build.xml
@@@ -402,26 -400,16 +402,26 @@@
  


 -  
 -  
 +  
 +  
 +  


-   
+   


 -  
 +  
 +  
 +  

  
 +  
 +  
 +  
 +  
 +  
  
  
  

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0f9cf23/src/java/org/apache/cassandra/transport/Message.java
--



[01/10] cassandra git commit: Upgrade netty to 4.0.44 to fix memory leak with client encryption

2017-02-09 Thread snazy
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 70e8b39b0 -> eb0f44370
  refs/heads/cassandra-2.2 25938090a -> f0f9cf232
  refs/heads/cassandra-3.0 74fdfe0a5 -> a696ab33b
  refs/heads/cassandra-3.11 6a504f403 -> 6d5cd2d45


Upgrade netty to 4.0.44 to fix memory leak with client encryption

patch by Stefan Podkowinski; reviewed by Robert Stupp for CASSANDRA-13114


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/eb0f4437
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/eb0f4437
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/eb0f4437

Branch: refs/heads/cassandra-2.1
Commit: eb0f443705425bac93f92a5e7e04ea5def77b1d8
Parents: 70e8b39
Author: Stefan Podkowinski 
Authored: Thu Feb 9 20:35:39 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 20:36:07 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.23.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.23.Final.jar  | Bin 1779991 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |  12 +-
 7 files changed, 212 insertions(+), 207 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 414d6ed..0c7d129 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.17
+ * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
  * Fix paging for DISTINCT queries on partition keys and static columns 
(CASSANDRA-13017)
  * Fix race causing infinite loop if Thrift server is stopped before it starts 
listening (CASSANDRA-12856)
  * cqlsh copy-from: sort user type fields in csv (CASSANDRA-12959)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/build.xml
--
diff --git a/build.xml b/build.xml
index f949aec..91dc34b 100644
--- a/build.xml
+++ b/build.xml
@@ -404,7 +404,7 @@
   
   
   
-  
+  
   
   
   

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/lib/licenses/netty-all-4.0.23.Final.txt
--
diff --git a/lib/licenses/netty-all-4.0.23.Final.txt 
b/lib/licenses/netty-all-4.0.23.Final.txt
deleted file mode 100644
index d645695..000
--- a/lib/licenses/netty-all-4.0.23.Final.txt
+++ /dev/null
@@ -1,202 +0,0 @@
-
- Apache License
-   Version 2.0, January 2004
-http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-  "License" shall mean the terms and conditions for use, reproduction,
-  and distribution as defined by Sections 1 through 9 of this document.
-
-  "Licensor" shall mean the copyright owner or entity authorized by
-  the copyright owner that is granting the License.
-
-  "Legal Entity" shall mean the union of the acting entity and all
-  other entities that control, are controlled by, or are under common
-  control with that entity. For the purposes of this definition,
-  "control" means (i) the power, direct or indirect, to cause the
-  direction or management of such entity, whether by contract or
-  otherwise, or (ii) ownership of fifty percent (50%) or more of the
-  outstanding shares, or (iii) beneficial ownership of such entity.
-
-  "You" (or "Your") shall mean an individual or Legal Entity
-  exercising permissions granted by this License.
-
-  "Source" form shall mean the preferred form for making modifications,
-  including but not limited to software source code, documentation
-  source, and configuration files.
-
-  "Object" form shall mean any form resulting from mechanical
-  transformation or translation of a Source form, including but
-  not limited to compiled object code, generated documentation,
-  and conversions to other media types.
-
-  "Work" shall mean the work of authorship, whether in Source or
-  Object form, made available under the License, as indicated by a
-  copyright notice that is included in or attached to the work
-  (an example is provided in the Appendix below).
-
-  "Derivative Works" shall mean any work, whether in Source or Object
-  form, that is based on (or derived from) the 

[02/10] cassandra git commit: Upgrade netty to 4.0.44 to fix memory leak with client encryption

2017-02-09 Thread snazy
Upgrade netty to 4.0.44 to fix memory leak with client encryption

patch by Stefan Podkowinski; reviewed by Robert Stupp for CASSANDRA-13114


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/eb0f4437
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/eb0f4437
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/eb0f4437

Branch: refs/heads/cassandra-2.2
Commit: eb0f443705425bac93f92a5e7e04ea5def77b1d8
Parents: 70e8b39
Author: Stefan Podkowinski 
Authored: Thu Feb 9 20:35:39 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 20:36:07 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.23.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.23.Final.jar  | Bin 1779991 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |  12 +-
 7 files changed, 212 insertions(+), 207 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 414d6ed..0c7d129 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.17
+ * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
  * Fix paging for DISTINCT queries on partition keys and static columns 
(CASSANDRA-13017)
  * Fix race causing infinite loop if Thrift server is stopped before it starts 
listening (CASSANDRA-12856)
  * cqlsh copy-from: sort user type fields in csv (CASSANDRA-12959)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/build.xml
--
diff --git a/build.xml b/build.xml
index f949aec..91dc34b 100644
--- a/build.xml
+++ b/build.xml
@@ -404,7 +404,7 @@
   
   
   
-  
+  
   
   
   

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/lib/licenses/netty-all-4.0.23.Final.txt
--
diff --git a/lib/licenses/netty-all-4.0.23.Final.txt 
b/lib/licenses/netty-all-4.0.23.Final.txt
deleted file mode 100644
index d645695..000
--- a/lib/licenses/netty-all-4.0.23.Final.txt
+++ /dev/null
@@ -1,202 +0,0 @@
-
- Apache License
-   Version 2.0, January 2004
-http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-  "License" shall mean the terms and conditions for use, reproduction,
-  and distribution as defined by Sections 1 through 9 of this document.
-
-  "Licensor" shall mean the copyright owner or entity authorized by
-  the copyright owner that is granting the License.
-
-  "Legal Entity" shall mean the union of the acting entity and all
-  other entities that control, are controlled by, or are under common
-  control with that entity. For the purposes of this definition,
-  "control" means (i) the power, direct or indirect, to cause the
-  direction or management of such entity, whether by contract or
-  otherwise, or (ii) ownership of fifty percent (50%) or more of the
-  outstanding shares, or (iii) beneficial ownership of such entity.
-
-  "You" (or "Your") shall mean an individual or Legal Entity
-  exercising permissions granted by this License.
-
-  "Source" form shall mean the preferred form for making modifications,
-  including but not limited to software source code, documentation
-  source, and configuration files.
-
-  "Object" form shall mean any form resulting from mechanical
-  transformation or translation of a Source form, including but
-  not limited to compiled object code, generated documentation,
-  and conversions to other media types.
-
-  "Work" shall mean the work of authorship, whether in Source or
-  Object form, made available under the License, as indicated by a
-  copyright notice that is included in or attached to the work
-  (an example is provided in the Appendix below).
-
-  "Derivative Works" shall mean any work, whether in Source or Object
-  form, that is based on (or derived from) the Work and for which the
-  editorial revisions, annotations, elaborations, or other modifications
-  represent, as a whole, an original work of authorship. For the purposes
-  of this License, Derivative Works shall not include works 

[05/10] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

2017-02-09 Thread snazy
Merge branch 'cassandra-2.1' into cassandra-2.2


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f0f9cf23
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f0f9cf23
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f0f9cf23

Branch: refs/heads/cassandra-3.0
Commit: f0f9cf232bf51107c855062c8b5b0196d0e90246
Parents: 2593809 eb0f443
Author: Robert Stupp 
Authored: Thu Feb 9 20:37:32 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 20:37:32 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.23.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.23.Final.jar  | Bin 1779991 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |  12 +-
 7 files changed, 212 insertions(+), 207 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0f9cf23/CHANGES.txt
--
diff --cc CHANGES.txt
index 086e0e5,0c7d129..c8419ab
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,33 -1,5 +1,34 @@@
 -2.1.17
 +2.2.9
 + * Fix speculative retry bugs (CASSANDRA-13009)
 + * Fix handling of nulls and unsets in IN conditions (CASSANDRA-12981) 
 + * Remove support for non-JavaScript UDFs (CASSANDRA-12883)
 + * Fix DynamicEndpointSnitch noop in multi-datacenter situations 
(CASSANDRA-13074)
 + * cqlsh copy-from: encode column names to avoid primary key parsing errors 
(CASSANDRA-12909)
 + * Temporarily fix bug that creates commit log when running offline tools 
(CASSANDRA-8616)
 + * Reduce granuality of OpOrder.Group during index build (CASSANDRA-12796)
 + * Test bind parameters and unset parameters in InsertUpdateIfConditionTest 
(CASSANDRA-12980)
 + * Do not specify local address on outgoing connection when 
listen_on_broadcast_address is set (CASSANDRA-12673)
 + * Use saved tokens when setting local tokens on StorageService.joinRing 
(CASSANDRA-12935)
 + * cqlsh: fix DESC TYPES errors (CASSANDRA-12914)
 + * Fix leak on skipped SSTables in sstableupgrade (CASSANDRA-12899)
 + * Avoid blocking gossip during pending range calculation (CASSANDRA-12281)
 + * Fix purgeability of tombstones with max timestamp (CASSANDRA-12792)
 + * Fail repair if participant dies during sync or anticompaction 
(CASSANDRA-12901)
 + * cqlsh COPY: unprotected pk values before converting them if not using 
prepared statements (CASSANDRA-12863)
 + * Fix Util.spinAssertEquals (CASSANDRA-12283)
 + * Fix potential NPE for compactionstats (CASSANDRA-12462)
 + * Prepare legacy authenticate statement if credentials table initialised 
after node startup (CASSANDRA-12813)
 + * Change cassandra.wait_for_tracing_events_timeout_secs default to 0 
(CASSANDRA-12754)
 + * Clean up permissions when a UDA is dropped (CASSANDRA-12720)
 + * Limit colUpdateTimeDelta histogram updates to reasonable deltas 
(CASSANDRA-7)
 + * Fix leak errors and execution rejected exceptions when draining 
(CASSANDRA-12457)
 + * Fix merkle tree depth calculation (CASSANDRA-12580)
 + * Make Collections deserialization more robust (CASSANDRA-12618)
 + * Better handle invalid system roles table (CASSANDRA-12700)
 + * Split consistent range movement flag correction (CASSANDRA-12786)
 + * CompactionTasks now correctly drops sstables out of compaction when not 
enough disk space is available (CASSANDRA-12979)
 +Merged from 2.1:
+  * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
   * Fix paging for DISTINCT queries on partition keys and static columns 
(CASSANDRA-13017)
   * Fix race causing infinite loop if Thrift server is stopped before it 
starts listening (CASSANDRA-12856)
   * cqlsh copy-from: sort user type fields in csv (CASSANDRA-12959)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0f9cf23/build.xml
--
diff --cc build.xml
index d9f8198,91dc34b..94e4723
--- a/build.xml
+++ b/build.xml
@@@ -402,26 -400,16 +402,26 @@@
  


 -  
 -  
 +  
 +  
 +  


-   
+   


 -  
 +  
 +  
 +  

  
 +  
 +  
 +  
 +  
 +  
  
  
  

http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0f9cf23/src/java/org/apache/cassandra/transport/Message.java
--



[09/10] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

2017-02-09 Thread snazy
Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a696ab33
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a696ab33
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a696ab33

Branch: refs/heads/cassandra-3.11
Commit: a696ab33ba17672efa125ae137458c1abcf9c116
Parents: 74fdfe0 f0f9cf2
Author: Robert Stupp 
Authored: Thu Feb 9 20:38:17 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 20:38:17 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.23.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.23.Final.jar  | Bin 1779991 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |  12 +-
 7 files changed, 212 insertions(+), 207 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/a696ab33/CHANGES.txt
--
diff --cc CHANGES.txt
index 1f638da,c8419ab..d8c1625
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -49,47 -12,6 +49,48 @@@ Merged from 2.2
   * cqlsh: fix DESC TYPES errors (CASSANDRA-12914)
   * Fix leak on skipped SSTables in sstableupgrade (CASSANDRA-12899)
   * Avoid blocking gossip during pending range calculation (CASSANDRA-12281)
 +Merged from 2.1:
++ * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
 + * cqlsh copy-from: sort user type fields in csv (CASSANDRA-12959)
 +
 +
 +
 +3.0.10
 + * Disallow offheap_buffers memtable allocation (CASSANDRA-11039)
 + * Fix CommitLogSegmentManagerTest (CASSANDRA-12283)
 + * Pass root cause to CorruptBlockException when uncompression failed 
(CASSANDRA-12889)
 + * Fix partition count log during compaction (CASSANDRA-12184)
 + * Batch with multiple conditional updates for the same partition causes 
AssertionError (CASSANDRA-12867)
 + * Make AbstractReplicationStrategy extendable from outside its package 
(CASSANDRA-12788)
 + * Fix CommitLogTest.testDeleteIfNotDirty (CASSANDRA-12854)
 + * Don't tell users to turn off consistent rangemovements during rebuild. 
(CASSANDRA-12296)
 + * Avoid deadlock due to materialized view lock contention (CASSANDRA-12689)
 + * Fix for KeyCacheCqlTest flakiness (CASSANDRA-12801)
 + * Include SSTable filename in compacting large row message (CASSANDRA-12384)
 + * Fix potential socket leak (CASSANDRA-12329, CASSANDRA-12330)
 + * Fix ViewTest.testCompaction (CASSANDRA-12789)
 + * Improve avg aggregate functions (CASSANDRA-12417)
 + * Preserve quoted reserved keyword column names in MV creation 
(CASSANDRA-11803)
 + * nodetool stopdaemon errors out (CASSANDRA-12646)
 + * Split materialized view mutations on build to prevent OOM (CASSANDRA-12268)
 + * mx4j does not work in 3.0.8 (CASSANDRA-12274)
 + * Abort cqlsh copy-from in case of no answer after prolonged period of time 
(CASSANDRA-12740)
 + * Avoid sstable corrupt exception due to dropped static column 
(CASSANDRA-12582)
 + * Make stress use client mode to avoid checking commit log size on startup 
(CASSANDRA-12478)
 + * Fix exceptions with new vnode allocation (CASSANDRA-12715)
 + * Unify drain and shutdown processes (CASSANDRA-12509)
 + * Fix NPE in ComponentOfSlice.isEQ() (CASSANDRA-12706)
 + * Fix failure in LogTransactionTest (CASSANDRA-12632)
 + * Fix potentially incomplete non-frozen UDT values when querying with the
 +   full primary key specified (CASSANDRA-12605)
 + * Skip writing MV mutations to commitlog on mutation.applyUnsafe() 
(CASSANDRA-11670)
 + * Establish consistent distinction between non-existing partition and NULL 
value for LWTs on static columns (CASSANDRA-12060)
 + * Extend ColumnIdentifier.internedInstances key to include the type that 
generated the byte buffer (CASSANDRA-12516)
 + * Backport CASSANDRA-10756 (race condition in NativeTransportService 
shutdown) (CASSANDRA-12472)
 + * If CF has no clustering columns, any row cache is full partition cache 
(CASSANDRA-12499)
 + * Correct log message for statistics of offheap memtable flush 
(CASSANDRA-12776)
 + * Explicitly set locale for string validation 
(CASSANDRA-12541,CASSANDRA-12542,CASSANDRA-12543,CASSANDRA-12545)
 +Merged from 2.2:
   * Fix purgeability of tombstones with max timestamp (CASSANDRA-12792)
   * Fail repair if participant dies during sync or anticompaction 
(CASSANDRA-12901)
   * cqlsh COPY: unprotected pk values before converting them if not using 
prepared statements (CASSANDRA-12863)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/a696ab33/build.xml

[10/10] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

2017-02-09 Thread snazy
Merge branch 'cassandra-3.0' into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6d5cd2d4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6d5cd2d4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6d5cd2d4

Branch: refs/heads/cassandra-3.11
Commit: 6d5cd2d459940f37dd1bb629b37add33d8f7272f
Parents: 6a504f4 a696ab3
Author: Robert Stupp 
Authored: Thu Feb 9 20:50:41 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 20:50:41 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.39.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.39.Final.jar  | Bin 2271610 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |   6 +-
 7 files changed, 208 insertions(+), 205 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6d5cd2d4/CHANGES.txt
--
diff --cc CHANGES.txt
index eb10bad,d8c1625..3073fd7
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -235,13 -107,10 +235,14 @@@ Merged from 2.2
   * Fix exceptions when enabling gossip on nodes that haven't joined the ring 
(CASSANDRA-12253)
   * Fix authentication problem when invoking cqlsh copy from a SOURCE command 
(CASSANDRA-12642)
   * Decrement pending range calculator jobs counter in finally block
 -  (CASSANDRA-12554)
 + * cqlshlib tests: increase default execute timeout (CASSANDRA-12481)
 + * Forward writes to replacement node when replace_address != 
broadcast_address (CASSANDRA-8523)
 + * Fail repair on non-existing table (CASSANDRA-12279)
 + * Enable repair -pr and -local together (fix regression of CASSANDRA-7450) 
(CASSANDRA-12522)
   * Split consistent range movement flag correction (CASSANDRA-12786)
  Merged from 2.1:
 - * Add system property to set the max number of native transport requests in 
queue (CASSANDRA-11363)
++ * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
 + * cqlsh copy-from: sort user type fields in csv (CASSANDRA-12959)
   * Don't skip sstables based on maxLocalDeletionTime (CASSANDRA-12765)
  
  

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6d5cd2d4/build.xml
--
diff --cc build.xml
index 0fdf5f3,a182f45..49dd95a
--- a/build.xml
+++ b/build.xml
@@@ -426,21 -396,16 +426,21 @@@



 -  
 +  


-   
+   


 -  
 +  
 +
 +
 +
 +
 +  

 -  
 -  
 +  
 +  




http://git-wip-us.apache.org/repos/asf/cassandra/blob/6d5cd2d4/src/java/org/apache/cassandra/transport/Message.java
--



[04/10] cassandra git commit: Upgrade netty to 4.0.44 to fix memory leak with client encryption

2017-02-09 Thread snazy
Upgrade netty to 4.0.44 to fix memory leak with client encryption

patch by Stefan Podkowinski; reviewed by Robert Stupp for CASSANDRA-13114


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/eb0f4437
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/eb0f4437
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/eb0f4437

Branch: refs/heads/cassandra-3.11
Commit: eb0f443705425bac93f92a5e7e04ea5def77b1d8
Parents: 70e8b39
Author: Stefan Podkowinski 
Authored: Thu Feb 9 20:35:39 2017 +0100
Committer: Robert Stupp 
Committed: Thu Feb 9 20:36:07 2017 +0100

--
 CHANGES.txt |   1 +
 build.xml   |   2 +-
 lib/licenses/netty-all-4.0.23.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.44.Final.txt | 202 +++
 lib/netty-all-4.0.23.Final.jar  | Bin 1779991 -> 0 bytes
 lib/netty-all-4.0.44.Final.jar  | Bin 0 -> 2342652 bytes
 .../org/apache/cassandra/transport/Message.java |  12 +-
 7 files changed, 212 insertions(+), 207 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 414d6ed..0c7d129 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.17
+ * Upgrade netty version to fix memory leak with client encryption 
(CASSANDRA-13114)
  * Fix paging for DISTINCT queries on partition keys and static columns 
(CASSANDRA-13017)
  * Fix race causing infinite loop if Thrift server is stopped before it starts 
listening (CASSANDRA-12856)
  * cqlsh copy-from: sort user type fields in csv (CASSANDRA-12959)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/build.xml
--
diff --git a/build.xml b/build.xml
index f949aec..91dc34b 100644
--- a/build.xml
+++ b/build.xml
@@ -404,7 +404,7 @@
   
   
   
-  
+  
   
   
   

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eb0f4437/lib/licenses/netty-all-4.0.23.Final.txt
--
diff --git a/lib/licenses/netty-all-4.0.23.Final.txt 
b/lib/licenses/netty-all-4.0.23.Final.txt
deleted file mode 100644
index d645695..000
--- a/lib/licenses/netty-all-4.0.23.Final.txt
+++ /dev/null
@@ -1,202 +0,0 @@
-
- Apache License
-   Version 2.0, January 2004
-http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-  "License" shall mean the terms and conditions for use, reproduction,
-  and distribution as defined by Sections 1 through 9 of this document.
-
-  "Licensor" shall mean the copyright owner or entity authorized by
-  the copyright owner that is granting the License.
-
-  "Legal Entity" shall mean the union of the acting entity and all
-  other entities that control, are controlled by, or are under common
-  control with that entity. For the purposes of this definition,
-  "control" means (i) the power, direct or indirect, to cause the
-  direction or management of such entity, whether by contract or
-  otherwise, or (ii) ownership of fifty percent (50%) or more of the
-  outstanding shares, or (iii) beneficial ownership of such entity.
-
-  "You" (or "Your") shall mean an individual or Legal Entity
-  exercising permissions granted by this License.
-
-  "Source" form shall mean the preferred form for making modifications,
-  including but not limited to software source code, documentation
-  source, and configuration files.
-
-  "Object" form shall mean any form resulting from mechanical
-  transformation or translation of a Source form, including but
-  not limited to compiled object code, generated documentation,
-  and conversions to other media types.
-
-  "Work" shall mean the work of authorship, whether in Source or
-  Object form, made available under the License, as indicated by a
-  copyright notice that is included in or attached to the work
-  (an example is provided in the Appendix below).
-
-  "Derivative Works" shall mean any work, whether in Source or Object
-  form, that is based on (or derived from) the Work and for which the
-  editorial revisions, annotations, elaborations, or other modifications
-  represent, as a whole, an original work of authorship. For the purposes
-  of this License, Derivative Works shall not include 

[jira] [Commented] (CASSANDRA-9639) size_estimates is inacurate in multi-dc clusters

2017-02-09 Thread Paulo Motta (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860082#comment-15860082
 ] 

Paulo Motta commented on CASSANDRA-9639:


LGTM, thanks! We should also take the chance here to avoid merging overlapping 
ranges (which was introduced on 
[CASSANDRA-9462|https://issues.apache.org/jira/browse/CASSANDRA-9462?focusedCommentId=14611854=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14611854]),
 since this will require the client to manually split the ranges to be able to 
directly run repair on ranges from the {{size_estimates}} table. For instance, 
a node with ranges (-2688160409776496397, -2506475074448728501) and 
(-2506475074448728501, 8473270337963525440) will currently be inserted into 
{{system.size_estimates}} as (-2688160409776496397, 8473270337963525440), due 
to the merging of neighbor ranges.

[~cnlwsu] can you have a look on [this 
commit|https://github.com/pauloricardomg/cassandra/commit/e26e1513812c3f2df2ea375585a575730bbb949e]?
 It basically avoids normalizing ranges, but instead just unwrap wrap-around 
ranges, which was the original idea behind CASSANDRA-9462.

I also added a regression 
[dtest|https://github.com/riptano/cassandra-dtest/pull/1439] to make sure this 
is working as expected.

Updated patch and tests available below:
||3.0||dtest||
|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:3.0-9639]|[branch|https://github.com/riptano/cassandra-dtest/compare/master...pauloricardomg:9639]|
|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-9639-testall/lastCompletedBuild/testReport/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-9639-dtest/lastCompletedBuild/testReport/]|


> size_estimates is inacurate in multi-dc clusters
> 
>
> Key: CASSANDRA-9639
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9639
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sebastian Estevez
>Assignee: Chris Lohfink
>Priority: Minor
> Fix For: 3.0.x
>
>
> CASSANDRA-7688 introduced size_estimates to replace the thrift 
> describe_splits_ex command.
> Users have reported seeing estimates that are widely off in multi-dc clusters.
> system.size_estimates show the wrong range_start / range_end



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13038) 33% of compaction time spent in StreamingHistogram.update()

2017-02-09 Thread Jeff Jirsa (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860080#comment-15860080
 ] 

Jeff Jirsa commented on CASSANDRA-13038:


Pushing my branches from yesterday here, with CI runs just starting. These have 
some extra system properties (3, in fact - one for the histogram bin size, one 
for the spool size, and one for the rounding) - I'll push a change in a moment 
to remove the system properties to minimize config bloat. 

|| Branch || Unit Tests || DTest ||
|[3.0|https://github.com/jeffjirsa/cassandra/tree/cassandra-3.0-13038] | 
http://cassci.datastax.com/job/jeffjirsa-cassandra-3.0-13038-testall/ | 
http://cassci.datastax.com/job/jeffjirsa-cassandra-3.0-13038-dtest/ | 
|[3.11|https://github.com/jeffjirsa/cassandra/tree/cassandra-3.11-13038] | 
http://cassci.datastax.com/job/jeffjirsa-cassandra-3.11-13038-testall/ | 
http://cassci.datastax.com/job/jeffjirsa-cassandra-3.11-13038-dtest/ | 
|[trunk|https://github.com/jeffjirsa/cassandra/tree/cassandra-13038] | 
http://cassci.datastax.com/job/jeffjirsa-cassandra-13038-testall/ | 
http://cassci.datastax.com/job/jeffjirsa-cassandra-13205-13038/ |  


> 33% of compaction time spent in StreamingHistogram.update()
> ---
>
> Key: CASSANDRA-13038
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13038
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Corentin Chary
>Assignee: Jeff Jirsa
> Attachments: compaction-speedup.patch, 
> compaction-streaminghistrogram.png, profiler-snapshot.nps
>
>
> With the following table, that contains a *lot* of cells: 
> {code}
> CREATE TABLE biggraphite.datapoints_11520p_60s (
> metric uuid,
> time_start_ms bigint,
> offset smallint,
> count int,
> value double,
> PRIMARY KEY ((metric, time_start_ms), offset)
> ) WITH CLUSTERING ORDER BY (offset DESC);
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy', 
> 'compaction_window_size': '6', 'compaction_window_unit': 'HOURS', 
> 'max_threshold': '32', 'min_threshold': '6'}
> Keyspace : biggraphite
> Read Count: 1822
> Read Latency: 1.8870054884742042 ms.
> Write Count: 2212271647
> Write Latency: 0.027705127678653473 ms.
> Pending Flushes: 0
> Table: datapoints_11520p_60s
> SSTable count: 47
> Space used (live): 300417555945
> Space used (total): 303147395017
> Space used by snapshots (total): 0
> Off heap memory used (total): 207453042
> SSTable Compression Ratio: 0.4955200053039823
> Number of keys (estimate): 16343723
> Memtable cell count: 220576
> Memtable data size: 17115128
> Memtable off heap memory used: 0
> Memtable switch count: 2872
> Local read count: 0
> Local read latency: NaN ms
> Local write count: 1103167888
> Local write latency: 0.025 ms
> Pending flushes: 0
> Percent repaired: 0.0
> Bloom filter false positives: 0
> Bloom filter false ratio: 0.0
> Bloom filter space used: 105118296
> Bloom filter off heap memory used: 106547192
> Index summary off heap memory used: 27730962
> Compression metadata off heap memory used: 73174888
> Compacted partition minimum bytes: 61
> Compacted partition maximum bytes: 51012
> Compacted partition mean bytes: 7899
> Average live cells per slice (last five minutes): NaN
> Maximum live cells per slice (last five minutes): 0
> Average tombstones per slice (last five minutes): NaN
> Maximum tombstones per slice (last five minutes): 0
> Dropped Mutations: 0
> {code}
> It looks like a good chunk of the compaction time is lost in 
> StreamingHistogram.update() (which is used to store the estimated tombstone 
> drop times).
> This could be caused by a huge number of different deletion times which would 
> makes the bin huge but it this histogram should be capped to 100 keys. It's 
> more likely caused by the huge number of cells.
> A simple solutions could be to only take into accounts part of the cells, the 
> fact the this table has a TWCS also gives us an additional hint that sampling 
> deletion times would be fine.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13114) Upgrade netty to 4.0.44 to fix memory leak with client encryption

2017-02-09 Thread Robert Stupp (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-13114:
-
Summary: Upgrade netty to 4.0.44 to fix memory leak with client encryption  
(was: 3.0.x: update netty)

> Upgrade netty to 4.0.44 to fix memory leak with client encryption
> -
>
> Key: CASSANDRA-13114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13114
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van der Woerdt
>Assignee: Stefan Podkowinski
>Priority: Blocker
> Fix For: 3.0.11
>
> Attachments: 13114_netty-4.0.44_2.x-3.0.patch, 
> 13114_netty-4.0.44_3.11.patch
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-12032 updated netty for 
> Cassandra 3.8, but this wasn't backported. Netty 4.0.23, which ships with 
> Cassandra 3.0.x, has some serious bugs around memory handling for SSL 
> connections.
> It would be nice if both were updated to 4.0.42, a version released this year.
> 4.0.23 makes it impossible for me to run SSL, because nodes run out of memory 
> every ~30 minutes. This was fixed in 4.0.27.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13114) 3.0.x: update netty

2017-02-09 Thread Stefan Podkowinski (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860044#comment-15860044
 ] 

Stefan Podkowinski commented on CASSANDRA-13114:


I don't think this is critical enough for 2.1, as you have to have large enough 
direct allocations through netty that will exhaust the memory between regular 
CMS runs. So you don't necessarily have to run into this problem and there's an 
easy workaround by not enabling disableexplicitgc (as described in 
CASSANDRA-13126) or by simply replacing the netty jar with a new version. 
But 2.2 and 3.0 - why not? Both are supported and it should be possible to do a 
library updated there.

> 3.0.x: update netty
> ---
>
> Key: CASSANDRA-13114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13114
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van der Woerdt
>Assignee: Stefan Podkowinski
>Priority: Blocker
> Fix For: 3.0.11
>
> Attachments: 13114_netty-4.0.44_2.x-3.0.patch, 
> 13114_netty-4.0.44_3.11.patch
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-12032 updated netty for 
> Cassandra 3.8, but this wasn't backported. Netty 4.0.23, which ships with 
> Cassandra 3.0.x, has some serious bugs around memory handling for SSL 
> connections.
> It would be nice if both were updated to 4.0.42, a version released this year.
> 4.0.23 makes it impossible for me to run SSL, because nodes run out of memory 
> every ~30 minutes. This was fixed in 4.0.27.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-12928) Assert error, 3.9 mutation stage

2017-02-09 Thread Jeff Jirsa (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-12928:
---
Resolution: Later
Status: Resolved  (was: Patch Available)

Officially closing as "Later", because the resolution is the same, but to be 
clear: this is NOT the same bug, even though it's the same resolution.


> Assert error, 3.9 mutation stage
> 
>
> Key: CASSANDRA-12928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12928
> Project: Cassandra
>  Issue Type: Bug
> Environment: 3.9 
>Reporter: Jeff Jirsa
> Attachments: 0001-Bump-version-of-netty-all-to-4.1.6.patch
>
>
> {code}
> WARN  [MutationStage-341] 2016-11-17 18:39:18,781 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[MutationStage-341,5,main]: {}
> java.lang.AssertionError: null
>   at 
> io.netty.util.Recycler$WeakOrderQueue.(Recycler.java:225) 
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> io.netty.util.Recycler$DefaultHandle.recycle(Recycler.java:180) 
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at io.netty.util.Recycler.recycle(Recycler.java:141) 
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> org.apache.cassandra.utils.btree.BTree$Builder.recycle(BTree.java:836) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.utils.btree.BTree$Builder.build(BTree.java:1089) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate.build(PartitionUpdate.java:587)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate.maybeBuild(PartitionUpdate.java:577)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate.holder(PartitionUpdate.java:388)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:177)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:172)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serializedSize(PartitionUpdate.java:868)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Mutation$MutationSerializer.serializedSize(Mutation.java:456)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:257) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:227) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:241) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1347)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2539)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_91]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13205) Hint related logging should include the IP address of the destination in addition to host ID

2017-02-09 Thread sankalp kohli (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

sankalp kohli updated CASSANDRA-13205:
--
Reviewer: Blake Eggleston

> Hint related logging should include the IP address of the destination in 
> addition to host ID
> 
>
> Key: CASSANDRA-13205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13205
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Trivial
> Fix For: 3.0.x
>
>
> After the hint rewrite in 3.0, many of the hint related logs now use hostId 
> UUIDs rather than endpoint addresses. This complicates debugging 
> unnecessarily. We should include both.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13204) Thread Leak in OutboundTcpConnection

2017-02-09 Thread Ariel Weisberg (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ariel Weisberg updated CASSANDRA-13204:
---
Reviewer: Ariel Weisberg

> Thread Leak in OutboundTcpConnection
> 
>
> Key: CASSANDRA-13204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13204
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jason Brown
> Fix For: 3.0.11, 2.1.x, 2.2.x, 3.11.x
>
>
> We found threads leaking from OutboundTcpConnection to machines which are not 
> part of the cluster and still in Gossip for some reason. There are two issues 
> here, this JIRA will cover the second one which is most important. 
> 1) First issue is that Gossip has information about machines not in the ring 
> which has been replaced out. It causes Cassandra to connect to those machines 
> but due to internode auth, it wont be able to connect to them at the socket 
> level.  
> 2) Second issue is a race between creating a connection and closing a 
> connections which is triggered by the gossip bug explained above. Let me try 
> to explain it using the code
> In OutboundTcpConnection, we are calling closeSocket(true) which will set 
> isStopped=true and also put a close sentinel into the queue to exit the 
> thread. On the ack connection, Gossip tries to send a message which calls 
> connect() which will block for 10 seconds which is RPC timeout. The reason we 
> will block is because Cassandra might not be running there or internode auth 
> will not let it connect. During this 10 seconds, if Gossip calls closeSocket, 
> it will put close sentinel into the queue. When we return from the connect 
> method after 10 seconds, we will clear the backlog queue causing this thread 
> to leak. 
> Proofs from the heap dump of the affected machine which is leaking threads 
> 1. Only ack connection is leaking and not the command connection which is not 
> used by Gossip. 
> 2. We see thread blocked on the backlog queue, isStopped=true and backlog 
> queue is empty. This is happening on the threads which have already leaked. 
> 3. A running thread was blocked on the connect waiting for timeout(10 
> seconds) and we see backlog queue to contain the close sentinel. Once the 
> connect will return false, we will clear the backlog and this thread will 
> have leaked.  
> Interesting bits from j stack 
> 1282 number of threads for "MessagingService-Outgoing-/"
> Thread which is about to leak:
> "MessagingService-Outgoing-/" 
>java.lang.Thread.State: RUNNABLE
>   at sun.nio.ch.Net.connect0(Native Method)
>   at sun.nio.ch.Net.connect(Net.java:454)
>   at sun.nio.ch.Net.connect(Net.java:446)
>   at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:137)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:119)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.connect(OutboundTcpConnection.java:381)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:217)
> Thread already leaked:
> "MessagingService-Outgoing-/"
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$DisabledCoalescingStrategy.coalesceInternal(CoalescingStrategies.java:482)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$CoalescingStrategy.coalesce(CoalescingStrategies.java:213)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:190)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-12928) Assert error, 3.9 mutation stage

2017-02-09 Thread Corentin Chary (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860034#comment-15860034
 ] 

Corentin Chary commented on CASSANDRA-12928:


LGTM

> Assert error, 3.9 mutation stage
> 
>
> Key: CASSANDRA-12928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12928
> Project: Cassandra
>  Issue Type: Bug
> Environment: 3.9 
>Reporter: Jeff Jirsa
> Attachments: 0001-Bump-version-of-netty-all-to-4.1.6.patch
>
>
> {code}
> WARN  [MutationStage-341] 2016-11-17 18:39:18,781 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[MutationStage-341,5,main]: {}
> java.lang.AssertionError: null
>   at 
> io.netty.util.Recycler$WeakOrderQueue.(Recycler.java:225) 
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> io.netty.util.Recycler$DefaultHandle.recycle(Recycler.java:180) 
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at io.netty.util.Recycler.recycle(Recycler.java:141) 
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> org.apache.cassandra.utils.btree.BTree$Builder.recycle(BTree.java:836) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.utils.btree.BTree$Builder.build(BTree.java:1089) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate.build(PartitionUpdate.java:587)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate.maybeBuild(PartitionUpdate.java:577)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate.holder(PartitionUpdate.java:388)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:177)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:172)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serializedSize(PartitionUpdate.java:868)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Mutation$MutationSerializer.serializedSize(Mutation.java:456)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:257) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:227) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:241) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1347)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2539)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_91]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13205) Hint related logging should include the IP address of the destination in addition to host ID

2017-02-09 Thread Jeff Jirsa (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Jirsa updated CASSANDRA-13205:
---
Status: Patch Available  (was: Open)

> Hint related logging should include the IP address of the destination in 
> addition to host ID
> 
>
> Key: CASSANDRA-13205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13205
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Trivial
> Fix For: 3.0.x
>
>
> After the hint rewrite in 3.0, many of the hint related logs now use hostId 
> UUIDs rather than endpoint addresses. This complicates debugging 
> unnecessarily. We should include both.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13205) Hint related logging should include the IP address of the destination in addition to host ID

2017-02-09 Thread Jeff Jirsa (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860013#comment-15860013
 ] 

Jeff Jirsa commented on CASSANDRA-13205:


|| Branch || Unit Tests || DTest ||
|[3.0|https://github.com/jeffjirsa/cassandra/tree/cassandra-3.0-13205] | 
http://cassci.datastax.com/job/jeffjirsa-cassandra-3.0-13205-testall/ | 
http://cassci.datastax.com/job/jeffjirsa-cassandra-3.0-13205-dtest/ | 
|[3.11|https://github.com/jeffjirsa/cassandra/tree/cassandra-3.11-13205] | 
http://cassci.datastax.com/job/jeffjirsa-cassandra-3.11-13205-testall/ | 
http://cassci.datastax.com/job/jeffjirsa-cassandra-3.11-13205-dtest/ | 
|[trunk|https://github.com/jeffjirsa/cassandra/tree/cassandra-13205] | 
http://cassci.datastax.com/job/jeffjirsa-cassandra-13205-testall/ | 
http://cassci.datastax.com/job/jeffjirsa-cassandra-13205-dtest/ |  


> Hint related logging should include the IP address of the destination in 
> addition to host ID
> 
>
> Key: CASSANDRA-13205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13205
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Trivial
> Fix For: 3.0.x
>
>
> After the hint rewrite in 3.0, many of the hint related logs now use hostId 
> UUIDs rather than endpoint addresses. This complicates debugging 
> unnecessarily. We should include both.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13114) 3.0.x: update netty

2017-02-09 Thread Robert Stupp (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859998#comment-15859998
 ] 

Robert Stupp commented on CASSANDRA-13114:
--

Patch LGTM - however, is this going into 3.0...trunk or 2.1...trunk? Fix 
version (and summary) say 3.0, but there are patches for 2.1 and 2.2, too.

> 3.0.x: update netty
> ---
>
> Key: CASSANDRA-13114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13114
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van der Woerdt
>Assignee: Stefan Podkowinski
>Priority: Blocker
> Fix For: 3.0.11
>
> Attachments: 13114_netty-4.0.44_2.x-3.0.patch, 
> 13114_netty-4.0.44_3.11.patch
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-12032 updated netty for 
> Cassandra 3.8, but this wasn't backported. Netty 4.0.23, which ships with 
> Cassandra 3.0.x, has some serious bugs around memory handling for SSL 
> connections.
> It would be nice if both were updated to 4.0.42, a version released this year.
> 4.0.23 makes it impossible for me to run SSL, because nodes run out of memory 
> every ~30 minutes. This was fixed in 4.0.27.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (CASSANDRA-12928) Assert error, 3.9 mutation stage

2017-02-09 Thread Jeff Jirsa (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860001#comment-15860001
 ] 

Jeff Jirsa edited comment on CASSANDRA-12928 at 2/9/17 7:00 PM:


We're going to be bumping netty in CASSANDRA-13114 (for an unrelated, but 
similarly serious bug) - let's call this a dupe of that one, and we'll pick up 
the appropriately newer version of netty there? 



was (Author: jjirsa):
We're going to be bumping 3.0.x in CASSANDRA-13114 - let's call this a dupe of 
that one, and we'll pick up the appropriately newer version of netty there? 


> Assert error, 3.9 mutation stage
> 
>
> Key: CASSANDRA-12928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12928
> Project: Cassandra
>  Issue Type: Bug
> Environment: 3.9 
>Reporter: Jeff Jirsa
> Attachments: 0001-Bump-version-of-netty-all-to-4.1.6.patch
>
>
> {code}
> WARN  [MutationStage-341] 2016-11-17 18:39:18,781 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[MutationStage-341,5,main]: {}
> java.lang.AssertionError: null
>   at 
> io.netty.util.Recycler$WeakOrderQueue.(Recycler.java:225) 
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> io.netty.util.Recycler$DefaultHandle.recycle(Recycler.java:180) 
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at io.netty.util.Recycler.recycle(Recycler.java:141) 
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> org.apache.cassandra.utils.btree.BTree$Builder.recycle(BTree.java:836) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.utils.btree.BTree$Builder.build(BTree.java:1089) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate.build(PartitionUpdate.java:587)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate.maybeBuild(PartitionUpdate.java:577)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate.holder(PartitionUpdate.java:388)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:177)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:172)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serializedSize(PartitionUpdate.java:868)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Mutation$MutationSerializer.serializedSize(Mutation.java:456)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:257) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:227) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:241) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1347)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2539)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_91]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-12928) Assert error, 3.9 mutation stage

2017-02-09 Thread Jeff Jirsa (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15860001#comment-15860001
 ] 

Jeff Jirsa commented on CASSANDRA-12928:


We're going to be bumping 3.0.x in CASSANDRA-13114 - let's call this a dupe of 
that one, and we'll pick up the appropriately newer version of netty there? 


> Assert error, 3.9 mutation stage
> 
>
> Key: CASSANDRA-12928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12928
> Project: Cassandra
>  Issue Type: Bug
> Environment: 3.9 
>Reporter: Jeff Jirsa
> Attachments: 0001-Bump-version-of-netty-all-to-4.1.6.patch
>
>
> {code}
> WARN  [MutationStage-341] 2016-11-17 18:39:18,781 
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread 
> Thread[MutationStage-341,5,main]: {}
> java.lang.AssertionError: null
>   at 
> io.netty.util.Recycler$WeakOrderQueue.(Recycler.java:225) 
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> io.netty.util.Recycler$DefaultHandle.recycle(Recycler.java:180) 
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at io.netty.util.Recycler.recycle(Recycler.java:141) 
> ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
>   at 
> org.apache.cassandra.utils.btree.BTree$Builder.recycle(BTree.java:836) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.utils.btree.BTree$Builder.build(BTree.java:1089) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate.build(PartitionUpdate.java:587)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate.maybeBuild(PartitionUpdate.java:577)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate.holder(PartitionUpdate.java:388)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:177)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:172)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.serializedSize(PartitionUpdate.java:868)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Mutation$MutationSerializer.serializedSize(Mutation.java:456)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.add(CommitLog.java:257) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:493) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:215) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:227) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at org.apache.cassandra.db.Mutation.apply(Mutation.java:241) 
> ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$8.runMayThrow(StorageProxy.java:1347)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2539)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_91]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [apache-cassandra-3.9.jar:3.9]
>   at 
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.9.jar:3.9]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13159) Coalescing strategy can enter infinite loop

2017-02-09 Thread Michael Shuler (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Shuler updated CASSANDRA-13159:
---
Fix Version/s: 3.11.x
   2.2.x
   2.1.x
   3.0.11

> Coalescing strategy can enter infinite loop
> ---
>
> Key: CASSANDRA-13159
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13159
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 3.0.11, 2.1.x, 2.2.x, 3.11.x
>
>
> {code}boolean maybeSleep(int messages, long averageGap, long 
> maxCoalesceWindow, Parker parker){code} 
> maybeSleep() can enter an infinite loop if messages or averageGap ends up 
> being 0 because sleep will be 0 and the while loop will never exit. I've 
> noticed that on one of my clusters twice this week.
> This can happen if in averageGap() sum is bigger than MEASURED_INTERVAL, 
> which should be pretty rare but apparently happen to me.
> Even if the diagnostic is wrong (and I'm pretty sure that this thread was 
> using 100% CPU doing nothing), the fix seems pretty safe to apply.
> {code}
> diff --git a/src/java/org/apache/cassandra/utils/CoalescingStrategies.java 
> b/src/java/org/apache/cassandra/utils/CoalescingStrategies.java
> index 0aa980f..982d4a6 100644
> --- a/src/java/org/apache/cassandra/utils/CoalescingStrategies.java
> +++ b/src/java/org/apache/cassandra/utils/CoalescingStrategies.java
> @@ -100,7 +100,7 @@ public class CoalescingStrategies
>  {
>  // only sleep if we can expect to double the number of messages 
> we're sending in the time interval
>  long sleep = messages * averageGap;
> -if (sleep > maxCoalesceWindow)
> +if (!sleep || sleep > maxCoalesceWindow)
>  return false;
>  
>  // assume we receive as many messages as we expect; apply the same 
> logic to the future batch:
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13204) Thread Leak in OutboundTcpConnection

2017-02-09 Thread Michael Shuler (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Shuler updated CASSANDRA-13204:
---
Fix Version/s: 3.11.x
   2.2.x
   2.1.x
   3.0.11

> Thread Leak in OutboundTcpConnection
> 
>
> Key: CASSANDRA-13204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13204
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jason Brown
> Fix For: 3.0.11, 2.1.x, 2.2.x, 3.11.x
>
>
> We found threads leaking from OutboundTcpConnection to machines which are not 
> part of the cluster and still in Gossip for some reason. There are two issues 
> here, this JIRA will cover the second one which is most important. 
> 1) First issue is that Gossip has information about machines not in the ring 
> which has been replaced out. It causes Cassandra to connect to those machines 
> but due to internode auth, it wont be able to connect to them at the socket 
> level.  
> 2) Second issue is a race between creating a connection and closing a 
> connections which is triggered by the gossip bug explained above. Let me try 
> to explain it using the code
> In OutboundTcpConnection, we are calling closeSocket(true) which will set 
> isStopped=true and also put a close sentinel into the queue to exit the 
> thread. On the ack connection, Gossip tries to send a message which calls 
> connect() which will block for 10 seconds which is RPC timeout. The reason we 
> will block is because Cassandra might not be running there or internode auth 
> will not let it connect. During this 10 seconds, if Gossip calls closeSocket, 
> it will put close sentinel into the queue. When we return from the connect 
> method after 10 seconds, we will clear the backlog queue causing this thread 
> to leak. 
> Proofs from the heap dump of the affected machine which is leaking threads 
> 1. Only ack connection is leaking and not the command connection which is not 
> used by Gossip. 
> 2. We see thread blocked on the backlog queue, isStopped=true and backlog 
> queue is empty. This is happening on the threads which have already leaked. 
> 3. A running thread was blocked on the connect waiting for timeout(10 
> seconds) and we see backlog queue to contain the close sentinel. Once the 
> connect will return false, we will clear the backlog and this thread will 
> have leaked.  
> Interesting bits from j stack 
> 1282 number of threads for "MessagingService-Outgoing-/"
> Thread which is about to leak:
> "MessagingService-Outgoing-/" 
>java.lang.Thread.State: RUNNABLE
>   at sun.nio.ch.Net.connect0(Native Method)
>   at sun.nio.ch.Net.connect(Net.java:454)
>   at sun.nio.ch.Net.connect(Net.java:446)
>   at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:137)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:119)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.connect(OutboundTcpConnection.java:381)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:217)
> Thread already leaked:
> "MessagingService-Outgoing-/"
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$DisabledCoalescingStrategy.coalesceInternal(CoalescingStrategies.java:482)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$CoalescingStrategy.coalesce(CoalescingStrategies.java:213)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:190)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (CASSANDRA-13205) Hint related logging should include the IP address of the destination in addition to host ID

2017-02-09 Thread Jeff Jirsa (JIRA)
Jeff Jirsa created CASSANDRA-13205:
--

 Summary: Hint related logging should include the IP address of the 
destination in addition to host ID
 Key: CASSANDRA-13205
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13205
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jeff Jirsa
Assignee: Jeff Jirsa
Priority: Trivial
 Fix For: 3.0.x


After the hint rewrite in 3.0, many of the hint related logs now use hostId 
UUIDs rather than endpoint addresses. This complicates debugging unnecessarily. 
We should include both.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13090) Coalescing strategy sleeps too much

2017-02-09 Thread Corentin Chary (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859980#comment-15859980
 ] 

Corentin Chary commented on CASSANDRA-13090:


Sorry, did not build the tests for this branch apparently. Fixed. Pushed to the 
branch linked above.

FYI:
{code}
$ git diff
diff --git a/test/unit/org/apache/cassandra/utils/CoalescingStrategiesTest.java 
b/test/unit/org/apache/cassandra/utils/CoalescingStrategiesTest.java
index 26b6b3a..b10d70b 100644
--- a/test/unit/org/apache/cassandra/utils/CoalescingStrategiesTest.java
+++ b/test/unit/org/apache/cassandra/utils/CoalescingStrategiesTest.java
@@ -106,7 +106,7 @@ public class CoalescingStrategiesTest
 @BeforeClass
 public static void initDD()
 {
-DatabaseDescriptor.forceStaticInitialization();
+DatabaseDescriptor.daemonInitialization();
 }
 
 @SuppressWarnings({ "serial" })
{code}

> Coalescing strategy sleeps too much
> ---
>
> Key: CASSANDRA-13090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13090
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 3.x
>
> Attachments: 0001-Fix-wait-time-coalescing-CASSANDRA-13090-2.patch, 
> 0001-Fix-wait-time-coalescing-CASSANDRA-13090.patch
>
>
> With the current code maybeSleep is called even if we managed to take 
> maxItems out of the backlog. In this case we should really avoid sleeping 
> because it means that backlog is building up.
> I'll send a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13079) Repair doesn't work after several replication factor changes

2017-02-09 Thread Marcus Eriksson (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859959#comment-15859959
 ] 

Marcus Eriksson commented on CASSANDRA-13079:
-

The problem is that if we automatically mark all stables as unrepaired, all 
repaired sstables will potentially move to L0 in the unrepaired compaction 
strategy, this would cause a lot of compactions across the cluster and that 
would probably be even more surprising to users than the fact that they have to 
run repair -full

> Repair doesn't work after several replication factor changes
> 
>
> Key: CASSANDRA-13079
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13079
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Debian 
>Reporter: Vladimir Yudovin
>Assignee: Paulo Motta
>Priority: Critical
>
> Scenario:
> Start two nodes cluster.
> Create keyspace with rep.factor *one*:
> CREATE KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> CREATE TABLE rep.data (str text PRIMARY KEY );
> INSERT INTO rep.data (str) VALUES ( 'qwerty');
> Run *nodetool flush* on all nodes. On one of them table files are created.
> Change replication factor to *two*:
> ALTER KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 2};
> Run repair, then *nodetool flush* on all nodes. On all nodes table files are 
> created.
> Change replication factor to *one*:
> ALTER KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> Then *nodetool cleanup*, only on initial node remained data files.
> Change replication factor to *two* again:
> ALTER KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 2};
> Run repair, then *nodetool flush* on all nodes. No data files on second node 
> (though expected, as after first repair/flush).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13204) Thread Leak in OutboundTcpConnection

2017-02-09 Thread Jason Brown (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Brown updated CASSANDRA-13204:

Reproduced In: 2.1.16
Since Version: 2.1.0

> Thread Leak in OutboundTcpConnection
> 
>
> Key: CASSANDRA-13204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13204
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jason Brown
>
> We found threads leaking from OutboundTcpConnection to machines which are not 
> part of the cluster and still in Gossip for some reason. There are two issues 
> here, this JIRA will cover the second one which is most important. 
> 1) First issue is that Gossip has information about machines not in the ring 
> which has been replaced out. It causes Cassandra to connect to those machines 
> but due to internode auth, it wont be able to connect to them at the socket 
> level.  
> 2) Second issue is a race between creating a connection and closing a 
> connections which is triggered by the gossip bug explained above. Let me try 
> to explain it using the code
> In OutboundTcpConnection, we are calling closeSocket(true) which will set 
> isStopped=true and also put a close sentinel into the queue to exit the 
> thread. On the ack connection, Gossip tries to send a message which calls 
> connect() which will block for 10 seconds which is RPC timeout. The reason we 
> will block is because Cassandra might not be running there or internode auth 
> will not let it connect. During this 10 seconds, if Gossip calls closeSocket, 
> it will put close sentinel into the queue. When we return from the connect 
> method after 10 seconds, we will clear the backlog queue causing this thread 
> to leak. 
> Proofs from the heap dump of the affected machine which is leaking threads 
> 1. Only ack connection is leaking and not the command connection which is not 
> used by Gossip. 
> 2. We see thread blocked on the backlog queue, isStopped=true and backlog 
> queue is empty. This is happening on the threads which have already leaked. 
> 3. A running thread was blocked on the connect waiting for timeout(10 
> seconds) and we see backlog queue to contain the close sentinel. Once the 
> connect will return false, we will clear the backlog and this thread will 
> have leaked.  
> Interesting bits from j stack 
> 1282 number of threads for "MessagingService-Outgoing-/"
> Thread which is about to leak:
> "MessagingService-Outgoing-/" 
>java.lang.Thread.State: RUNNABLE
>   at sun.nio.ch.Net.connect0(Native Method)
>   at sun.nio.ch.Net.connect(Net.java:454)
>   at sun.nio.ch.Net.connect(Net.java:446)
>   at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:137)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:119)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.connect(OutboundTcpConnection.java:381)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:217)
> Thread already leaked:
> "MessagingService-Outgoing-/"
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$DisabledCoalescingStrategy.coalesceInternal(CoalescingStrategies.java:482)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$CoalescingStrategy.coalesce(CoalescingStrategies.java:213)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:190)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13204) Thread Leak in OutboundTcpConnection

2017-02-09 Thread Jason Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859957#comment-15859957
 ] 

Jason Brown commented on CASSANDRA-13204:
-

Looks like this is due to a regression with CASSANDRA-1632, where I naively 
clear the {{backlog}}, which had previously been the {{active}} queue. (we used 
to have two LBQs in {{OutboundTcpConnection}} in pre-2.1)

> Thread Leak in OutboundTcpConnection
> 
>
> Key: CASSANDRA-13204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13204
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jason Brown
>
> We found threads leaking from OutboundTcpConnection to machines which are not 
> part of the cluster and still in Gossip for some reason. There are two issues 
> here, this JIRA will cover the second one which is most important. 
> 1) First issue is that Gossip has information about machines not in the ring 
> which has been replaced out. It causes Cassandra to connect to those machines 
> but due to internode auth, it wont be able to connect to them at the socket 
> level.  
> 2) Second issue is a race between creating a connection and closing a 
> connections which is triggered by the gossip bug explained above. Let me try 
> to explain it using the code
> In OutboundTcpConnection, we are calling closeSocket(true) which will set 
> isStopped=true and also put a close sentinel into the queue to exit the 
> thread. On the ack connection, Gossip tries to send a message which calls 
> connect() which will block for 10 seconds which is RPC timeout. The reason we 
> will block is because Cassandra might not be running there or internode auth 
> will not let it connect. During this 10 seconds, if Gossip calls closeSocket, 
> it will put close sentinel into the queue. When we return from the connect 
> method after 10 seconds, we will clear the backlog queue causing this thread 
> to leak. 
> Proofs from the heap dump of the affected machine which is leaking threads 
> 1. Only ack connection is leaking and not the command connection which is not 
> used by Gossip. 
> 2. We see thread blocked on the backlog queue, isStopped=true and backlog 
> queue is empty. This is happening on the threads which have already leaked. 
> 3. A running thread was blocked on the connect waiting for timeout(10 
> seconds) and we see backlog queue to contain the close sentinel. Once the 
> connect will return false, we will clear the backlog and this thread will 
> have leaked.  
> Interesting bits from j stack 
> 1282 number of threads for "MessagingService-Outgoing-/"
> Thread which is about to leak:
> "MessagingService-Outgoing-/" 
>java.lang.Thread.State: RUNNABLE
>   at sun.nio.ch.Net.connect0(Native Method)
>   at sun.nio.ch.Net.connect(Net.java:454)
>   at sun.nio.ch.Net.connect(Net.java:446)
>   at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:137)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:119)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.connect(OutboundTcpConnection.java:381)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:217)
> Thread already leaked:
> "MessagingService-Outgoing-/"
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$DisabledCoalescingStrategy.coalesceInternal(CoalescingStrategies.java:482)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$CoalescingStrategy.coalesce(CoalescingStrategies.java:213)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:190)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (CASSANDRA-13204) Thread Leak in OutboundTcpConnection

2017-02-09 Thread sankalp kohli (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

sankalp kohli reassigned CASSANDRA-13204:
-

Assignee: Jason Brown

> Thread Leak in OutboundTcpConnection
> 
>
> Key: CASSANDRA-13204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13204
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jason Brown
>
> We found threads leaking from OutboundTcpConnection to machines which are not 
> part of the cluster and still in Gossip for some reason. There are two issues 
> here, this JIRA will cover the second one which is most important. 
> 1) First issue is that Gossip has information about machines not in the ring 
> which has been replaced out. It causes Cassandra to connect to those machines 
> but due to internode auth, it wont be able to connect to them at the socket 
> level.  
> 2) Second issue is a race between creating a connection and closing a 
> connections which is triggered by the gossip bug explained above. Let me try 
> to explain it using the code
> In OutboundTcpConnection, we are calling closeSocket(true) which will set 
> isStopped=true and also put a close sentinel into the queue to exit the 
> thread. On the ack connection, Gossip tries to send a message which calls 
> connect() which will block for 10 seconds which is RPC timeout. The reason we 
> will block is because Cassandra might not be running there or internode auth 
> will not let it connect. During this 10 seconds, if Gossip calls closeSocket, 
> it will put close sentinel into the queue. When we return from the connect 
> method after 10 seconds, we will clear the backlog queue causing this thread 
> to leak. 
> Proofs from the heap dump of the affected machine which is leaking threads 
> 1. Only ack connection is leaking and not the command connection which is not 
> used by Gossip. 
> 2. We see thread blocked on the backlog queue, isStopped=true and backlog 
> queue is empty. This is happening on the threads which have already leaked. 
> 3. A running thread was blocked on the connect waiting for timeout(10 
> seconds) and we see backlog queue to contain the close sentinel. Once the 
> connect will return false, we will clear the backlog and this thread will 
> have leaked.  
> Interesting bits from j stack 
> 1282 number of threads for "MessagingService-Outgoing-/"
> Thread which is about to leak:
> "MessagingService-Outgoing-/" 
>java.lang.Thread.State: RUNNABLE
>   at sun.nio.ch.Net.connect0(Native Method)
>   at sun.nio.ch.Net.connect(Net.java:454)
>   at sun.nio.ch.Net.connect(Net.java:446)
>   at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:137)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:119)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.connect(OutboundTcpConnection.java:381)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:217)
> Thread already leaked:
> "MessagingService-Outgoing-/"
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$DisabledCoalescingStrategy.coalesceInternal(CoalescingStrategies.java:482)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$CoalescingStrategy.coalesce(CoalescingStrategies.java:213)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:190)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (CASSANDRA-13204) Thread Leak in OutboundTcpConnection

2017-02-09 Thread sankalp kohli (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

sankalp kohli reassigned CASSANDRA-13204:
-

Assignee: (was: Jason Brown)

> Thread Leak in OutboundTcpConnection
> 
>
> Key: CASSANDRA-13204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13204
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>
> We found threads leaking from OutboundTcpConnection to machines which are not 
> part of the cluster and still in Gossip for some reason. There are two issues 
> here, this JIRA will cover the second one which is most important. 
> 1) First issue is that Gossip has information about machines not in the ring 
> which has been replaced out. It causes Cassandra to connect to those machines 
> but due to internode auth, it wont be able to connect to them at the socket 
> level.  
> 2) Second issue is a race between creating a connection and closing a 
> connections which is triggered by the gossip bug explained above. Let me try 
> to explain it using the code
> In OutboundTcpConnection, we are calling closeSocket(true) which will set 
> isStopped=true and also put a close sentinel into the queue to exit the 
> thread. On the ack connection, Gossip tries to send a message which calls 
> connect() which will block for 10 seconds which is RPC timeout. The reason we 
> will block is because Cassandra might not be running there or internode auth 
> will not let it connect. During this 10 seconds, if Gossip calls closeSocket, 
> it will put close sentinel into the queue. When we return from the connect 
> method after 10 seconds, we will clear the backlog queue causing this thread 
> to leak. 
> Proofs from the heap dump of the affected machine which is leaking threads 
> 1. Only ack connection is leaking and not the command connection which is not 
> used by Gossip. 
> 2. We see thread blocked on the backlog queue, isStopped=true and backlog 
> queue is empty. This is happening on the threads which have already leaked. 
> 3. A running thread was blocked on the connect waiting for timeout(10 
> seconds) and we see backlog queue to contain the close sentinel. Once the 
> connect will return false, we will clear the backlog and this thread will 
> have leaked.  
> Interesting bits from j stack 
> 1282 number of threads for "MessagingService-Outgoing-/"
> Thread which is about to leak:
> "MessagingService-Outgoing-/" 
>java.lang.Thread.State: RUNNABLE
>   at sun.nio.ch.Net.connect0(Native Method)
>   at sun.nio.ch.Net.connect(Net.java:454)
>   at sun.nio.ch.Net.connect(Net.java:446)
>   at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:137)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:119)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.connect(OutboundTcpConnection.java:381)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:217)
> Thread already leaked:
> "MessagingService-Outgoing-/"
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$DisabledCoalescingStrategy.coalesceInternal(CoalescingStrategies.java:482)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$CoalescingStrategy.coalesce(CoalescingStrategies.java:213)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:190)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (CASSANDRA-13204) Thread Leak in OutboundTcpConnection

2017-02-09 Thread sankalp kohli (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

sankalp kohli reassigned CASSANDRA-13204:
-

Assignee: Jason Brown

> Thread Leak in OutboundTcpConnection
> 
>
> Key: CASSANDRA-13204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13204
> Project: Cassandra
>  Issue Type: Bug
>Reporter: sankalp kohli
>Assignee: Jason Brown
>
> We found threads leaking from OutboundTcpConnection to machines which are not 
> part of the cluster and still in Gossip for some reason. There are two issues 
> here, this JIRA will cover the second one which is most important. 
> 1) First issue is that Gossip has information about machines not in the ring 
> which has been replaced out. It causes Cassandra to connect to those machines 
> but due to internode auth, it wont be able to connect to them at the socket 
> level.  
> 2) Second issue is a race between creating a connection and closing a 
> connections which is triggered by the gossip bug explained above. Let me try 
> to explain it using the code
> In OutboundTcpConnection, we are calling closeSocket(true) which will set 
> isStopped=true and also put a close sentinel into the queue to exit the 
> thread. On the ack connection, Gossip tries to send a message which calls 
> connect() which will block for 10 seconds which is RPC timeout. The reason we 
> will block is because Cassandra might not be running there or internode auth 
> will not let it connect. During this 10 seconds, if Gossip calls closeSocket, 
> it will put close sentinel into the queue. When we return from the connect 
> method after 10 seconds, we will clear the backlog queue causing this thread 
> to leak. 
> Proofs from the heap dump of the affected machine which is leaking threads 
> 1. Only ack connection is leaking and not the command connection which is not 
> used by Gossip. 
> 2. We see thread blocked on the backlog queue, isStopped=true and backlog 
> queue is empty. This is happening on the threads which have already leaked. 
> 3. A running thread was blocked on the connect waiting for timeout(10 
> seconds) and we see backlog queue to contain the close sentinel. Once the 
> connect will return false, we will clear the backlog and this thread will 
> have leaked.  
> Interesting bits from j stack 
> 1282 number of threads for "MessagingService-Outgoing-/"
> Thread which is about to leak:
> "MessagingService-Outgoing-/" 
>java.lang.Thread.State: RUNNABLE
>   at sun.nio.ch.Net.connect0(Native Method)
>   at sun.nio.ch.Net.connect(Net.java:454)
>   at sun.nio.ch.Net.connect(Net.java:446)
>   at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   - locked <> (a java.lang.Object)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:137)
>   at 
> org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:119)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.connect(OutboundTcpConnection.java:381)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:217)
> Thread already leaked:
> "MessagingService-Outgoing-/"
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$DisabledCoalescingStrategy.coalesceInternal(CoalescingStrategies.java:482)
>   at 
> org.apache.cassandra.utils.CoalescingStrategies$CoalescingStrategy.coalesce(CoalescingStrategies.java:213)
>   at 
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:190)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (CASSANDRA-13204) Thread Leak in OutboundTcpConnection

2017-02-09 Thread sankalp kohli (JIRA)
sankalp kohli created CASSANDRA-13204:
-

 Summary: Thread Leak in OutboundTcpConnection
 Key: CASSANDRA-13204
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13204
 Project: Cassandra
  Issue Type: Bug
Reporter: sankalp kohli


We found threads leaking from OutboundTcpConnection to machines which are not 
part of the cluster and still in Gossip for some reason. There are two issues 
here, this JIRA will cover the second one which is most important. 



1) First issue is that Gossip has information about machines not in the ring 
which has been replaced out. It causes Cassandra to connect to those machines 
but due to internode auth, it wont be able to connect to them at the socket 
level.  

2) Second issue is a race between creating a connection and closing a 
connections which is triggered by the gossip bug explained above. Let me try to 
explain it using the code

In OutboundTcpConnection, we are calling closeSocket(true) which will set 
isStopped=true and also put a close sentinel into the queue to exit the thread. 
On the ack connection, Gossip tries to send a message which calls connect() 
which will block for 10 seconds which is RPC timeout. The reason we will block 
is because Cassandra might not be running there or internode auth will not let 
it connect. During this 10 seconds, if Gossip calls closeSocket, it will put 
close sentinel into the queue. When we return from the connect method after 10 
seconds, we will clear the backlog queue causing this thread to leak. 

Proofs from the heap dump of the affected machine which is leaking threads 
1. Only ack connection is leaking and not the command connection which is not 
used by Gossip. 
2. We see thread blocked on the backlog queue, isStopped=true and backlog queue 
is empty. This is happening on the threads which have already leaked. 
3. A running thread was blocked on the connect waiting for timeout(10 seconds) 
and we see backlog queue to contain the close sentinel. Once the connect will 
return false, we will clear the backlog and this thread will have leaked.  


Interesting bits from j stack 
1282 number of threads for "MessagingService-Outgoing-/"

Thread which is about to leak:
"MessagingService-Outgoing-/" 
   java.lang.Thread.State: RUNNABLE
at sun.nio.ch.Net.connect0(Native Method)
at sun.nio.ch.Net.connect(Net.java:454)
at sun.nio.ch.Net.connect(Net.java:446)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648)
- locked <> (a java.lang.Object)
- locked <> (a java.lang.Object)
- locked <> (a java.lang.Object)
at 
org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:137)
at 
org.apache.cassandra.net.OutboundTcpConnectionPool.newSocket(OutboundTcpConnectionPool.java:119)
at 
org.apache.cassandra.net.OutboundTcpConnection.connect(OutboundTcpConnection.java:381)
at 
org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:217)

Thread already leaked:
"MessagingService-Outgoing-/"
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
org.apache.cassandra.utils.CoalescingStrategies$DisabledCoalescingStrategy.coalesceInternal(CoalescingStrategies.java:482)
at 
org.apache.cassandra.utils.CoalescingStrategies$CoalescingStrategy.coalesce(CoalescingStrategies.java:213)
at 
org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:190)




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13090) Coalescing strategy sleeps too much

2017-02-09 Thread Ariel Weisberg (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859903#comment-15859903
 ] 

Ariel Weisberg commented on CASSANDRA-13090:


The trunk version didn't build. Your branches don't do the diff stat weirdness 
which is good.
https://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-cassandra-13090-trunk-dtest/8/consoleText
{noformat}
build-test:
[javac] Compiling 502 source files to 
/home/automaton/cassandra/build/test/classes
[javac] 
/home/automaton/cassandra/test/unit/org/apache/cassandra/utils/CoalescingStrategiesTest.java:109:
 error: cannot find symbol
[javac] DatabaseDescriptor.forceStaticInitialization();
[javac]   ^
[javac]   symbol:   method forceStaticInitialization()
[javac]   location: class DatabaseDescriptor
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
/home/automaton/cassandra/build.xml:1047: Compile failed; see the compiler 
error output for details.
{noformat}

> Coalescing strategy sleeps too much
> ---
>
> Key: CASSANDRA-13090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13090
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 3.x
>
> Attachments: 0001-Fix-wait-time-coalescing-CASSANDRA-13090-2.patch, 
> 0001-Fix-wait-time-coalescing-CASSANDRA-13090.patch
>
>
> With the current code maybeSleep is called even if we managed to take 
> maxItems out of the backlog. In this case we should really avoid sleeping 
> because it means that backlog is building up.
> I'll send a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13008) Add vm.max_map_count StartupCheck

2017-02-09 Thread Stefania (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859854#comment-15859854
 ] 

Stefania commented on CASSANDRA-13008:
--

Thanks for the patch and sorry for the delay with the review. 

The patch LGTM - I've merely fixed the brackets positions and replaced 
{{FBUtilities.isWindows}} with {{FBUtilities.hasProcFS()}}.

I've started running the tests on 3.0 only:

||3.0||3.11||trunk||
|[patch|https://github.com/stef1927/cassandra/tree/13008-3.0]|[patch|https://github.com/stef1927/cassandra/tree/13008-3.11]|[patch|https://github.com/stef1927/cassandra/tree/13008]|
|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-13008-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-13008-3.11-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-13008-testall/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-13008-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-13008-3.11-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-13008-dtest/]|

The 3.0 patch applies cleanly to 3.11 and trunk.

> Add vm.max_map_count StartupCheck
> -
>
> Key: CASSANDRA-13008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13008
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
>Priority: Minor
> Fix For: 3.0.x
>
> Attachments: 13008-3.0.txt
>
>
> It's recommended to set {{vm.max_map_count}} to 1048575 (CASSANDRA-3563)
> When the max_map_count is low, it throws OOM exception, which is hard to link 
> to the real issue of vm.max_map_count.
> The problem happened when we tried to remove one node, all the other nodes in 
> cluster crashed. As each node was trying to load more local SSTable files for 
> streaming.
> I would suggest to add a StartupCheck for max_map_count, at least it could 
> give a warning message to help the debug.
> {code}
> ERROR [STREAM-IN-] JVMStabilityInspector.java:140 - JVM state determined to 
> be unstable.  Exiting forcefully due to:
> java.lang.OutOfMemoryError: Map failed
> at sun.nio.ch.FileChannelImpl.map0(Native Method) ~[na:1.8.0_112]
> at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:937) 
> ~[na:1.8.0_112]
> at org.apache.cassandra.io.util.ChannelProxy.map(ChannelProxy.java:152) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.io.util.MmappedRegions$State.add(MmappedRegions.java:280)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.io.util.MmappedRegions$State.access$400(MmappedRegions.java:216)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.io.util.MmappedRegions.updateState(MmappedRegions.java:173)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:70) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.io.util.MmappedRegions.(MmappedRegions.java:58) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.io.util.MmappedRegions.map(MmappedRegions.java:96) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.io.util.CompressedSegmentedFile.(CompressedSegmentedFile.java:47)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.io.util.CompressedSegmentedFile$Builder.complete(CompressedSegmentedFile.java:132)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.io.util.SegmentedFile$Builder.complete(SegmentedFile.java:177)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.io.util.SegmentedFile$Builder.buildData(SegmentedFile.java:193)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openFinal(BigTableWriter.java:276)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.access$600(BigTableWriter.java:50)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$TransactionalProxy.doPrepare(BigTableWriter.java:313)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:184)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.io.sstable.format.SSTableWriter.finish(SSTableWriter.java:213)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> 

[jira] [Updated] (CASSANDRA-13114) 3.0.x: update netty

2017-02-09 Thread Michael Shuler (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Shuler updated CASSANDRA-13114:
---
Priority: Blocker  (was: Major)

> 3.0.x: update netty
> ---
>
> Key: CASSANDRA-13114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13114
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van der Woerdt
>Assignee: Stefan Podkowinski
>Priority: Blocker
> Fix For: 3.0.11
>
> Attachments: 13114_netty-4.0.44_2.x-3.0.patch, 
> 13114_netty-4.0.44_3.11.patch
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-12032 updated netty for 
> Cassandra 3.8, but this wasn't backported. Netty 4.0.23, which ships with 
> Cassandra 3.0.x, has some serious bugs around memory handling for SSL 
> connections.
> It would be nice if both were updated to 4.0.42, a version released this year.
> 4.0.23 makes it impossible for me to run SSL, because nodes run out of memory 
> every ~30 minutes. This was fixed in 4.0.27.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13114) 3.0.x: update netty

2017-02-09 Thread Michael Shuler (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859746#comment-15859746
 ] 

Michael Shuler commented on CASSANDRA-13114:


I set this ticket as a blocker for 3.0.11.

Is there any additional testing required to merge this to the cassandra-3.0 
branch, so we can release 3.0.11?  Thanks!

> 3.0.x: update netty
> ---
>
> Key: CASSANDRA-13114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13114
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van der Woerdt
>Assignee: Stefan Podkowinski
>Priority: Blocker
> Fix For: 3.0.11
>
> Attachments: 13114_netty-4.0.44_2.x-3.0.patch, 
> 13114_netty-4.0.44_3.11.patch
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-12032 updated netty for 
> Cassandra 3.8, but this wasn't backported. Netty 4.0.23, which ships with 
> Cassandra 3.0.x, has some serious bugs around memory handling for SSL 
> connections.
> It would be nice if both were updated to 4.0.42, a version released this year.
> 4.0.23 makes it impossible for me to run SSL, because nodes run out of memory 
> every ~30 minutes. This was fixed in 4.0.27.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13114) 3.0.x: update netty

2017-02-09 Thread Michael Shuler (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Shuler updated CASSANDRA-13114:
---
Fix Version/s: 3.0.11

> 3.0.x: update netty
> ---
>
> Key: CASSANDRA-13114
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13114
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Tom van der Woerdt
>Assignee: Stefan Podkowinski
>Priority: Blocker
> Fix For: 3.0.11
>
> Attachments: 13114_netty-4.0.44_2.x-3.0.patch, 
> 13114_netty-4.0.44_3.11.patch
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-12032 updated netty for 
> Cassandra 3.8, but this wasn't backported. Netty 4.0.23, which ships with 
> Cassandra 3.0.x, has some serious bugs around memory handling for SSL 
> connections.
> It would be nice if both were updated to 4.0.42, a version released this year.
> 4.0.23 makes it impossible for me to run SSL, because nodes run out of memory 
> every ~30 minutes. This was fixed in 4.0.27.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (CASSANDRA-13201) dtest failure in repair_tests.repair_test.TestRepair.test_failure_during_anticompaction

2017-02-09 Thread Blake Eggleston (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Blake Eggleston reassigned CASSANDRA-13201:
---

Assignee: Blake Eggleston

> dtest failure in 
> repair_tests.repair_test.TestRepair.test_failure_during_anticompaction
> ---
>
> Key: CASSANDRA-13201
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13201
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>Assignee: Blake Eggleston
>  Labels: dtest, test-failure
> Attachments: node1_debug.log, node1_gc.log, node1.log, 
> node2_debug.log, node2_gc.log, node2.log, node3_debug.log, node3_gc.log, 
> node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/427/testReport/repair_tests.repair_test/TestRepair/test_failure_during_anticompaction
> {code}
> Error Message
> 08 Feb 2017 04:42:14 [node3] Missing: ['Got anticompaction request']:
> INFO  [main] 2017-02-08 04:31:15,447 YamlConfigura.
> See debug.log for remainder
> {code}{code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools/decorators.py", line 48, in 
> wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 1056, in test_failure_during_anticompaction
> self._test_failure_during_repair(phase='anticompaction',)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 1131, in _test_failure_during_repair
> node_to_kill.watch_log_for(msg_to_wait, filename='debug.log')
>   File "/usr/local/lib/python2.7/dist-packages/ccmlib/node.py", line 471, in 
> watch_log_for
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S", time.gmtime()) + " 
> [" + self.name + "] Missing: " + str([e.pattern for e in tofind]) + ":\n" + 
> reads[:50] + ".\nSee {} for remainder".format(filename))
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (CASSANDRA-13199) dtest failure in repair_tests.repair_test.TestRepair.no_anticompaction_after_dclocal_repair_test

2017-02-09 Thread Blake Eggleston (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Blake Eggleston reassigned CASSANDRA-13199:
---

Assignee: Blake Eggleston

> dtest failure in 
> repair_tests.repair_test.TestRepair.no_anticompaction_after_dclocal_repair_test
> 
>
> Key: CASSANDRA-13199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13199
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>Assignee: Blake Eggleston
>  Labels: dtest, test-failure
> Attachments: node1_debug.log, node1_gc.log, node1.log, 
> node2_debug.log, node2_gc.log, node2.log, node3_debug.log, node3_gc.log, 
> node3.log, node4_debug.log, node4_gc.log, node4.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/427/testReport/repair_tests.repair_test/TestRepair/no_anticompaction_after_dclocal_repair_test
> {code}
> Error Message
> Subprocess ['nodetool', '-h', 'localhost', '-p', '7100', ['repair', '-local', 
> 'keyspace1', 'standard1']] exited with non-zero status; exit status: 2; 
> stderr: error: Incremental repairs cannot be run against a subset of tokens 
> or ranges
> -- StackTrace --
> java.lang.IllegalArgumentException: Incremental repairs cannot be run against 
> a subset of tokens or ranges
>   at 
> org.apache.cassandra.repair.messages.RepairOption.parse(RepairOption.java:242)
>   at 
> org.apache.cassandra.service.StorageService.repairAsync(StorageService.java:3258)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
>   at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
>   at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
>   at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
>   at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
>   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
>   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1399)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:828)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
>   at sun.rmi.transport.Transport$1.run(Transport.java:200)
>   at sun.rmi.transport.Transport$1.run(Transport.java:197)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>   at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
>   at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
>   at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$241(TCPTransport.java:683)
>   at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$335/1485984579.run(Unknown
>  Source)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> 

[jira] [Commented] (CASSANDRA-13199) dtest failure in repair_tests.repair_test.TestRepair.no_anticompaction_after_dclocal_repair_test

2017-02-09 Thread Blake Eggleston (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859712#comment-15859712
 ] 

Blake Eggleston commented on CASSANDRA-13199:
-

This is caused by CASSANDRA-9143, and should be addressed by 
https://github.com/riptano/cassandra-dtest/pull/1436

> dtest failure in 
> repair_tests.repair_test.TestRepair.no_anticompaction_after_dclocal_repair_test
> 
>
> Key: CASSANDRA-13199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13199
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>  Labels: dtest, test-failure
> Attachments: node1_debug.log, node1_gc.log, node1.log, 
> node2_debug.log, node2_gc.log, node2.log, node3_debug.log, node3_gc.log, 
> node3.log, node4_debug.log, node4_gc.log, node4.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/427/testReport/repair_tests.repair_test/TestRepair/no_anticompaction_after_dclocal_repair_test
> {code}
> Error Message
> Subprocess ['nodetool', '-h', 'localhost', '-p', '7100', ['repair', '-local', 
> 'keyspace1', 'standard1']] exited with non-zero status; exit status: 2; 
> stderr: error: Incremental repairs cannot be run against a subset of tokens 
> or ranges
> -- StackTrace --
> java.lang.IllegalArgumentException: Incremental repairs cannot be run against 
> a subset of tokens or ranges
>   at 
> org.apache.cassandra.repair.messages.RepairOption.parse(RepairOption.java:242)
>   at 
> org.apache.cassandra.service.StorageService.repairAsync(StorageService.java:3258)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
>   at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
>   at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
>   at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
>   at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
>   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
>   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1399)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:828)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
>   at sun.rmi.transport.Transport$1.run(Transport.java:200)
>   at sun.rmi.transport.Transport$1.run(Transport.java:197)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>   at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
>   at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
>   at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$241(TCPTransport.java:683)
>   at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$335/1485984579.run(Unknown
>  Source)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
>   at 
> 

[jira] [Commented] (CASSANDRA-13201) dtest failure in repair_tests.repair_test.TestRepair.test_failure_during_anticompaction

2017-02-09 Thread Blake Eggleston (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859710#comment-15859710
 ] 

Blake Eggleston commented on CASSANDRA-13201:
-

This is caused by CASSANDRA-9143, and should be addressed by 
https://github.com/riptano/cassandra-dtest/pull/1436

> dtest failure in 
> repair_tests.repair_test.TestRepair.test_failure_during_anticompaction
> ---
>
> Key: CASSANDRA-13201
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13201
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>  Labels: dtest, test-failure
> Attachments: node1_debug.log, node1_gc.log, node1.log, 
> node2_debug.log, node2_gc.log, node2.log, node3_debug.log, node3_gc.log, 
> node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/427/testReport/repair_tests.repair_test/TestRepair/test_failure_during_anticompaction
> {code}
> Error Message
> 08 Feb 2017 04:42:14 [node3] Missing: ['Got anticompaction request']:
> INFO  [main] 2017-02-08 04:31:15,447 YamlConfigura.
> See debug.log for remainder
> {code}{code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools/decorators.py", line 48, in 
> wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 1056, in test_failure_during_anticompaction
> self._test_failure_during_repair(phase='anticompaction',)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 1131, in _test_failure_during_repair
> node_to_kill.watch_log_for(msg_to_wait, filename='debug.log')
>   File "/usr/local/lib/python2.7/dist-packages/ccmlib/node.py", line 471, in 
> watch_log_for
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S", time.gmtime()) + " 
> [" + self.name + "] Missing: " + str([e.pattern for e in tofind]) + ":\n" + 
> reads[:50] + ".\nSee {} for remainder".format(filename))
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (CASSANDRA-13200) dtest failure in repair_tests.repair_test.TestRepair.test_dead_sync_participant

2017-02-09 Thread Blake Eggleston (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Blake Eggleston reassigned CASSANDRA-13200:
---

Assignee: Blake Eggleston

> dtest failure in 
> repair_tests.repair_test.TestRepair.test_dead_sync_participant
> ---
>
> Key: CASSANDRA-13200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13200
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>Assignee: Blake Eggleston
>  Labels: dtest, test-failure
> Attachments: node1_debug.log, node1_gc.log, node1.log, 
> node2_debug.log, node2_gc.log, node2.log, node3_debug.log, node3_gc.log, 
> node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/427/testReport/repair_tests.repair_test/TestRepair/test_dead_sync_participant
> {code}
> Error Message
> 08 Feb 2017 04:31:07 [node1] Missing: ['Endpoint .* died']:
> INFO  [main] 2017-02-08 04:28:51,776 YamlConfigura.
> See system.log for remainder
> {code}{code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools/decorators.py", line 48, in 
> wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 1049, in test_dead_sync_participant
> self._test_failure_during_repair(phase='sync', initiator=False,)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 1139, in _test_failure_during_repair
> node1.watch_log_for('Endpoint .* died', timeout=60)
>   File "/usr/local/lib/python2.7/dist-packages/ccmlib/node.py", line 471, in 
> watch_log_for
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S", time.gmtime()) + " 
> [" + self.name + "] Missing: " + str([e.pattern for e in tofind]) + ":\n" + 
> reads[:50] + ".\nSee {} for remainder".format(filename))
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (CASSANDRA-13200) dtest failure in repair_tests.repair_test.TestRepair.test_dead_sync_participant

2017-02-09 Thread Blake Eggleston (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859711#comment-15859711
 ] 

Blake Eggleston commented on CASSANDRA-13200:
-

This is caused by CASSANDRA-9143, and should be addressed by 
https://github.com/riptano/cassandra-dtest/pull/1436

> dtest failure in 
> repair_tests.repair_test.TestRepair.test_dead_sync_participant
> ---
>
> Key: CASSANDRA-13200
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13200
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>  Labels: dtest, test-failure
> Attachments: node1_debug.log, node1_gc.log, node1.log, 
> node2_debug.log, node2_gc.log, node2.log, node3_debug.log, node3_gc.log, 
> node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/427/testReport/repair_tests.repair_test/TestRepair/test_dead_sync_participant
> {code}
> Error Message
> 08 Feb 2017 04:31:07 [node1] Missing: ['Endpoint .* died']:
> INFO  [main] 2017-02-08 04:28:51,776 YamlConfigura.
> See system.log for remainder
> {code}{code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools/decorators.py", line 48, in 
> wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 1049, in test_dead_sync_participant
> self._test_failure_during_repair(phase='sync', initiator=False,)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 1139, in _test_failure_during_repair
> node1.watch_log_for('Endpoint .* died', timeout=60)
>   File "/usr/local/lib/python2.7/dist-packages/ccmlib/node.py", line 471, in 
> watch_log_for
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S", time.gmtime()) + " 
> [" + self.name + "] Missing: " + str([e.pattern for e in tofind]) + ":\n" + 
> reads[:50] + ".\nSee {} for remainder".format(filename))
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (CASSANDRA-13202) dtest failure in repair_tests.incremental_repair_test.TestIncRepair.sstable_marking_test

2017-02-09 Thread Blake Eggleston (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Blake Eggleston reassigned CASSANDRA-13202:
---

Assignee: Blake Eggleston

> dtest failure in 
> repair_tests.incremental_repair_test.TestIncRepair.sstable_marking_test
> 
>
> Key: CASSANDRA-13202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13202
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>Assignee: Blake Eggleston
>  Labels: dtest, test-failure
> Attachments: node1_debug.log, node1_gc.log, node1.log, 
> node2_debug.log, node2_gc.log, node2.log, node3_debug.log, node3_gc.log, 
> node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/427/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_marking_test
> {code}
> Error Message
> 'Repaired at: 0' unexpectedly found in 'SSTable: 
> /tmp/dtest-9PYhKy/test/node1/data0/keyspace1/standard1-17eaf440edbb11e68d99c3f653778b71/md-1-big\nPartitioner:
>  org.apache.cassandra.dht.Murmur3Partitioner\nBloom Filter FP chance: 
> 0.01\nMinimum timestamp: 1486529856104000\nMaximum timestamp: 
> 1486529859637013\nSSTable min local deletion time: 2147483647\nSSTable max 
> local deletion time: 2147483647\nCompressor: -\nTTL min: 0\nTTL max: 0\nFirst 
> token: -9222701292667950301 (key=5032394c323239385030)\nLast token: 
> -3134717340917976237 (key=304b3338324b324b3430)\nEstimated droppable 
> tombstones: 0.0\nSSTable Level: 0\nRepaired at: 0\nPending repair: 
> 26e751a0-edbb-11e6-accb-61d17d26194a\nReplay positions covered: 
> {CommitLogPosition(segmentId=1486529830270, 
> position=41626)=CommitLogPosition(segmentId=1486529830270, 
> position=2604016)}\ntotalColumnsSet: 16365\ntotalRows: 3273\nEstimated 
> tombstone drop times:\nCount   Row SizeCell Count\n1  
> 0 0\n2  0 
> 0\n3  0 0\n4  
> 0 0\n5  0  
> 6546\n6  0 0\n7   
>0 0\n8  0 0\n10
>  0 0\n12 0
>  0\n14 0 0\n17
>  0 0\n20 0 
> 0\n24 0 0\n29 
> 0 0\n35 0 0\n42   
>   0 0\n50 0   
>   0\n60 0 0\n72   
>   0 0\n86 0 
> 0\n1030 0\n124
> 0 0\n1490 0\n179  
>   0 0\n2152   
>   0\n258 3271 0\n310  
>   0 0\n3720 
> 0\n4460 0\n535
> 0 0\n6420 0\n770  
>   0 0\n9240   
>   0\n1109   0 0\n1331 
>   0 0\n1597   0 
> 0\n1916   0 0\n2299   
> 0 0\n2759   0 0\n3311 
>   0 0\n3973   0   
>   0\n4768   0 0\n5722 
>   0 0\n6866   0 
> 0\n8239   0 0\n9887   
> 0 0\n11864  0 0\n14237
>   0 0\n17084  0   
>   0\n20501  0 0\n24601
>   0 0\n29521  0 
> 0\n35425  0 0\n42510  
> 0 0\n51012  0 0\n61214
>   0 0\n73457  0   
>

[jira] [Commented] (CASSANDRA-13202) dtest failure in repair_tests.incremental_repair_test.TestIncRepair.sstable_marking_test

2017-02-09 Thread Blake Eggleston (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859709#comment-15859709
 ] 

Blake Eggleston commented on CASSANDRA-13202:
-

This is caused by CASSANDRA-9143, and should be addressed by 
https://github.com/riptano/cassandra-dtest/pull/1436

> dtest failure in 
> repair_tests.incremental_repair_test.TestIncRepair.sstable_marking_test
> 
>
> Key: CASSANDRA-13202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13202
> Project: Cassandra
>  Issue Type: Bug
>  Components: Testing
>Reporter: Sean McCarthy
>  Labels: dtest, test-failure
> Attachments: node1_debug.log, node1_gc.log, node1.log, 
> node2_debug.log, node2_gc.log, node2.log, node3_debug.log, node3_gc.log, 
> node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/427/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_marking_test
> {code}
> Error Message
> 'Repaired at: 0' unexpectedly found in 'SSTable: 
> /tmp/dtest-9PYhKy/test/node1/data0/keyspace1/standard1-17eaf440edbb11e68d99c3f653778b71/md-1-big\nPartitioner:
>  org.apache.cassandra.dht.Murmur3Partitioner\nBloom Filter FP chance: 
> 0.01\nMinimum timestamp: 1486529856104000\nMaximum timestamp: 
> 1486529859637013\nSSTable min local deletion time: 2147483647\nSSTable max 
> local deletion time: 2147483647\nCompressor: -\nTTL min: 0\nTTL max: 0\nFirst 
> token: -9222701292667950301 (key=5032394c323239385030)\nLast token: 
> -3134717340917976237 (key=304b3338324b324b3430)\nEstimated droppable 
> tombstones: 0.0\nSSTable Level: 0\nRepaired at: 0\nPending repair: 
> 26e751a0-edbb-11e6-accb-61d17d26194a\nReplay positions covered: 
> {CommitLogPosition(segmentId=1486529830270, 
> position=41626)=CommitLogPosition(segmentId=1486529830270, 
> position=2604016)}\ntotalColumnsSet: 16365\ntotalRows: 3273\nEstimated 
> tombstone drop times:\nCount   Row SizeCell Count\n1  
> 0 0\n2  0 
> 0\n3  0 0\n4  
> 0 0\n5  0  
> 6546\n6  0 0\n7   
>0 0\n8  0 0\n10
>  0 0\n12 0
>  0\n14 0 0\n17
>  0 0\n20 0 
> 0\n24 0 0\n29 
> 0 0\n35 0 0\n42   
>   0 0\n50 0   
>   0\n60 0 0\n72   
>   0 0\n86 0 
> 0\n1030 0\n124
> 0 0\n1490 0\n179  
>   0 0\n2152   
>   0\n258 3271 0\n310  
>   0 0\n3720 
> 0\n4460 0\n535
> 0 0\n6420 0\n770  
>   0 0\n9240   
>   0\n1109   0 0\n1331 
>   0 0\n1597   0 
> 0\n1916   0 0\n2299   
> 0 0\n2759   0 0\n3311 
>   0 0\n3973   0   
>   0\n4768   0 0\n5722 
>   0 0\n6866   0 
> 0\n8239   0 0\n9887   
> 0 0\n11864  0 0\n14237
>   0 0\n17084  0   
>   0\n20501  0 0\n24601
>   0 0\n29521  0 
> 0\n35425  0 0\n42510  
> 0 0\n51012  0 0\n61214
> 

[jira] [Created] (CASSANDRA-13203) UPDATE USING TIMESTAMP can surprisingly append to a list column instead of replace

2017-02-09 Thread craig mcmillan (JIRA)
craig mcmillan created CASSANDRA-13203:
--

 Summary: UPDATE USING TIMESTAMP can surprisingly append to a list 
column instead of replace
 Key: CASSANDRA-13203
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13203
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: craig mcmillan
Priority: Minor


{code}
create table stufflist (id uuid primary key , stuff list);

insert into stufflist (id, stuff) values (75a01c40-eed9-11e6-930a-939ae9ea5575, 
['one']) using timestamp 1000;

update stufflist using timestamp 1000 set stuff=['one'] where 
id=75a01c40-eed9-11e6-930a-939ae9ea5575;

select * from stufflist;

 id   | stuff
--+
 75a01c40-eed9-11e6-930a-939ae9ea5575 | ['one', 'one']
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-9667) strongly consistent membership and ownership

2017-02-09 Thread Jason Brown (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Brown updated CASSANDRA-9667:
---
Fix Version/s: (was: 3.x)

> strongly consistent membership and ownership
> 
>
> Key: CASSANDRA-9667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9667
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Jason Brown
>  Labels: LWT, membership, ownership
>
> Currently, there is advice to users to "wait two minutes between adding new 
> nodes" in order for new node tokens, et al, to propagate. Further, as there's 
> no coordination amongst joining node wrt token selection, new nodes can end 
> up selecting ranges that overlap with other joining nodes. This causes a lot 
> of duplicate streaming from the existing source nodes as they shovel out the 
> bootstrap data for those new nodes.
> This ticket proposes creating a mechanism that allows strongly consistent 
> membership and ownership changes in cassandra such that changes are performed 
> in a linearizable and safe manner. The basic idea is to use LWT operations 
> over a global system table, and leverage the linearizability of LWT for 
> ensuring the safety of cluster membership/ownership state changes. This work 
> is inspired by Riak's claimant module.
> The existing workflows for node join, decommission, remove, replace, and 
> range move (there may be others I'm not thinking of) will need to be modified 
> to participate in this scheme, as well as changes to nodetool to enable them.
> Note: we distinguish between membership and ownership in the following ways: 
> for membership we mean "a host in this cluster and it's state". For 
> ownership, we mean "what tokens (or ranges) does each node own"; these nodes 
> must already be a member to be assigned tokens.
> A rough draft sketch of how the 'add new node' workflow might look like is: 
> new nodes would no longer create tokens themselves, but instead contact a 
> member of a Paxos cohort (via a seed). The cohort member will generate the 
> tokens and execute a LWT transaction, ensuring a linearizable change to the 
> membership/ownership state. The updated state will then be disseminated via 
> the existing gossip.
> As for joining specifically, I think we could support two modes: auto-mode 
> and manual-mode. Auto-mode is for adding a single new node per LWT operation, 
> and would require no operator intervention (much like today). In manual-mode, 
> however, multiple new nodes could (somehow) signal their their intent to join 
> to the cluster, but will wait until an operator executes a nodetool command 
> that will trigger the token generation and LWT operation for all pending new 
> nodes. This will allow us better range partitioning and will make the 
> bootstrap streaming more efficient as we won't have overlapping range 
> requests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (CASSANDRA-13109) Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0

2017-02-09 Thread Sylvain Lebresne (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylvain Lebresne updated CASSANDRA-13109:
-
   Resolution: Fixed
Fix Version/s: 3.11.0
   3.0.11
Reproduced In: 3.0.10, 3.0.9, 3.0.8  (was: 3.0.8, 3.0.9, 3.0.10)
   Status: Resolved  (was: Patch Available)

CI was clean so committed, thanks.

> Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0
> ---
>
> Key: CASSANDRA-13109
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13109
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Klock
>Assignee: Samuel Klock
> Fix For: 3.0.11, 3.11.0
>
> Attachments: 13109-3.0.txt
>
>
> We've observed this upgrading from 2.1.15 to 3.0.8 and from 2.1.16 to 3.0.10: 
> some lightweight transactions executed on upgraded nodes fail with a read 
> failure.  The following conditions seem relevant to this occurring:
> * The transaction must be conditioned on the current value of at least one 
> column, e.g., {{IF NOT EXISTS}} transactions don't seem to be affected.
> * There should be a collection column (in our case, a map) defined on the 
> table on which the transaction is executed.
> * The transaction should be executed before sstables on the node are 
> upgraded.  The failure does not occur after the sstables have been upgraded 
> (whether via {{nodetool upgradesstables}} or effectively via compaction).
> * Upgraded nodes seem to be able to participate in lightweight transactions 
> as long as they're not the coordinator.
> * The values in the row being manipulated by the transaction must have been 
> consistently manipulated by lightweight transactions (perhaps the existence 
> of Paxos state for the partition is somehow relevant?).
> * In 3.0.10, it _seems_ to be necessary to have the partition split across 
> multiple legacy sstables.  This was not necessary to reproduce the bug in 
> 3.0.8 or .9.
> For applications affected by this bug, a possible workaround is to prevent 
> nodes being upgraded from coordinating requests until sstables have been 
> upgraded.
> We're able to reproduce this when upgrading from 2.1.16 to 3.0.10 with the 
> following steps on a single-node cluster using a mostly pristine 
> {{cassandra.yaml}} from the source distribution.
> # Start Cassandra-2.1.16 on the node.
> # Create a table with a collection column and insert some data into it.
> {code:sql}
> CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> CREATE TABLE test.test (key TEXT PRIMARY KEY, cas_target TEXT, 
> some_collection MAP);
> INSERT INTO test.test (key, cas_target, some_collection) VALUES ('key', 
> 'value', {}) IF NOT EXISTS;
> {code}
> # Flush the row to an sstable: {{nodetool flush}}.
> # Update the row:
> {code:sql}
> UPDATE test.test SET cas_target = 'newvalue', some_collection = {} WHERE key 
> = 'key' IF cas_target = 'value';
> {code}
> # Drain the node: {{nodetool drain}}
> # Stop the node, upgrade to 3.0.10, and start the node.
> # Attempt to update the row again:
> {code:sql}
> UPDATE test.test SET cas_target = 'lastvalue' WHERE key = 'key' IF cas_target 
> = 'newvalue';
> {code}
> Using {{cqlsh}}, if the error is reproduced, the following output will be 
> returned:
> {code:sql}
> $ ./cqlsh <<< "UPDATE test.test SET cas_target = 'newvalue', some_collection 
> = {} WHERE key = 'key' IF cas_target = 'value';"
> (start: 2016-12-22 10:14:27 EST)
> :2:ReadFailure: Error from server: code=1300 [Replica(s) failed to 
> execute read] message="Operation failed - received 0 responses and 1 
> failures" info={'failures': 1, 'received_responses': 0, 'required_responses': 
> 1, 'consistency': 'QUORUM'}
> {code}
> and the following stack trace will be present in the system log:
> {noformat}
> WARN  15:14:28 Uncaught exception on thread 
> Thread[SharedPool-Worker-10,10,main]: {}
> java.lang.RuntimeException: java.lang.NullPointerException
>   at 
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2476)
>  ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_101]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  ~[main/:na]
>   at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
>  [main/:na]
>   at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [main/:na]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> Caused by: java.lang.NullPointerException: null
>   at 
> 

[2/6] cassandra git commit: Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0

2017-02-09 Thread slebresne
Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0

patch by Samuel Klock and Sylvain Lebresne; reviewed by Sylvain Lebresne for 
CASSANDRA-13109


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/74fdfe0a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/74fdfe0a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/74fdfe0a

Branch: refs/heads/cassandra-3.11
Commit: 74fdfe0a5f9bd8d3c525e771e2ba2cd3cfc18697
Parents: 7c2437e
Author: Samuel Klock 
Authored: Thu Feb 9 10:24:10 2017 +0100
Committer: Sylvain Lebresne 
Committed: Thu Feb 9 10:26:08 2017 +0100

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/db/LegacyLayout.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/74fdfe0a/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7da61e7..1f638da 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.11
+ * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
  * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
  * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)
  * Abort or retry on failed hints delivery (CASSANDRA-13124)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/74fdfe0a/src/java/org/apache/cassandra/db/LegacyLayout.java
--
diff --git a/src/java/org/apache/cassandra/db/LegacyLayout.java 
b/src/java/org/apache/cassandra/db/LegacyLayout.java
index 3788c3c..972bb9f 100644
--- a/src/java/org/apache/cassandra/db/LegacyLayout.java
+++ b/src/java/org/apache/cassandra/db/LegacyLayout.java
@@ -1261,7 +1261,7 @@ public abstract class LegacyLayout
 return true;
 }
 
-if (tombstone.isCollectionTombstone())
+if (tombstone.isCollectionTombstone() && 
helper.includes(tombstone.start.collectionName))
 {
 if (clustering == null)
 {



[4/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

2017-02-09 Thread slebresne
Merge branch 'cassandra-3.0' into cassandra-3.11

* cassandra-3.0:
  Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6a504f40
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6a504f40
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6a504f40

Branch: refs/heads/trunk
Commit: 6a504f40305bea990187d8d1fec2dbb093ddf7a2
Parents: 6b7302b 74fdfe0
Author: Sylvain Lebresne 
Authored: Thu Feb 9 10:27:00 2017 +0100
Committer: Sylvain Lebresne 
Committed: Thu Feb 9 10:27:00 2017 +0100

--
 CHANGES.txt| 2 ++
 src/java/org/apache/cassandra/db/LegacyLayout.java | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6a504f40/CHANGES.txt
--
diff --cc CHANGES.txt
index e346722,1f638da..eb10bad
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,12 -1,8 +1,14 @@@
 -3.0.11
 +3.11.0
 + * Move to FastThreadLocalThread and FastThreadLocal (CASSANDRA-13034)
 + * nodetool stopdaemon errors out (CASSANDRA-13030)
 + * Tables in system_distributed should not use gcgs of 0 (CASSANDRA-12954)
 + * Fix primary index calculation for SASI (CASSANDRA-12910)
 + * More fixes to the TokenAllocator (CASSANDRA-12990)
 + * NoReplicationTokenAllocator should work with zero replication factor 
(CASSANDRA-12983)
 +Merged from 3.0:
+  * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
+  * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
   * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)
 - * Abort or retry on failed hints delivery (CASSANDRA-13124)
   * Fix handling of partition with partition-level deletion plus
 live rows in sstabledump (CASSANDRA-13177)
   * Provide user workaround when system_schema.columns does not contain entries

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6a504f40/src/java/org/apache/cassandra/db/LegacyLayout.java
--



[6/6] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

2017-02-09 Thread slebresne
Merge branch 'cassandra-3.11' into trunk

* cassandra-3.11:
  Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4550734c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4550734c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4550734c

Branch: refs/heads/trunk
Commit: 4550734c2a400e5eedd6010e3fa1eaf535ae9003
Parents: a9207a4 6a504f4
Author: Sylvain Lebresne 
Authored: Thu Feb 9 10:27:29 2017 +0100
Committer: Sylvain Lebresne 
Committed: Thu Feb 9 10:27:29 2017 +0100

--
 CHANGES.txt | 2 ++
 1 file changed, 2 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/4550734c/CHANGES.txt
--



[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

2017-02-09 Thread slebresne
Merge branch 'cassandra-3.0' into cassandra-3.11

* cassandra-3.0:
  Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6a504f40
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6a504f40
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6a504f40

Branch: refs/heads/cassandra-3.11
Commit: 6a504f40305bea990187d8d1fec2dbb093ddf7a2
Parents: 6b7302b 74fdfe0
Author: Sylvain Lebresne 
Authored: Thu Feb 9 10:27:00 2017 +0100
Committer: Sylvain Lebresne 
Committed: Thu Feb 9 10:27:00 2017 +0100

--
 CHANGES.txt| 2 ++
 src/java/org/apache/cassandra/db/LegacyLayout.java | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/6a504f40/CHANGES.txt
--
diff --cc CHANGES.txt
index e346722,1f638da..eb10bad
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,12 -1,8 +1,14 @@@
 -3.0.11
 +3.11.0
 + * Move to FastThreadLocalThread and FastThreadLocal (CASSANDRA-13034)
 + * nodetool stopdaemon errors out (CASSANDRA-13030)
 + * Tables in system_distributed should not use gcgs of 0 (CASSANDRA-12954)
 + * Fix primary index calculation for SASI (CASSANDRA-12910)
 + * More fixes to the TokenAllocator (CASSANDRA-12990)
 + * NoReplicationTokenAllocator should work with zero replication factor 
(CASSANDRA-12983)
 +Merged from 3.0:
+  * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
+  * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
   * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)
 - * Abort or retry on failed hints delivery (CASSANDRA-13124)
   * Fix handling of partition with partition-level deletion plus
 live rows in sstabledump (CASSANDRA-13177)
   * Provide user workaround when system_schema.columns does not contain entries

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6a504f40/src/java/org/apache/cassandra/db/LegacyLayout.java
--



[1/6] cassandra git commit: Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0

2017-02-09 Thread slebresne
Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 7c2437e26 -> 74fdfe0a5
  refs/heads/cassandra-3.11 6b7302b65 -> 6a504f403
  refs/heads/trunk a9207a44a -> 4550734c2


Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0

patch by Samuel Klock and Sylvain Lebresne; reviewed by Sylvain Lebresne for 
CASSANDRA-13109


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/74fdfe0a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/74fdfe0a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/74fdfe0a

Branch: refs/heads/cassandra-3.0
Commit: 74fdfe0a5f9bd8d3c525e771e2ba2cd3cfc18697
Parents: 7c2437e
Author: Samuel Klock 
Authored: Thu Feb 9 10:24:10 2017 +0100
Committer: Sylvain Lebresne 
Committed: Thu Feb 9 10:26:08 2017 +0100

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/db/LegacyLayout.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/74fdfe0a/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7da61e7..1f638da 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.11
+ * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
  * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
  * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)
  * Abort or retry on failed hints delivery (CASSANDRA-13124)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/74fdfe0a/src/java/org/apache/cassandra/db/LegacyLayout.java
--
diff --git a/src/java/org/apache/cassandra/db/LegacyLayout.java 
b/src/java/org/apache/cassandra/db/LegacyLayout.java
index 3788c3c..972bb9f 100644
--- a/src/java/org/apache/cassandra/db/LegacyLayout.java
+++ b/src/java/org/apache/cassandra/db/LegacyLayout.java
@@ -1261,7 +1261,7 @@ public abstract class LegacyLayout
 return true;
 }
 
-if (tombstone.isCollectionTombstone())
+if (tombstone.isCollectionTombstone() && 
helper.includes(tombstone.start.collectionName))
 {
 if (clustering == null)
 {



[3/6] cassandra git commit: Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0

2017-02-09 Thread slebresne
Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0

patch by Samuel Klock and Sylvain Lebresne; reviewed by Sylvain Lebresne for 
CASSANDRA-13109


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/74fdfe0a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/74fdfe0a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/74fdfe0a

Branch: refs/heads/trunk
Commit: 74fdfe0a5f9bd8d3c525e771e2ba2cd3cfc18697
Parents: 7c2437e
Author: Samuel Klock 
Authored: Thu Feb 9 10:24:10 2017 +0100
Committer: Sylvain Lebresne 
Committed: Thu Feb 9 10:26:08 2017 +0100

--
 CHANGES.txt| 1 +
 src/java/org/apache/cassandra/db/LegacyLayout.java | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/74fdfe0a/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 7da61e7..1f638da 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.0.11
+ * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
  * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
  * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)
  * Abort or retry on failed hints delivery (CASSANDRA-13124)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/74fdfe0a/src/java/org/apache/cassandra/db/LegacyLayout.java
--
diff --git a/src/java/org/apache/cassandra/db/LegacyLayout.java 
b/src/java/org/apache/cassandra/db/LegacyLayout.java
index 3788c3c..972bb9f 100644
--- a/src/java/org/apache/cassandra/db/LegacyLayout.java
+++ b/src/java/org/apache/cassandra/db/LegacyLayout.java
@@ -1261,7 +1261,7 @@ public abstract class LegacyLayout
 return true;
 }
 
-if (tombstone.isCollectionTombstone())
+if (tombstone.isCollectionTombstone() && 
helper.includes(tombstone.start.collectionName))
 {
 if (clustering == null)
 {



[jira] [Comment Edited] (CASSANDRA-13109) Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0

2017-02-09 Thread Sylvain Lebresne (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857806#comment-15857806
 ] 

Sylvain Lebresne edited comment on CASSANDRA-13109 at 2/9/17 9:25 AM:
--

Thanks for the report and reproduction steps. I _was_ able to reproduce this 
consistently with 3.0.10 but this actually happens to be fixed on the current 
3.0 branch (future 3.0.11).

And the reason this is not a problem anymore is CASSANDRA-12694 and that's 
because it basically made us fetch all columns for CAS (much like we do for any 
other CQL query really), thus side-stepping the "the code to read legacy 
sstable can return stuffs for non fetched columns".

That said, that problem in {{LegacyLayout}} is kind of legit: we should include 
something that is not fetched and while we correctly skip non-fetched column 
for "cells", we did miss doing the same for collection tombsones. But I say 
"kind of" because thruth is, after CASSANDRA-12694, I'm not sure we can really 
run into this problem anymore: only thrift queries uses the mode where we don't 
fetch all columns, but thrift don't support collections so actually cannot 
create a query that would be problematic for this case.

Still, the code is definitively not doing what it should and the fix is trivial 
enough that it's not worth risking running into problems in the future, or if I 
happen to miss a genuine case where this could happen, so I've pushed the patch 
for CI below and will commit if tests are clear. I did modify said patch a bit 
because if the column for which we have a collection tombstone is not fetched, 
we also want to skip the few lines that were before the condition your patch 
added as otherwise we might end up returning an empty row which would break 
assumptions of the code. Still, mostly the same thing, just moving the 
condition a bit up.
| [13109-3.0|https://github.com/pcmanus/cassandra/commits/13109-3.0] | 
[utests|http://cassci.datastax.com/job/pcmanus-13109-3.0-testall] | 
[dtests|http://cassci.datastax.com/job/pcmanus-13109-3.0-dtest] |
| [13109-3.11|https://github.com/pcmanus/cassandra/commits/13109-3.11] | 
[utests|http://cassci.datastax.com/job/pcmanus-13109-3.11-testall] | 
[dtests|http://cassci.datastax.com/job/pcmanus-13109-3.11-dtest] |



was (Author: slebresne):
Thanks for the report and reproduction steps. I _was_ able to reproduce this 
consistently with 3.0.10 but this actually happens to be fixed on the current 
3.0 branch (future 3.0.11).

And the reason this is not a problem anymore is CASSANDRA-12694 and that's 
because it basically made us fetch all columns for CAS (much like we do for any 
other CQL query really), thus side-stepping the "the code to read legacy 
sstable can return stuffs for non fetched columns".

That said, that problem in {{LegacyLayout}} is kind of legit: we should include 
something that is not fetched and while we correctly skip non-fetched column 
for "cells", we did miss doing the same for collection tombsones. But I say 
"kind of" because thruth is, after CASSANDRA-12694, I'm not sure we can really 
run into this problem anymore: only thrift queries uses the mode where we don't 
fetch all columns, but thrift don't support collections so actually cannot 
create a query that would be problematic for this case.

Still, the code is definitively not doing what it should and the fix is trivial 
enough that it's not worth risking running into problems in the future, or if I 
happen to miss a genuine case where this could happen, so I've pushed the patch 
for CI below and will commit if tests are clear. I did modify said patch a bit 
because if the column for which we have a collection tombstone is not fetched, 
we also want to skip the few lines that were before the condition your patch 
added as otherwise we might end up returning an empty row which would break 
assumptions of the code. Still, mostly the same thing, just moving the 
condition a bit up.
| [13019-3.0|https://github.com/pcmanus/cassandra/commits/13019-3.0] | 
[utests|http://cassci.datastax.com/job/pcmanus-13019-3.0-testall] | 
[dtests|http://cassci.datastax.com/job/pcmanus-13019-3.0-dtest] |
| [13019-3.11|https://github.com/pcmanus/cassandra/commits/13019-3.11] | 
[utests|http://cassci.datastax.com/job/pcmanus-13019-3.11-testall] | 
[dtests|http://cassci.datastax.com/job/pcmanus-13019-3.11-dtest] |


> Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0
> ---
>
> Key: CASSANDRA-13109
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13109
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Samuel Klock
>Assignee: Samuel Klock
> Attachments: 13109-3.0.txt
>
>
> We've observed this upgrading from 2.1.15 to 3.0.8 and from 2.1.16 to 3.0.10: 
> some 

[jira] [Commented] (CASSANDRA-13038) 33% of compaction time spent in StreamingHistogram.update()

2017-02-09 Thread Sylvain Lebresne (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859243#comment-15859243
 ] 

Sylvain Lebresne commented on CASSANDRA-13038:
--

bq. and then make it tunable via system property

I'd rather we don't. There is imo such a thing as configuration creep and I 
really don't think it's useful here.

Frankly, I'd personally just go with 5 minutes round-up and call it a day. I 
genuinely don't think it would be reasonable for any user to rely on a high 
precision if only, again, because the there is other factor that make it 
impossible to rely on this.

But whatever, I don't care that much, and if going with 1 minute make anyone 
sleep better for some reason, let's go with that. But please let's not add more 
configuration for this.


> 33% of compaction time spent in StreamingHistogram.update()
> ---
>
> Key: CASSANDRA-13038
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13038
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Corentin Chary
>Assignee: Jeff Jirsa
> Attachments: compaction-speedup.patch, 
> compaction-streaminghistrogram.png, profiler-snapshot.nps
>
>
> With the following table, that contains a *lot* of cells: 
> {code}
> CREATE TABLE biggraphite.datapoints_11520p_60s (
> metric uuid,
> time_start_ms bigint,
> offset smallint,
> count int,
> value double,
> PRIMARY KEY ((metric, time_start_ms), offset)
> ) WITH CLUSTERING ORDER BY (offset DESC);
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy', 
> 'compaction_window_size': '6', 'compaction_window_unit': 'HOURS', 
> 'max_threshold': '32', 'min_threshold': '6'}
> Keyspace : biggraphite
> Read Count: 1822
> Read Latency: 1.8870054884742042 ms.
> Write Count: 2212271647
> Write Latency: 0.027705127678653473 ms.
> Pending Flushes: 0
> Table: datapoints_11520p_60s
> SSTable count: 47
> Space used (live): 300417555945
> Space used (total): 303147395017
> Space used by snapshots (total): 0
> Off heap memory used (total): 207453042
> SSTable Compression Ratio: 0.4955200053039823
> Number of keys (estimate): 16343723
> Memtable cell count: 220576
> Memtable data size: 17115128
> Memtable off heap memory used: 0
> Memtable switch count: 2872
> Local read count: 0
> Local read latency: NaN ms
> Local write count: 1103167888
> Local write latency: 0.025 ms
> Pending flushes: 0
> Percent repaired: 0.0
> Bloom filter false positives: 0
> Bloom filter false ratio: 0.0
> Bloom filter space used: 105118296
> Bloom filter off heap memory used: 106547192
> Index summary off heap memory used: 27730962
> Compression metadata off heap memory used: 73174888
> Compacted partition minimum bytes: 61
> Compacted partition maximum bytes: 51012
> Compacted partition mean bytes: 7899
> Average live cells per slice (last five minutes): NaN
> Maximum live cells per slice (last five minutes): 0
> Average tombstones per slice (last five minutes): NaN
> Maximum tombstones per slice (last five minutes): 0
> Dropped Mutations: 0
> {code}
> It looks like a good chunk of the compaction time is lost in 
> StreamingHistogram.update() (which is used to store the estimated tombstone 
> drop times).
> This could be caused by a huge number of different deletion times which would 
> makes the bin huge but it this histogram should be capped to 100 keys. It's 
> more likely caused by the huge number of cells.
> A simple solutions could be to only take into accounts part of the cells, the 
> fact the this table has a TWCS also gives us an additional hint that sampling 
> deletion times would be fine.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)