[jira] [Commented] (CASSANDRA-14848) When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes

2019-02-20 Thread Tommy Stendahl (JIRA)


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

Tommy Stendahl commented on CASSANDRA-14848:


Patch is available here: 
[cassandra-14848|https://github.com/tommystendahl/cassandra/commit/d2a9cfe87c0e41e20ea43a75bab76f2cba8e293c]

> When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non 
> seed nodes
> -
>
> Key: CASSANDRA-14848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14848
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Blocker
>  Labels: security
> Fix For: 4.0
>
>
> When upgrading from 3.11.3 to 4.0 with server encryption enabled the new 4.0 
> node only connects to 3.11.3 seed node, there are no connection established 
> to non-seed nodes on the old version.
> I have four nodes, *.242 is upgraded to 4.0, *.243 and *.244 are 3.11.3 
> non-seed and *.246 are 3.11.3 seed. After starting the 4.0 node I get this 
> nodetool status on the different nodes:
> {noformat}
> *.242
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 1017.77 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> DN 10.216.193.243 743.32 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 
> RAC1
> DN 10.216.193.244 711.54 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 659.81 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> *.243 and *.244
> -- Address Load Tokens Owns (effective) Host ID Rack
> DN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> *.246
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> {noformat}
>  
> I have built 4.0 with wire tracing activated and in my config the 
> storage_port=12700 and ssl_storage_port=12701. In the log I can see that the 
> 4.0 node start to connect to the 3.11.3 seed node on the storage_port but 
> quickly switch to the ssl_storage_port, but when connecting to the non-seed 
> nodes it never switch to the ssl_storage_port.
> {noformat}
> >grep 193.246 system.log | grep Outbound
> 2018-10-25T10:57:36.799+0200 [MessagingService-NettyOutbound-Thread-4-1] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x2f0e5e55] CONNECT: 
> /10.216.193.246:12700
> 2018-10-25T10:57:36.902+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c] CONNECT: 
> /10.216.193.246:12701
> 2018-10-25T10:57:36.905+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c, 
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] ACTIVE
> 2018-10-25T10:57:36.906+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c, 
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] WRITE: 8B
> >grep 193.243 system.log | grep Outbound
> 2018-10-25T10:57:38.438+0200 [MessagingService-NettyOutbound-Thread-4-3] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xd8f1d6c4] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.540+0200 [MessagingService-NettyOutbound-Thread-4-4] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xfde6cc9f] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.694+0200 [MessagingService-NettyOutbound-Thread-4-5] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x7e87fc4e] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.741+0200 [MessagingService-NettyOutbound-Thread-4-7] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x39395296] CONNECT: 
> /10.216.193.243:12700{noformat}
>  
> When I had the dbug log activated and started the 4.0 node I can see that it 
> switch port for *.246 but not for *.243 and *.244.
> {noformat}
> >grep DEBUG system.log| grep OutboundMessagingConnection | grep 
> >maybeUpdateConnectionId
> 2018-10-25T13:12:56.095+0200 [ScheduledFastTasks:1] DEBUG 
> o.a.c.n.a.OutboundMessagingConnection:314 maybeUpdateConnectionId changing 
> connectionId to 10.216.193.246:12701 

[jira] [Updated] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric

2019-02-20 Thread Anup Shirolkar (JIRA)


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

Anup Shirolkar updated CASSANDRA-15015:
---
Attachment: (was: 150150-trunk.txt)

> Cassandra metrics documentation is not correct for Hint_delays metric
> -
>
> Key: CASSANDRA-15015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15015
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Blog
>Reporter: Anup Shirolkar
>Assignee: Anup Shirolkar
>Priority: Minor
>  Labels: documentation, easyfix, low-hanging-fruit
> Fix For: 3.0.19, 3.11.5, 4.0
>
> Attachments: 150150-trunk.txt
>
>
> The Cassandra metrics for hint delays are not correctly referred on the 
> documentation web page: 
> [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics]
>  
> The metrics are defined in the 
> [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52]
>  as 'Hint_delays' and 'Hint_delays-' but those are listed on the 
> website as 'Hints_delays' and 'Hints_delays-'.
> The documentation should be fixed by removing the extra 's' in Hints to match 
> it with code.
> The Jira for adding hint_delays: CASSANDRA-13234 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric

2019-02-20 Thread Anup Shirolkar (JIRA)


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

Anup Shirolkar updated CASSANDRA-15015:
---
Attachment: 150150-trunk.txt
Status: Patch Available  (was: Open)

> Cassandra metrics documentation is not correct for Hint_delays metric
> -
>
> Key: CASSANDRA-15015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15015
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Blog
>Reporter: Anup Shirolkar
>Assignee: Anup Shirolkar
>Priority: Minor
>  Labels: documentation, easyfix, low-hanging-fruit
> Fix For: 3.0.19, 3.11.5, 4.0
>
> Attachments: 150150-trunk.txt
>
>
> The Cassandra metrics for hint delays are not correctly referred on the 
> documentation web page: 
> [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics]
>  
> The metrics are defined in the 
> [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52]
>  as 'Hint_delays' and 'Hint_delays-' but those are listed on the 
> website as 'Hints_delays' and 'Hints_delays-'.
> The documentation should be fixed by removing the extra 's' in Hints to match 
> it with code.
> The Jira for adding hint_delays: CASSANDRA-13234 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric

2019-02-20 Thread Anup Shirolkar (JIRA)


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

Anup Shirolkar updated CASSANDRA-15015:
---
Status: In Progress  (was: Patch Available)

> Cassandra metrics documentation is not correct for Hint_delays metric
> -
>
> Key: CASSANDRA-15015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15015
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Blog
>Reporter: Anup Shirolkar
>Assignee: Anup Shirolkar
>Priority: Minor
>  Labels: documentation, easyfix, low-hanging-fruit
> Fix For: 3.0.19, 3.11.5, 4.0
>
> Attachments: 150150-trunk.txt
>
>
> The Cassandra metrics for hint delays are not correctly referred on the 
> documentation web page: 
> [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics]
>  
> The metrics are defined in the 
> [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52]
>  as 'Hint_delays' and 'Hint_delays-' but those are listed on the 
> website as 'Hints_delays' and 'Hints_delays-'.
> The documentation should be fixed by removing the extra 's' in Hints to match 
> it with code.
> The Jira for adding hint_delays: CASSANDRA-13234 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Comment Edited] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric

2019-02-20 Thread Anup Shirolkar (JIRA)


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

Anup Shirolkar edited comment on CASSANDRA-15015 at 2/21/19 2:12 AM:
-

[~djoshi3] I have attached a patch now. Can you please review it. Thanks.

Sorry, I had to delete the patch I had submitted last time as I did not follow 
the process. I think its all good now.

Also created a branch in case required for review:

[https://github.com/instaclustr/cassandra/tree/150150] 


was (Author: anupshirolkar):
[~djoshi3] I have attached a patch now. Can you please review it. Thanks.

Sorry, I had to delete the patch I had submitted last time as I did not follow 
the process. I think its all good now.

> Cassandra metrics documentation is not correct for Hint_delays metric
> -
>
> Key: CASSANDRA-15015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15015
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Blog
>Reporter: Anup Shirolkar
>Assignee: Anup Shirolkar
>Priority: Minor
>  Labels: documentation, easyfix, low-hanging-fruit
> Fix For: 3.0.19, 3.11.5, 4.0
>
> Attachments: 150150-trunk.txt
>
>
> The Cassandra metrics for hint delays are not correctly referred on the 
> documentation web page: 
> [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics]
>  
> The metrics are defined in the 
> [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52]
>  as 'Hint_delays' and 'Hint_delays-' but those are listed on the 
> website as 'Hints_delays' and 'Hints_delays-'.
> The documentation should be fixed by removing the extra 's' in Hints to match 
> it with code.
> The Jira for adding hint_delays: CASSANDRA-13234 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Comment Edited] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric

2019-02-20 Thread Anup Shirolkar (JIRA)


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

Anup Shirolkar edited comment on CASSANDRA-15015 at 2/21/19 2:10 AM:
-

[~djoshi3] I have attached a patch now. Can you please review it. Thanks.

Sorry, I had to delete the patch I had submitted last time as I did not follow 
the process. I think its all good now.


was (Author: anupshirolkar):
[~djoshi3] I have attached a patch now. Can you please review it. Thanks.

> Cassandra metrics documentation is not correct for Hint_delays metric
> -
>
> Key: CASSANDRA-15015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15015
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Blog
>Reporter: Anup Shirolkar
>Assignee: Anup Shirolkar
>Priority: Minor
>  Labels: documentation, easyfix, low-hanging-fruit
> Fix For: 3.0.19, 3.11.5, 4.0
>
> Attachments: 150150-trunk.txt
>
>
> The Cassandra metrics for hint delays are not correctly referred on the 
> documentation web page: 
> [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics]
>  
> The metrics are defined in the 
> [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52]
>  as 'Hint_delays' and 'Hint_delays-' but those are listed on the 
> website as 'Hints_delays' and 'Hints_delays-'.
> The documentation should be fixed by removing the extra 's' in Hints to match 
> it with code.
> The Jira for adding hint_delays: CASSANDRA-13234 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric

2019-02-20 Thread Anup Shirolkar (JIRA)


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

Anup Shirolkar commented on CASSANDRA-15015:


[~djoshi3] I have attached a patch now. Can you please review it. Thanks.

> Cassandra metrics documentation is not correct for Hint_delays metric
> -
>
> Key: CASSANDRA-15015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15015
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Blog
>Reporter: Anup Shirolkar
>Assignee: Anup Shirolkar
>Priority: Minor
>  Labels: documentation, easyfix, low-hanging-fruit
> Fix For: 3.0.19, 3.11.5, 4.0
>
> Attachments: 150150-trunk.txt
>
>
> The Cassandra metrics for hint delays are not correctly referred on the 
> documentation web page: 
> [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics]
>  
> The metrics are defined in the 
> [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52]
>  as 'Hint_delays' and 'Hint_delays-' but those are listed on the 
> website as 'Hints_delays' and 'Hints_delays-'.
> The documentation should be fixed by removing the extra 's' in Hints to match 
> it with code.
> The Jira for adding hint_delays: CASSANDRA-13234 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Issue Comment Deleted] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric

2019-02-20 Thread Anup Shirolkar (JIRA)


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

Anup Shirolkar updated CASSANDRA-15015:
---
Comment: was deleted

(was: Submitting a patch for documentation fix)

> Cassandra metrics documentation is not correct for Hint_delays metric
> -
>
> Key: CASSANDRA-15015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15015
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Blog
>Reporter: Anup Shirolkar
>Assignee: Anup Shirolkar
>Priority: Minor
>  Labels: documentation, easyfix, low-hanging-fruit
> Fix For: 3.0.19, 3.11.5, 4.0
>
> Attachments: 150150-trunk.txt
>
>
> The Cassandra metrics for hint delays are not correctly referred on the 
> documentation web page: 
> [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics]
>  
> The metrics are defined in the 
> [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52]
>  as 'Hint_delays' and 'Hint_delays-' but those are listed on the 
> website as 'Hints_delays' and 'Hints_delays-'.
> The documentation should be fixed by removing the extra 's' in Hints to match 
> it with code.
> The Jira for adding hint_delays: CASSANDRA-13234 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric

2019-02-20 Thread Anup Shirolkar (JIRA)


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

Anup Shirolkar updated CASSANDRA-15015:
---
Attachment: 150150-trunk.txt
Status: Patch Available  (was: Open)

> Cassandra metrics documentation is not correct for Hint_delays metric
> -
>
> Key: CASSANDRA-15015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15015
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Blog
>Reporter: Anup Shirolkar
>Assignee: Anup Shirolkar
>Priority: Minor
>  Labels: documentation, easyfix, low-hanging-fruit
> Fix For: 3.0.19, 3.11.5, 4.0
>
> Attachments: 150150-trunk.txt
>
>
> The Cassandra metrics for hint delays are not correctly referred on the 
> documentation web page: 
> [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics]
>  
> The metrics are defined in the 
> [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52]
>  as 'Hint_delays' and 'Hint_delays-' but those are listed on the 
> website as 'Hints_delays' and 'Hints_delays-'.
> The documentation should be fixed by removing the extra 's' in Hints to match 
> it with code.
> The Jira for adding hint_delays: CASSANDRA-13234 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-14482) ZSTD Compressor support in Cassandra

2019-02-20 Thread Blake Eggleston (JIRA)


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

Blake Eggleston commented on CASSANDRA-14482:
-

[~djoshi3], I pushed up a commit 
[here|https://github.com/bdeggleston/cassandra/commit/716a6b631d68532773bb804e8ce33ab3dd23946c]
 that makes the following changes:

1. simplifies {{ZstdCompressor#compress}} method to just call 
{{Zstd#compress}}. The compressor doesn't support on heap buffers so there's no 
need to do the stream stuff. This is basically how the snappy compressor works.
 2. updates test support method visibility/annotation in ZstdCompressor
 3. adds ratio to CompressorPerformance output

If you're ok with these changes and I haven't broken the tests, I think this is 
ready to commit.

> ZSTD Compressor support in Cassandra
> 
>
> Key: CASSANDRA-14482
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14482
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Dependencies, Feature/Compression
>Reporter: Sushma A Devendrappa
>Assignee: Dinesh Joshi
>Priority: Major
>  Labels: performance, pull-request-available
> Fix For: 4.x
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> ZStandard has a great speed and compression ratio tradeoff. 
> ZStandard is open source compression from Facebook.
> More about ZSTD
> [https://github.com/facebook/zstd]
> https://code.facebook.com/posts/1658392934479273/smaller-and-faster-data-compression-with-zstandard/
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-15020) Invalid CQL in documentation

2019-02-20 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-15020:
-
Reviewer: Nate McCall

> Invalid CQL in documentation
> 
>
> Key: CASSANDRA-15020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15020
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation/Website
>Reporter: Liudmila Kornilova
>Assignee: C. Scott Andreas
>Priority: Trivial
> Attachments: CASSANDRA-15020-3.0.patch, 
> CASSANDRA-15020-trunk-3.11.patch
>
>
>  [http://cassandra.apache.org/doc/4.0/cql/security.html]
> 1.
> Wrong:
> CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER;
>  CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true 
> AND SUPERUSER = true;
> Correct:
> CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER;
> CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = 
> true AND SUPERUSER = true; 
>  
> 2. 
>  Wrong:
> CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true;
> CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true;
> Correct:
> CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true;
> CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true;
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4

2019-02-20 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-9384:
-

For trunk -

 # Abort start up if {{auth_bcrypt_gensalt_log2_rounds = 31}}
 # Upgrade the jbcrypt binary

For versions other than trunk (Approach 1) -

 # Abort start up if {{auth_bcrypt_gensalt_log2_rounds = 31}}
 # Upgrade the jbcrypt binary

With this approach, the operator will have to reduce 
{{auth_bcrypt_gensalt_log2_rounds}} before they upgrade C*.

For versions other than trunk (Approach 2) -

# Abort start up if {{auth_bcrypt_gensalt_log2_rounds = 31}}
# Allow operator to start C* with {{auth_bcrypt_gensalt_log2_rounds = 31}} if 
they pass in {{-Dcassandra.allow_unsafe_bcrypt}}
# Don't upgrade the jbcrypt binary

Any preferences for which of the two approaches we should use for non-trunk 
versions?



> Update jBCrypt dependency to version 0.4
> 
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4

2019-02-20 Thread Ariel Weisberg (JIRA)


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

Ariel Weisberg commented on CASSANDRA-9384:
---

I am also in favor of failing at startup in this case for the reasons Jeff and 
Dinesh mentioned.

> Update jBCrypt dependency to version 0.4
> 
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4

2019-02-20 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa commented on CASSANDRA-9384:
---

I think failing to start is the right thing here.



> Update jBCrypt dependency to version 0.4
> 
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4

2019-02-20 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-9384:
-

[~jjirsa] I assume that people actually test new versions of C* before they 
deploy them in prod. With my approach, the newly updated instance will fail to 
come up with the bad setting. Hopefully the bounce will stop before it takes 
down the whole cluster. This is how I would expect bounces to behave. At this 
point I'd expect the operator to look into why C* failed to start and notice 
the error message and do a deeper investigation to fix their issue or add the 
override and move on. This should happen in a dev or test environment. Not prod.

Consider the alternative where someone misses the warning message and doesn't 
read CHANGES.txt. They might get exploited because these messages went 
unnoticed. There is a higher chance of this making it into production without 
an incident. As an operator I would like security vulnerabilities fixed with a 
new releases and not just some log messages warning me that it exists.

We can go with [~spo...@gmail.com]'s approach but I feel subtle failure is 
worse than explicit failure at start time.

> Update jBCrypt dependency to version 0.4
> 
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4

2019-02-20 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa commented on CASSANDRA-9384:
---

Think about this from the user side -

- Someone's going to bounce. 
- They may or may not see the logs.
- If they had rounds=31, the password hashes arent going to match
- Newly bounced hosts will reject new connections, but the app will keep 
working for a while. 
- All the connections will stack up on the unbounced hosts until they're 
overloaded
- Eventually the cluster will tip due to concentrating connections on a few 
coordinators OR you'll eventually cause an outage due to removing all 
coordinators with working auth.

That's not a great user story. 



> Update jBCrypt dependency to version 0.4
> 
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4

2019-02-20 Thread Stefan Podkowinski (JIRA)


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

Stefan Podkowinski commented on CASSANDRA-9384:
---

We don't need to "grab attention" by having C* fail to start. We should put 
whats important for upgrades into NEWS.txt. So how about having that warning 
message and put a notice there, saying something like "check your log2_rounds 
settings if you're seeing the following message during startup". The user can 
then deliberately make the decision to change or ignore the setting. 

> Update jBCrypt dependency to version 0.4
> 
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Comment Edited] (CASSANDRA-14983) Local reads potentially blocking remote reads

2019-02-20 Thread Marcus Olsson (JIRA)


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

Marcus Olsson edited comment on CASSANDRA-14983 at 2/20/19 6:26 PM:


I created CASSANDRA-15022 for the SEP executor and have uploaded some patches 
for 3.0, 3.11 and 4.0:
|[3.0|https://github.com/emolsson/cassandra/tree/3.0-CASSANDRA-14983]|[unit 
tests|https://circleci.com/gh/emolsson/cassandra/13]|
|[3.11|https://github.com/emolsson/cassandra/tree/3.11-CASSANDRA-14983]|[unit 
tests|https://circleci.com/gh/emolsson/cassandra/16]|
|[4.0|https://github.com/emolsson/cassandra/tree/4.0-CASSANDRA-14983]|[unit 
tests|https://circleci.com/gh/emolsson/cassandra/19]|

I seem to be having some issues running the tests on 4.0 though. When I tried 
to run the tests on a clean trunk branch locally I got similar issues as the 
ones in the build. But the 3.0 and 3.11 branches seems to pass the unit tests.

A note for the 4.0 patch is that all requests are still performed as full data 
requests. My understanding is that digest request are primarily used to avoid 
sending large amounts of data over the network. If we always perform data 
requests locally we might however keep multiple copies of the data in memory if 
we send data requests to remote nodes as well. If we want to change that 
behavior I think it should be in a separate JIRA ticket.

I also looked into the transient requests and I don't think anything would 
change from a logic perspective by executing the local request as a transient 
request as it is right now. Responses seems to be considered transient by 
checking the replica plan rather than the response. The 
ReadCommand#acceptsTransient()-method only seems to be used for validation 
before starting to execute the request and not affecting the actual request. 
Basically I don't think this is causing us any bugs right now. With that said I 
think the transient status should be kept even for local requests, at least 
from a correctness perspective. WDYT, should the local request be converted to 
a transient request when that is the case?

–

I also looked at the distributed tests but I'm not sure how to delay or lose 
the local requests in a good way without changing the actual code base. Do you 
know of a good place on the nodes read path to hook in to and delay it - I 
can't seem to find any?


was (Author: molsson):
I created CASSANDRA-15022 for the SEP executor and have uploaded some patches 
for 3.0, 3.11 and 4.0:

|[3.0|https://github.com/emolsson/cassandra/tree/3.0-CASSANDRA-14983]|[unit 
tests|https://circleci.com/gh/emolsson/cassandra/13]|
|[3.11|https://github.com/emolsson/cassandra/tree/3.11-CASSANDRA-14983]|[unit 
tests|https://circleci.com/gh/emolsson/cassandra/16]|
|[4.0|https://github.com/emolsson/cassandra/tree/4.0-CASSANDRA-14983]|[unit 
tests|https://circleci.com/gh/emolsson/cassandra/19]|

I seem to be having some issues running the tests on 4.0 though. When I tried 
to run the tests on a clean trunk branch locally I got similar issues as the 
ones in the build. But the 3.0 and 3.11 branches seems to pass the unit tests.

I also looked at the distributed tests but I'm not sure how to delay or lose 
the local requests in a good way without changing the actual code base.

> Local reads potentially blocking remote reads
> -
>
> Key: CASSANDRA-14983
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14983
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Coordination
>Reporter: Marcus Olsson
>Priority: Minor
> Attachments: graph_local_read.html, graph_local_read_trunk.html, 
> local_read_trace.log
>
>
> Since CASSANDRA-4718 there is a fast path allowing local requests to continue 
> to [work in the same 
> thread|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/reads/AbstractReadExecutor.java#L157]
>  rather than being sent over to the read stage.
> Based on the comment
> {code:java}
> // We delay the local (potentially blocking) read till the end to avoid 
> stalling remote requests.
> {code}
> it seems like this should be performed last in the chain to avoid blocking 
> remote requests but that does not seem to be the case when the local request 
> is a data request. The digest request(s) are sent after the data requests are 
> sent (and now the transient replica requests as well). When the fast path is 
> used for local data/transient data requests this will block the next type of 
> request from being sent away until the local read is finished and add 
> additional latency to the request.
> In addition to this it seems like local requests are *always* data requests 
> (might not be a problem), but the log message can say either ["digest" or 
> 

[jira] [Commented] (CASSANDRA-14983) Local reads potentially blocking remote reads

2019-02-20 Thread Marcus Olsson (JIRA)


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

Marcus Olsson commented on CASSANDRA-14983:
---

I created CASSANDRA-15022 for the SEP executor and have uploaded some patches 
for 3.0, 3.11 and 4.0:

|[3.0|https://github.com/emolsson/cassandra/tree/3.0-CASSANDRA-14983]|[unit 
tests|https://circleci.com/gh/emolsson/cassandra/13]|
|[3.11|https://github.com/emolsson/cassandra/tree/3.11-CASSANDRA-14983]|[unit 
tests|https://circleci.com/gh/emolsson/cassandra/16]|
|[4.0|https://github.com/emolsson/cassandra/tree/4.0-CASSANDRA-14983]|[unit 
tests|https://circleci.com/gh/emolsson/cassandra/19]|

I seem to be having some issues running the tests on 4.0 though. When I tried 
to run the tests on a clean trunk branch locally I got similar issues as the 
ones in the build. But the 3.0 and 3.11 branches seems to pass the unit tests.

I also looked at the distributed tests but I'm not sure how to delay or lose 
the local requests in a good way without changing the actual code base.

> Local reads potentially blocking remote reads
> -
>
> Key: CASSANDRA-14983
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14983
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Coordination
>Reporter: Marcus Olsson
>Priority: Minor
> Attachments: graph_local_read.html, graph_local_read_trunk.html, 
> local_read_trace.log
>
>
> Since CASSANDRA-4718 there is a fast path allowing local requests to continue 
> to [work in the same 
> thread|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/reads/AbstractReadExecutor.java#L157]
>  rather than being sent over to the read stage.
> Based on the comment
> {code:java}
> // We delay the local (potentially blocking) read till the end to avoid 
> stalling remote requests.
> {code}
> it seems like this should be performed last in the chain to avoid blocking 
> remote requests but that does not seem to be the case when the local request 
> is a data request. The digest request(s) are sent after the data requests are 
> sent (and now the transient replica requests as well). When the fast path is 
> used for local data/transient data requests this will block the next type of 
> request from being sent away until the local read is finished and add 
> additional latency to the request.
> In addition to this it seems like local requests are *always* data requests 
> (might not be a problem), but the log message can say either ["digest" or 
> "data"|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/reads/AbstractReadExecutor.java#L156]
>  as the type of request.
> I have tried to run performance measurements to see the impact of this in 3.0 
> (by moving local requests to the end of ARE#executeAsync()) but I haven't 
> seen any big difference yet. I'll continue to run some more tests to see if I 
> can find a use case affected by this.
> Attaching a trace (3.0) where this happens. Reproduction:
>  # Create a three node CCM cluster
>  # Provision data with stress (rf=3)
>  # In parallel:
>  ## Start stress read run
>  ## Run multiple manual read queries in cqlsh with tracing on and 
> local_quorum (as this does not always happen)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4

2019-02-20 Thread Dinesh Joshi (JIRA)


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

Dinesh Joshi commented on CASSANDRA-9384:
-

Rethinking this for existing releases, I wouldn't want C* to start up with the 
vulnerable setting. Normally, people don't pay attention to "WARN" messages and 
C* generates so many log entries at start up that it is hard for an operator to 
decide which ones they should be really concerned about.

For versions other than trunk, here's what I prefer -

 # Abort start up if {{auth_bcrypt_gensalt_log2_rounds = 31}}
 # Allow operator to start C* with {{auth_bcrypt_gensalt_log2_rounds = 31}} if 
they pass in {{-Dcassandra.allow_unsafe_bcrypt}}
 # Don't upgrade the jbcrypt binary

That way the operator has a way to use the old behavior but at least it grabs 
their attention. We're technically backward compatible and not breaking anybody 
except that now they have to consciously choose the bad setting. This should 
not affect most users. Thoughts?

> Update jBCrypt dependency to version 0.4
> 
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-15027) Handle IR prepare phase failures less race prone by waiting for all results

2019-02-20 Thread Blake Eggleston (JIRA)


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

Blake Eggleston updated CASSANDRA-15027:

Reviewer: Blake Eggleston

> Handle IR prepare phase failures less race prone by waiting for all results
> ---
>
> Key: CASSANDRA-15027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15027
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair, Local/Compaction
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
> Fix For: 4.x
>
>
> Handling incremental repairs as a coordinator begins by sending a 
> {{PrepareConsistentRequest}} message to all participants, which may also 
> include the coordinator itself. Participants will run anti-compactions upon 
> receiving such a message and report the result of the operation back to the 
> coordinator.
> Once we receive a failure response from any of the participants, we fail-fast 
> in {{CoordinatorSession.handlePrepareResponse()}}, which will in turn 
> completes the {{prepareFuture}} that {{RepairRunnable}} is blocking on. Then 
> the repair command will terminate with an error status, as expected.
> The issue is that in case the node will both be coordinator and participant, 
> we may end up with a local session and submitted anti-compactions, which will 
> be executed without any coordination with the coordinator session (on same 
> node). This may result in situations where running repair commands right 
> after another, may cause overlapping execution of anti-compactions that will 
> cause the following (misleading) message to show up in the logs and will 
> cause the repair to fail again:
>  "Prepare phase for incremental repair session %s has failed because it 
> encountered intersecting sstables belonging to another incremental repair 
> session (%s). This is by starting an incremental repair session before a 
> previous one has completed. Check nodetool repair_admin for hung sessions and 
> fix them."



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-15005) Configurable whilelist for UDFs

2019-02-20 Thread A. Soroka (JIRA)


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

A. Soroka commented on CASSANDRA-15005:
---

Hi, [~jmeredithco], thanks very much for checking in!

Do I understand the distinction you're making to be that between:
 # UDFs, for which C* is responsible for parsing syntax, developing JVM 
bytecode, and distributing the resulting executable function, and
 # functions-via-distributed-JARs, in which the _client_ is responsible for all 
of those things, and the CQL end of things would just entail a mapping between 
a fresh CQL function name and a Java method reference (or something like that) ?

If so, then definitely yes, the latter would resolve my use case deliciously. 
I'm after the ability to distribute lightweight computations next to my data, 
and I'm happy to organize the management of that process from the client-side; 
I don't need or even want to make C* do that work for me.

Did I understand you correctly (I hope!)?

> Configurable whilelist for UDFs
> ---
>
> Key: CASSANDRA-15005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15005
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Interpreter
>Reporter: A. Soroka
>Priority: Minor
>
> I would like to use the UDF system to distribute some simple calculations on 
> values. For some use cases, this would require access only to some Java API 
> classes that aren't on the (hardcoded) whitelist (e.g. 
> {{java.security.MessageDigest}}). In other cases, it would require access to 
> a little non-C* library code, pre-distributed to nodes by out-of-band means.
> As I understand the situation now, the whitelist for types UDFs can use is 
> hardcoded in java in 
> [UDFunction|[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/UDFunction.java#L99].]
> This ticket, then, is a request for a facility that would allow that list to 
> be extended via some kind of deployment-time configuration. I realize that 
> serious security concerns immediately arise for this kind of functionality, 
> but I hope that by restricting it (only used during startup, no exposing the 
> whitelist for introspection, etc.) it could be quite practical.
> I'd like very much to assist with this ticket if it is accepted. (I believe I 
> have sufficient Java skill to do that, but no real familiarity with C*'s 
> codebase, yet. :) )



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4

2019-02-20 Thread Jeff Jirsa (JIRA)


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

Jeff Jirsa commented on CASSANDRA-9384:
---

More from the peanut gallery: can we fix this line, which is just generally 
poor and confusing grammar:

https://github.com/dineshjoshi/cassandra/blob/18adf79e8b53bf38ce751362b98e02b72e690a11/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java#L64



> Update jBCrypt dependency to version 0.4
> 
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4

2019-02-20 Thread Jon Meredith (JIRA)


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

Jon Meredith commented on CASSANDRA-9384:
-

Small patches get the most comments...

For the trunk patch, what do you think about adding a 'Please recreate user 
passwords after changing this setting' to the log message, there's very little 
documentation about the setting and it might save somebody wondering why 
everything is broken after an upgrade.

For the 2.1 patch, I agree bcrypt shouldn't be updated.  What do you think 
about changing the log message to

logger.warn("!!! IMPORTANT !!! ...")

Otherwise they'll get a WARN  !!! WARNING  message

> Update jBCrypt dependency to version 0.4
> 
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-14848) When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes

2019-02-20 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas updated CASSANDRA-14848:
-
Status: In Progress  (was: Ready to Commit)

> When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non 
> seed nodes
> -
>
> Key: CASSANDRA-14848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14848
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Blocker
>  Labels: security
> Fix For: 4.0
>
>
> When upgrading from 3.11.3 to 4.0 with server encryption enabled the new 4.0 
> node only connects to 3.11.3 seed node, there are no connection established 
> to non-seed nodes on the old version.
> I have four nodes, *.242 is upgraded to 4.0, *.243 and *.244 are 3.11.3 
> non-seed and *.246 are 3.11.3 seed. After starting the 4.0 node I get this 
> nodetool status on the different nodes:
> {noformat}
> *.242
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 1017.77 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> DN 10.216.193.243 743.32 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 
> RAC1
> DN 10.216.193.244 711.54 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 659.81 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> *.243 and *.244
> -- Address Load Tokens Owns (effective) Host ID Rack
> DN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> *.246
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> {noformat}
>  
> I have built 4.0 with wire tracing activated and in my config the 
> storage_port=12700 and ssl_storage_port=12701. In the log I can see that the 
> 4.0 node start to connect to the 3.11.3 seed node on the storage_port but 
> quickly switch to the ssl_storage_port, but when connecting to the non-seed 
> nodes it never switch to the ssl_storage_port.
> {noformat}
> >grep 193.246 system.log | grep Outbound
> 2018-10-25T10:57:36.799+0200 [MessagingService-NettyOutbound-Thread-4-1] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x2f0e5e55] CONNECT: 
> /10.216.193.246:12700
> 2018-10-25T10:57:36.902+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c] CONNECT: 
> /10.216.193.246:12701
> 2018-10-25T10:57:36.905+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c, 
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] ACTIVE
> 2018-10-25T10:57:36.906+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c, 
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] WRITE: 8B
> >grep 193.243 system.log | grep Outbound
> 2018-10-25T10:57:38.438+0200 [MessagingService-NettyOutbound-Thread-4-3] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xd8f1d6c4] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.540+0200 [MessagingService-NettyOutbound-Thread-4-4] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xfde6cc9f] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.694+0200 [MessagingService-NettyOutbound-Thread-4-5] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x7e87fc4e] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.741+0200 [MessagingService-NettyOutbound-Thread-4-7] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x39395296] CONNECT: 
> /10.216.193.243:12700{noformat}
>  
> When I had the dbug log activated and started the 4.0 node I can see that it 
> switch port for *.246 but not for *.243 and *.244.
> {noformat}
> >grep DEBUG system.log| grep OutboundMessagingConnection | grep 
> >maybeUpdateConnectionId
> 2018-10-25T13:12:56.095+0200 [ScheduledFastTasks:1] DEBUG 
> o.a.c.n.a.OutboundMessagingConnection:314 maybeUpdateConnectionId changing 
> connectionId to 10.216.193.246:12701 (GOSSIP), with a different port for 
> secure communication, because peer version is 11
> 2018-10-25T13:12:58.100+0200 

[jira] [Comment Edited] (CASSANDRA-14848) When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes

2019-02-20 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas edited comment on CASSANDRA-14848 at 2/20/19 4:14 PM:
---

It looks like an anonymous user modified the state of this ticket to "Ready to 
Commit" yesterday. Moving back to "In Progress" because I don't see a reviewer 
assigned.


was (Author: cscotta):
It looks like an anonymous user modified the state of this ticket to "Ready to 
Commit" yesterday. Moving back to "Patch Available" because I don't see a 
reviewer assigned.

> When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non 
> seed nodes
> -
>
> Key: CASSANDRA-14848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14848
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Blocker
>  Labels: security
> Fix For: 4.0
>
>
> When upgrading from 3.11.3 to 4.0 with server encryption enabled the new 4.0 
> node only connects to 3.11.3 seed node, there are no connection established 
> to non-seed nodes on the old version.
> I have four nodes, *.242 is upgraded to 4.0, *.243 and *.244 are 3.11.3 
> non-seed and *.246 are 3.11.3 seed. After starting the 4.0 node I get this 
> nodetool status on the different nodes:
> {noformat}
> *.242
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 1017.77 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> DN 10.216.193.243 743.32 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 
> RAC1
> DN 10.216.193.244 711.54 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 659.81 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> *.243 and *.244
> -- Address Load Tokens Owns (effective) Host ID Rack
> DN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> *.246
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> {noformat}
>  
> I have built 4.0 with wire tracing activated and in my config the 
> storage_port=12700 and ssl_storage_port=12701. In the log I can see that the 
> 4.0 node start to connect to the 3.11.3 seed node on the storage_port but 
> quickly switch to the ssl_storage_port, but when connecting to the non-seed 
> nodes it never switch to the ssl_storage_port.
> {noformat}
> >grep 193.246 system.log | grep Outbound
> 2018-10-25T10:57:36.799+0200 [MessagingService-NettyOutbound-Thread-4-1] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x2f0e5e55] CONNECT: 
> /10.216.193.246:12700
> 2018-10-25T10:57:36.902+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c] CONNECT: 
> /10.216.193.246:12701
> 2018-10-25T10:57:36.905+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c, 
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] ACTIVE
> 2018-10-25T10:57:36.906+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c, 
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] WRITE: 8B
> >grep 193.243 system.log | grep Outbound
> 2018-10-25T10:57:38.438+0200 [MessagingService-NettyOutbound-Thread-4-3] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xd8f1d6c4] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.540+0200 [MessagingService-NettyOutbound-Thread-4-4] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xfde6cc9f] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.694+0200 [MessagingService-NettyOutbound-Thread-4-5] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x7e87fc4e] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.741+0200 [MessagingService-NettyOutbound-Thread-4-7] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x39395296] CONNECT: 
> /10.216.193.243:12700{noformat}
>  
> When I had the dbug log activated and started the 4.0 node I can see that it 
> switch port for *.246 but not for *.243 and *.244.

[jira] [Commented] (CASSANDRA-14848) When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes

2019-02-20 Thread C. Scott Andreas (JIRA)


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

C. Scott Andreas commented on CASSANDRA-14848:
--

It looks like an anonymous user modified the state of this ticket to "Ready to 
Commit" yesterday. Moving back to "Patch Available" because I don't see a 
reviewer assigned.

> When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non 
> seed nodes
> -
>
> Key: CASSANDRA-14848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14848
> Project: Cassandra
>  Issue Type: Bug
>  Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Blocker
>  Labels: security
> Fix For: 4.0
>
>
> When upgrading from 3.11.3 to 4.0 with server encryption enabled the new 4.0 
> node only connects to 3.11.3 seed node, there are no connection established 
> to non-seed nodes on the old version.
> I have four nodes, *.242 is upgraded to 4.0, *.243 and *.244 are 3.11.3 
> non-seed and *.246 are 3.11.3 seed. After starting the 4.0 node I get this 
> nodetool status on the different nodes:
> {noformat}
> *.242
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 1017.77 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> DN 10.216.193.243 743.32 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 
> RAC1
> DN 10.216.193.244 711.54 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 659.81 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> *.243 and *.244
> -- Address Load Tokens Owns (effective) Host ID Rack
> DN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> *.246
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4 
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6 
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291 
> RAC1
> {noformat}
>  
> I have built 4.0 with wire tracing activated and in my config the 
> storage_port=12700 and ssl_storage_port=12701. In the log I can see that the 
> 4.0 node start to connect to the 3.11.3 seed node on the storage_port but 
> quickly switch to the ssl_storage_port, but when connecting to the non-seed 
> nodes it never switch to the ssl_storage_port.
> {noformat}
> >grep 193.246 system.log | grep Outbound
> 2018-10-25T10:57:36.799+0200 [MessagingService-NettyOutbound-Thread-4-1] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x2f0e5e55] CONNECT: 
> /10.216.193.246:12700
> 2018-10-25T10:57:36.902+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c] CONNECT: 
> /10.216.193.246:12701
> 2018-10-25T10:57:36.905+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c, 
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] ACTIVE
> 2018-10-25T10:57:36.906+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c, 
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] WRITE: 8B
> >grep 193.243 system.log | grep Outbound
> 2018-10-25T10:57:38.438+0200 [MessagingService-NettyOutbound-Thread-4-3] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xd8f1d6c4] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.540+0200 [MessagingService-NettyOutbound-Thread-4-4] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xfde6cc9f] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.694+0200 [MessagingService-NettyOutbound-Thread-4-5] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x7e87fc4e] CONNECT: 
> /10.216.193.243:12700
> 2018-10-25T10:57:38.741+0200 [MessagingService-NettyOutbound-Thread-4-7] INFO 
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x39395296] CONNECT: 
> /10.216.193.243:12700{noformat}
>  
> When I had the dbug log activated and started the 4.0 node I can see that it 
> switch port for *.246 but not for *.243 and *.244.
> {noformat}
> >grep DEBUG system.log| grep OutboundMessagingConnection | grep 
> >maybeUpdateConnectionId
> 2018-10-25T13:12:56.095+0200 [ScheduledFastTasks:1] DEBUG 
> o.a.c.n.a.OutboundMessagingConnection:314 maybeUpdateConnectionId 

[jira] [Commented] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4

2019-02-20 Thread Stefan Podkowinski (JIRA)


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

Stefan Podkowinski commented on CASSANDRA-9384:
---

The bcrypt dependency should not be updated in any version but trunk in that 
case. The idea is to give users time to migrate to the new setting, without 
causing an incident during upgrades.

> Update jBCrypt dependency to version 0.4
> 
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org