[jira] [Commented] (CASSANDRA-14153) BloomFilterTest generates un-deleted test file
[ https://issues.apache.org/jira/browse/CASSANDRA-14153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315544#comment-16315544 ] Jay Zhuang commented on CASSANDRA-14153: | Branch | uTest | | [14153-trunk|https://github.com/cooldoger/cassandra/tree/14153-trunk] | [!https://circleci.com/gh/cooldoger/cassandra/tree/14153-trunk.svg?style=svg!|https://circleci.com/gh/cooldoger/cassandra/tree/14153-trunk] | > BloomFilterTest generates un-deleted test file > -- > > Key: CASSANDRA-14153 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14153 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Jay Zhuang >Assignee: Jay Zhuang >Priority: Minor > Labels: testing > > https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/utils/BloomFilterTest.java#L196 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14153) BloomFilterTest generates un-deleted test file
[ https://issues.apache.org/jira/browse/CASSANDRA-14153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Zhuang updated CASSANDRA-14153: --- Status: Patch Available (was: Open) > BloomFilterTest generates un-deleted test file > -- > > Key: CASSANDRA-14153 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14153 > Project: Cassandra > Issue Type: Test > Components: Testing >Reporter: Jay Zhuang >Assignee: Jay Zhuang >Priority: Minor > Labels: testing > > https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/utils/BloomFilterTest.java#L196 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14153) BloomFilterTest generates un-deleted test file
Jay Zhuang created CASSANDRA-14153: -- Summary: BloomFilterTest generates un-deleted test file Key: CASSANDRA-14153 URL: https://issues.apache.org/jira/browse/CASSANDRA-14153 Project: Cassandra Issue Type: Test Components: Testing Reporter: Jay Zhuang Assignee: Jay Zhuang Priority: Minor https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/utils/BloomFilterTest.java#L196 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14152) Remove unused on-heap BloomFilter implementation
[ https://issues.apache.org/jira/browse/CASSANDRA-14152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Zhuang updated CASSANDRA-14152: --- Status: Awaiting Feedback (was: Open) > Remove unused on-heap BloomFilter implementation > > > Key: CASSANDRA-14152 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14152 > Project: Cassandra > Issue Type: Improvement >Reporter: Jay Zhuang >Priority: Minor > > Seems like it's just dead code, should that be removed? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14152) Remove unused on-heap BloomFilter implementation
[ https://issues.apache.org/jira/browse/CASSANDRA-14152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Zhuang updated CASSANDRA-14152: --- Description: Seems like it's just dead code, should that be removed? (was: Seems like it's just dead code.) > Remove unused on-heap BloomFilter implementation > > > Key: CASSANDRA-14152 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14152 > Project: Cassandra > Issue Type: Improvement >Reporter: Jay Zhuang >Priority: Minor > > Seems like it's just dead code, should that be removed? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9067) BloomFilter serialization format should not change byte ordering
[
https://issues.apache.org/jira/browse/CASSANDRA-9067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315523#comment-16315523
]
Jay Zhuang commented on CASSANDRA-9067:
---
Seems the byte re-ordering is because it needs to backward compatible with the
older on-heap BloomFilter file. Removing that does improve the performance:
[9067-test|https://github.com/cooldoger/cassandra/tree/9067-test]
Here is the microbench test result before and after the test (The test {{[Add
bf bench
test|https://github.com/cooldoger/cassandra/commit/0e82a30e852279176e78f036b07a7000cf6f7e12]}}
basically serialize and deserialize a BF with {{numElemsInK}} elements):
{noformat}
NoFix:
[java] Benchmark (numElemsInK) Mode
Cnt Score Error Units
[java] BloomFilterSerializerBench.serializationTest 10 avgt
4 1863.613 ± 286.654 us/op
[java] BloomFilterSerializerBench.serializationTest100 avgt
4 15027.986 ±1021.473 us/op
[java] BloomFilterSerializerBench.serializationTest 1024 avgt
4143462.679 ±4833.878 us/op
[java] BloomFilterSerializerBench.serializationTest 10240 avgt
4 1413625.791 ± 72691.584 us/op
[java] BloomFilterSerializerBench.serializationTest 102400 avgt
4 14219387.793 ± 1243380.279 us/op
WithFix:
[java] Benchmark (numElemsInK) Mode
CntScore Error Units
[java] BloomFilterSerializerBench.serializationTest 10 avgt
4 609.689 ± 312.061 us/op
[java] BloomFilterSerializerBench.serializationTest100 avgt
4 2509.484 ±65.843 us/op
[java] BloomFilterSerializerBench.serializationTest 1024 avgt
421010.078 ± 4246.935 us/op
[java] BloomFilterSerializerBench.serializationTest 10240 avgt
4 203592.239 ± 28953.074 us/op
[java] BloomFilterSerializerBench.serializationTest 102400 avgt
4 2076461.208 ± 96848.833 us/op
{noformat}
For 10K elements, it has about 3 times improvement, for 100M, it's about 7
times.
But as the BloomFilter file doesn't have version support, how could we migrate
the existing format to the new one?
> BloomFilter serialization format should not change byte ordering
>
>
> Key: CASSANDRA-9067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9067
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Benedict
>Assignee: Jay Zhuang
>Priority: Minor
> Fix For: 4.x
>
>
> As a follow-up to CASSANDRA-9066 and CASSANDRA-9060, it appears we do some
> unnecessary byte swapping during the serialization of bloom filters, which
> makes the logic slower and harder to follow. We should either perform them
> more efficiently (using Long.reverseBytes) or, preferably, eliminate the
> conversion altogether since it does not appear to serve any purpose.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-9067) BloomFilter serialization format should not change byte ordering
[ https://issues.apache.org/jira/browse/CASSANDRA-9067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Zhuang updated CASSANDRA-9067: -- Status: Awaiting Feedback (was: Open) > BloomFilter serialization format should not change byte ordering > > > Key: CASSANDRA-9067 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9067 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict >Assignee: Jay Zhuang >Priority: Minor > Fix For: 4.x > > > As a follow-up to CASSANDRA-9066 and CASSANDRA-9060, it appears we do some > unnecessary byte swapping during the serialization of bloom filters, which > makes the logic slower and harder to follow. We should either perform them > more efficiently (using Long.reverseBytes) or, preferably, eliminate the > conversion altogether since it does not appear to serve any purpose. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12125) ERROR [MemtableFlushWriter:4] 2016-07-01 06:20:41,137 CassandraDaemon.java:185 - Exception in thread Thread[MemtableFlushWriter:4,5,main] java.lang.RuntimeExcepti
[
https://issues.apache.org/jira/browse/CASSANDRA-12125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315519#comment-16315519
]
Kurt Greaves commented on CASSANDRA-12125:
--
This could be fixed by CASSANDRA-12651, which was in 3.0.11 and 3.10. If you're
able to upgrade that may fix it.
> ERROR [MemtableFlushWriter:4] 2016-07-01 06:20:41,137
> CassandraDaemon.java:185 - Exception in thread
> Thread[MemtableFlushWriter:4,5,main] java.lang.RuntimeException: Last
> written key DecoratedKey(.XX, X) >= current key DecoratedKey
>
>
> Key: CASSANDRA-12125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12125
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: RHEL-6.5 64-bit Apache Cassandra 2.2.5v
>Reporter: Relish Chackochan
> Fix For: 2.2.x
>
>
> We are running on RHEL-6.5 64-bit with Apache Cassandra 2.2.5v on 4 node
> cluster and getting the following error on multiple node while running the
> repair job and when getting the error repair job is hang.
> Can some one help to identify the issue.
> {code}
> ERROR [MemtableFlushWriter:4] 2016-07-01 06:20:41,137
> CassandraDaemon.java:185 - Exception in thread
> Thread[MemtableFlushWriter:4,5,main]
> java.lang.RuntimeException: Last written key DecoratedKey(1467371986.8870,
> 313436373337313938362e38383730) >= current key DecoratedKey(,
> 313436373337323030312e38383730) writing into
> /opt/cassandra/data/proddb/log_data1-0a5092a0a4fa11e5872fc1ce0a46dc27/.maxdatetimeindex_idx/tmp-la-470-big-Data.db
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14152) Remove unused on-heap BloomFilter implementation
Jay Zhuang created CASSANDRA-14152: -- Summary: Remove unused on-heap BloomFilter implementation Key: CASSANDRA-14152 URL: https://issues.apache.org/jira/browse/CASSANDRA-14152 Project: Cassandra Issue Type: Improvement Reporter: Jay Zhuang Priority: Minor Seems like it's just dead code. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-9067) BloomFilter serialization format should not change byte ordering
[ https://issues.apache.org/jira/browse/CASSANDRA-9067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Zhuang reassigned CASSANDRA-9067: - Assignee: Jay Zhuang > BloomFilter serialization format should not change byte ordering > > > Key: CASSANDRA-9067 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9067 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict >Assignee: Jay Zhuang >Priority: Minor > Fix For: 4.x > > > As a follow-up to CASSANDRA-9066 and CASSANDRA-9060, it appears we do some > unnecessary byte swapping during the serialization of bloom filters, which > makes the logic slower and harder to follow. We should either perform them > more efficiently (using Long.reverseBytes) or, preferably, eliminate the > conversion altogether since it does not appear to serve any purpose. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-14135) Problem with creating keyspace after drop
[ https://issues.apache.org/jira/browse/CASSANDRA-14135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mhanna Abu Tareef resolved CASSANDRA-14135. --- Resolution: Invalid > Problem with creating keyspace after drop > - > > Key: CASSANDRA-14135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14135 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Development > QA >Reporter: Mhanna Abu Tareef > Attachments: k2fabric.log.100, k2fabric.log.101, k2fabric.log.102, > k2fabric.log.103, k2fabric.log.98, k2fabric.log.99, no-keyspace-ondisk.png, > no_keyspace.png, schema_after_ks_creation.png, schema_before_ks_creation.png > > > I think i have the same issue in C* 3.11.1 > i have a multi-dc cluster > 6 nodes > 2 DCs > DC1 > 98 > 99 - seed > 100 > DC2 > 101 > 102 > 103 - seed > via cqlsh from 102 > 1. using a fresh cluster > 2. create keyspace k2view_functionslu > 3. create table > Works! > from node 98 > via cqlsh drop keyspace - succeded > now from node 102 > via cqlsh from 102 > 1. create keyspace k2view_functionslu > 2. create table => Keyspace k2view_functionslu doesn't exist > attacged logs from all nodes > attached schema version from all nodes > attached "desc keyspaces" > P.S I think this was already seen in older version > https://issues.apache.org/jira/browse/CASSANDRA-4219 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14135) Problem with creating keyspace after drop
[ https://issues.apache.org/jira/browse/CASSANDRA-14135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315130#comment-16315130 ] Mhanna Abu Tareef commented on CASSANDRA-14135: --- Hi Thanks for the reply. The problem was that the time was out of sync between the nodes > Problem with creating keyspace after drop > - > > Key: CASSANDRA-14135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14135 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Development > QA >Reporter: Mhanna Abu Tareef > Attachments: k2fabric.log.100, k2fabric.log.101, k2fabric.log.102, > k2fabric.log.103, k2fabric.log.98, k2fabric.log.99, no-keyspace-ondisk.png, > no_keyspace.png, schema_after_ks_creation.png, schema_before_ks_creation.png > > > I think i have the same issue in C* 3.11.1 > i have a multi-dc cluster > 6 nodes > 2 DCs > DC1 > 98 > 99 - seed > 100 > DC2 > 101 > 102 > 103 - seed > via cqlsh from 102 > 1. using a fresh cluster > 2. create keyspace k2view_functionslu > 3. create table > Works! > from node 98 > via cqlsh drop keyspace - succeded > now from node 102 > via cqlsh from 102 > 1. create keyspace k2view_functionslu > 2. create table => Keyspace k2view_functionslu doesn't exist > attacged logs from all nodes > attached schema version from all nodes > attached "desc keyspaces" > P.S I think this was already seen in older version > https://issues.apache.org/jira/browse/CASSANDRA-4219 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
