[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579966#comment-17579966 ] Alex Lourie commented on CASSANDRA-13010: - [~smiklosovic] Yea, go ahead, I don't plan to work on it. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction, Tool/nodetool >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Normal > Labels: 4.0-feature-freeze-review-requested, lhf > Attachments: cleanup.png, multiple operations.png > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13938) Default repair is broken, crashes other nodes participating in repair (in trunk)
[
https://issues.apache.org/jira/browse/CASSANDRA-13938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16658981#comment-16658981
]
Alex Lourie edited comment on CASSANDRA-13938 at 10/22/18 1:39 PM:
---
[~jasobrown] I've been testing both trunk and your branch in a simple repair
scenario and it's still failing. The scenario I'm working with is:
1. Start a cluster
2. Load the cluster for 10 minutes
3. Stop one node and load it for an additional 30 minutes
4. Clear the hints
5. Start the stopped node and let it resync with others for a couple of minutes.
6. Start the repairs on the previously stopped node.
Repairs crash on the other nodes (on 2 nodes in my 3-node test cluster) with
the following error:
{code}
Oct 22 13:10:54 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:10:54,716 Validator.java:417 - [repair
#9c38dd00-d5fb-11e8-ac32-316a9d8f8d32] Sending completed merkle tree to
35.162.15.68:7000 for alex.test2
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,594 StreamingRepairTask.java:72 - [streaming task
#9c38dd00-d5fb-11e8-ac32-316a9d8f8d32] Performing streaming repair of 7382
ranges with 35.162.15.68:7000
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,981 StreamResultFuture.java:89 - [Stream
#9fe63820-d5fc-11e8-8a2b-3555ba61a619] Executing streaming plan for Repair
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,981 StreamSession.java:287 - [Stream
#9fe63820-d5fc-11e8-8a2b-3555ba61a619] Starting streaming to 35.162.15.68:7000
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,987 StreamCoordinator.java:259 - [Stream
#9fe63820-d5fc-11e8-8a2b-3555ba61a619, ID#0] Beginning stream session with
35.162.15.68:7000
Oct 22 13:16:03 ip-10-0-13-111 cassandra[5927]: INFO
[Stream-Deserializer-35.162.15.68:7000-0b32ed63] 2018-10-22 13:16:03,783
StreamResultFuture.java:178 - [Stream #9fe63820-d5fc-11e8-8a2b-3555ba61a619
ID#0] Prepare completed. Receiving 6 files(215.878MiB), sending 17
files(720.317MiB)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: WARN
[Stream-Deserializer-35.162.15.68:60292-be7cb6ee] 2018-10-22 13:16:04,355
CassandraCompressedStreamReader.java:110 - [Stream
9fe63820-d5fc-11e8-8a2b-3555ba61a619] Error while reading partition
DecoratedKey(-9088115514873584734, 646572706865616435393632373436) from stream
on ks='alex' and table='test2'.
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: ERROR
[Stream-Deserializer-35.162.15.68:60292-be7cb6ee] 2018-10-22 13:16:04,362
StreamingInboundHandler.java:213 - [Stream channel: be7cb6ee] stream operation
from 35.162.15.68:60292 failed
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: java.lang.AssertionError:
stream can only read forward.
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.db.streaming.CompressedInputStream.position(CompressedInputStream.java:108)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:93)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:74)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:49)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:55)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:177)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
java.lang.Thread.run(Thread.java:748)
{code}
The data is created as follows:
{code:sql}
CREATE KEYSPACE IF NOT EXISTS alex with replication = { 'class':
'NetworkTopologyStrategy', 'alourie': 3 };
CREATE TABLE IF NOT EXISTS alex.test2 (
part text,
clus int,
[jira] [Commented] (CASSANDRA-13938) Default repair is broken, crashes other nodes participating in repair (in trunk)
[
https://issues.apache.org/jira/browse/CASSANDRA-13938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16658981#comment-16658981
]
Alex Lourie commented on CASSANDRA-13938:
-
[~jasobrown] I've been testing both trunk and your branch in a simple repair
scenario and it's still failing. The scenario I'm working with is:
1. Start a cluster
2. Load the cluster for 10 minutes
3. Stop one node and load it for an additional 30 minutes
4. Clear the hints
5. Start the stopped node and let it resync with others for a couple of minutes.
6. Start the repairs on the previously stopped node.
Repairs crash on the other nodes (on 2 nodes in my 3-node test cluster) with
the following error:
{code}
Oct 22 13:10:54 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:10:54,716 Validator.java:417 - [repair
#9c38dd00-d5fb-11e8-ac32-316a9d8f8d32] Sending completed merkle tree to
35.162.15.68:7000 for alex.test2
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,594 StreamingRepairTask.java:72 - [streaming task
#9c38dd00-d5fb-11e8-ac32-316a9d8f8d32] Performing streaming repair of 7382
ranges with 35.162.15.68:7000
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,981 StreamResultFuture.java:89 - [Stream
#9fe63820-d5fc-11e8-8a2b-3555ba61a619] Executing streaming plan for Repair
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,981 StreamSession.java:287 - [Stream
#9fe63820-d5fc-11e8-8a2b-3555ba61a619] Starting streaming to 35.162.15.68:7000
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,987 StreamCoordinator.java:259 - [Stream
#9fe63820-d5fc-11e8-8a2b-3555ba61a619, ID#0] Beginning stream session with
35.162.15.68:7000
Oct 22 13:16:03 ip-10-0-13-111 cassandra[5927]: INFO
[Stream-Deserializer-35.162.15.68:7000-0b32ed63] 2018-10-22 13:16:03,783
StreamResultFuture.java:178 - [Stream #9fe63820-d5fc-11e8-8a2b-3555ba61a619
ID#0] Prepare completed. Receiving 6 files(215.878MiB), sending 17
files(720.317MiB)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: WARN
[Stream-Deserializer-35.162.15.68:60292-be7cb6ee] 2018-10-22 13:16:04,355
CassandraCompressedStreamReader.java:110 - [Stream
9fe63820-d5fc-11e8-8a2b-3555ba61a619] Error while reading partition
DecoratedKey(-9088115514873584734, 646572706865616435393632373436) from stream
on ks='alex' and table='test2'.
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: ERROR
[Stream-Deserializer-35.162.15.68:60292-be7cb6ee] 2018-10-22 13:16:04,362
StreamingInboundHandler.java:213 - [Stream channel: be7cb6ee] stream operation
from 35.162.15.68:60292 failed
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: java.lang.AssertionError:
stream can only read forward.
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.db.streaming.CompressedInputStream.position(CompressedInputStream.java:108)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:93)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:74)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:49)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:55)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:177)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
java.lang.Thread.run(Thread.java:748)
{code}
The data is created as follows:
{code:cql}
CREATE KEYSPACE IF NOT EXISTS alex with replication = { 'class':
'NetworkTopologyStrategy', 'alourie': 3 };
CREATE TABLE IF NOT EXISTS alex.test2 (
part text,
clus int,
[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16658539#comment-16658539 ] Alex Lourie commented on CASSANDRA-13010: - [~rustyrazorblade] by "reviewed" I meant the output format, not the patch. I apologise, I thought I was clear in this regard. Also, it was not clear that the problem was this mixture of relative/absolute paths and not the format. I'll check the code again to make it include absolute paths only. Thanks! > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: 4.0-feature-freeze-review-requested, lhf > Attachments: cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16658497#comment-16658497 ] Alex Lourie commented on CASSANDRA-13010: - I believe that the output matches the request, and was reviewed more than once. Nevertheless, I'm ready to change it if required. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: 4.0-feature-freeze-review-requested, lhf > Attachments: cleanup.png, multiple operations.png > > -- 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-11559) Enhance node representation
[ https://issues.apache.org/jira/browse/CASSANDRA-11559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414721#comment-16414721 ] Alex Lourie edited comment on CASSANDRA-11559 at 6/28/18 4:55 AM: -- I've done some work on this ticket and it's available at [https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-11559#files_bucket]. Few pointers: * I've refactored InetAddressAndPort class into VirtualEndpoint class across all the codebase (this will be responsible for the majority of the code changes). * I've added a UUID field to hold the hostID value of the endpoint and added additional methods for working with it. * I've reworked the TokenMetadata to hold structures other than maps for UUID-host references and they would no longer be needed, i.e. keeping just a set of endpoints is enough to hold both address data and the hostID data and to also look up hosts by IDs or the vice versa. * I've reworked the SystemKeyspace to also acknowledge the hostIDs where significant (in local data/peer data storing/fetching), and also only create new local id if requested (in most cases only when the node is created for the first time, but also useful for tests that require initiating multiple "nodes" on the same machine) I've added a field in DatabaseDescriptor to mark that SystemKeyspace is ready to be read. This is required for many unit tests that set up clusters "on the fly" and for further endpoint information discovery during the test run. * I've updated required unit tests to properly utilise the new object and initialise and clean others as required. * I've updated the code in some other locations to incorporate this change, which does make it simpler on many occasions. The current state is everything _seems_ to be working and the unit tests pass ([https://circleci.com/gh/alourie/cassandra/123]) The complication that comes out of this work is with building unit tests - the host ID would now be kept in multiple structures: * a VirtualEndpoint object when instantiated. * SystemKeyspace.localHost (queries the DB) * SystemKeyspace.peersInfo (queries the DB) * TokenMetadata lists (such as allEndpoints, tokenMap, etc) * Gossip.instance.endpointState maps (the specific endpoint is added including the uuid) * FBUtilities also keeps local reference once fetched As a result, when creating tests, one needs to update or clear the hostID-related information in all relevant places, otherwise, tests would fail with really confusing messages (in most cases because in some thread an endpoint comparison will happen and UUIDs won't match), such as "no seeds found", "host cannot be contacted" or various kinds of timeouts and NPEs. Additionally, when SystemKeyspace is ready to be read within a test flow, a DatabaseDescriptor.canReadSystemKeyspace field will need to be set to true so that the UUID would be fetched from SystemKeyspace. Additionally, at the moment we are keeping EndpointState separately from this object (in Gossip). Considering that now this VirtualEndpoint can include basically any information about the endpoint, it may as well incorporate its own state, and then all handling of the network/state information about an endpoint will be in one place. Supposedly this should simplify things further and allow clearing a lot of code. [~aweisberg] - you have done the previous move away from InetAddress representation to InetAddressAndPort, which this current patch changes considerably. I'd love your feedback on this. Any and all feedback is very welcome. was (Author: alourie): I've done some work on this ticket and it's available at [https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-11559#files_bucket]. Few pointers: * I've refactored InetAddressAndPort class into VirtualEndpoint class across all the codebase (this will be responsible for the majority of the code changes). * I've added a UUID field to hold the hostID value of the endpoint and added additional methods for working with it. * I've reworked the TokenMetadata to hold structures other than maps for UUID-host references and they would no longer be needed, i.e. keeping just a set of endpoints is enough to hold both address data and the hostID data and to also look up hosts by IDs or the vice versa. * I've reworked the SystemKeyspace to also acknowledge the hostIDs where significant (in local data/peer data storing/fetching), and also only create new local id if requested (in most cases only when the node is created for the first time, but also useful for tests that require initiating multiple "nodes" on the same machine) I've added a field in DatabaseDescriptor to mark that SystemKeyspace is ready to be read. This is required for many unit tests that set up clusters "on the fly" and for further endpoint information discovery during the test run. * I've updated
[jira] [Commented] (CASSANDRA-11559) Enhance node representation
[
https://issues.apache.org/jira/browse/CASSANDRA-11559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16525912#comment-16525912
]
Alex Lourie commented on CASSANDRA-11559:
-
[~bdeggleston] I've rebased the work on the recent trunk and changed the name
of the new object to Endpoint. Would love any other feedback if there's any.
[~aweisberg] If you have the time, I'd really appreciate your take on this.
> Enhance node representation
> ---
>
> Key: CASSANDRA-11559
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11559
> Project: Cassandra
> Issue Type: Sub-task
> Components: Distributed Metadata
>Reporter: Paulo Motta
>Assignee: Alex Lourie
>Priority: Minor
>
> We currently represent nodes as {{InetAddress}} objects on {{TokenMetadata}},
> what causes difficulties when replacing a node with the same address (see
> CASSANDRA-8523 and CASSANDRA-9244).
> Since CASSANDRA-4120 we index hosts by {{UUID}} in gossip, so I think it's
> time to move that representation to {{TokenMetadata}}.
> I propose representing nodes as {{InetAddress, UUID}} pairs on
> {{TokenMetadata}}, encapsulated in a {{VirtualNode}} interface, so it will
> backward compatible with the current representation, while still allowing us
> to enhance it in the future with additional metadata (and improved vnode
> handling) if needed.
> This change will probably affect interfaces of internal classes like
> {{TokenMetadata}} and {{AbstractReplicationStrategy}}, so I'd like to hear
> from integrators and other developers if it's possible to change these
> without major hassle or if we need to wait until 4.0.
> Besides updating {{TokenMetadata}} and {{AbstractReplicationStrategy}} (and
> subclasses), we will also need to replace all {{InetAddress}} uses with
> {{VirtualNode.getEndpoint()}} calls on {{StorageService}} and related classes
> and tests. We would probably already be able to replace some
> {{TokenMetadata.getHostId(InetAddress endpoint)}} calls with
> {{VirtualNode.getHostId()}}.
> While we will still be dealing with {{InetAddress}} on {{StorageService}} in
> this initial stage, in the future I think we should pass {{VirtualNode}}
> instances around and only translate from {{VirtualNode}} to {{InetAddress}}
> in the network layer.
> Public interfaces like {{IEndpointSnitch}} will not be affected by this.
--
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-14056) Many dtests fail with ConfigurationException: offheap_objects are not available in 3.0 when OFFHEAP_MEMTABLES="true"
[
https://issues.apache.org/jira/browse/CASSANDRA-14056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16521834#comment-16521834
]
Alex Lourie commented on CASSANDRA-14056:
-
PR is closed too. Thanks!
> Many dtests fail with ConfigurationException: offheap_objects are not
> available in 3.0 when OFFHEAP_MEMTABLES="true"
>
>
> Key: CASSANDRA-14056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14056
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>Priority: Major
>
> Tons of dtests are running when they shouldn't as it looks like the path is
> no longer supported.. we need to add a bunch of logic that's missing to fully
> support running dtests with off-heap memtables enabled (via the
> OFFHEAP_MEMTABLES="true" environment variable)
> {code}[node2 ERROR] java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:394)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:361)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:577)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:554)
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:887)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:354)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:110)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:179)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException:
> offheap_objects are not available in 3.0. They will be re-introduced in a
> future release, see https://issues.apache.org/jira/browse/CASSANDRA-9472 for
> details
> at
> org.apache.cassandra.config.DatabaseDescriptor.getMemtableAllocatorPool(DatabaseDescriptor.java:1907)
> at org.apache.cassandra.db.Memtable.(Memtable.java:65)
> ... 14 more
> {code}
--
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-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
[ https://issues.apache.org/jira/browse/CASSANDRA-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519001#comment-16519001 ] Alex Lourie commented on CASSANDRA-14054: - [~jasobrown] Just rerun this on trunk, 3.0 and 3.11, doesn't reproduce. Happy to close it off. > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > - > > Key: CASSANDRA-14054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14054 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Michael Kjellman >Assignee: Alex Lourie >Priority: Major > > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > Fails about 25% of the time. It is currently our only flaky unit test on > trunk so it would be great to get this one fixed up so we can be confident in > unit test failures going forward. > junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of > type int), expected <2> but got <1> > at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973) > at > org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380) -- 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-14056) Many dtests fail with ConfigurationException: offheap_objects are not available in 3.0 when OFFHEAP_MEMTABLES="true"
[
https://issues.apache.org/jira/browse/CASSANDRA-14056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518917#comment-16518917
]
Alex Lourie commented on CASSANDRA-14056:
-
[~jasobrown] You're right, I don't know how I tested before and it worked...in
any case, I've fixed both issues. Now it checks the versions including 3.0 and
when invoking pytest directly. The PR is at
https://github.com/apache/cassandra-dtest/pull/18 and the branch is
https://github.com/apache/cassandra-dtest/compare/master...alourie:CASSANDRA-14056.
Please have a look again if you can.
Thanks!
> Many dtests fail with ConfigurationException: offheap_objects are not
> available in 3.0 when OFFHEAP_MEMTABLES="true"
>
>
> Key: CASSANDRA-14056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14056
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>Priority: Major
>
> Tons of dtests are running when they shouldn't as it looks like the path is
> no longer supported.. we need to add a bunch of logic that's missing to fully
> support running dtests with off-heap memtables enabled (via the
> OFFHEAP_MEMTABLES="true" environment variable)
> {code}[node2 ERROR] java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:394)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:361)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:577)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:554)
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:887)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:354)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:110)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:179)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException:
> offheap_objects are not available in 3.0. They will be re-introduced in a
> future release, see https://issues.apache.org/jira/browse/CASSANDRA-9472 for
> details
> at
> org.apache.cassandra.config.DatabaseDescriptor.getMemtableAllocatorPool(DatabaseDescriptor.java:1907)
> at org.apache.cassandra.db.Memtable.(Memtable.java:65)
> ... 14 more
> {code}
--
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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517875#comment-16517875 ] Alex Lourie commented on CASSANDRA-13010: - Hi [~rustyrazorblade] I've just rebased this work on top of the latest trunk. Would you be able to have a look? The code is at https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010?expand=1 or patch at https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010.patch Thanks! > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lourie updated CASSANDRA-13010: Attachment: (was: 0001-Implementing-13010.patch) > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lourie updated CASSANDRA-13010: Attachment: (was: 0002-Addition-more-info-option.patch) > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: cleanup.png, multiple operations.png > > -- 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-14056) Many dtests fail with ConfigurationException: offheap_objects are not available in 3.0 when OFFHEAP_MEMTABLES="true"
[
https://issues.apache.org/jira/browse/CASSANDRA-14056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517744#comment-16517744
]
Alex Lourie commented on CASSANDRA-14056:
-
Hey [~jasobrown] [~mkjellman], could you spare few moments to look at the
patch? Thanks!
> Many dtests fail with ConfigurationException: offheap_objects are not
> available in 3.0 when OFFHEAP_MEMTABLES="true"
>
>
> Key: CASSANDRA-14056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14056
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>Priority: Major
>
> Tons of dtests are running when they shouldn't as it looks like the path is
> no longer supported.. we need to add a bunch of logic that's missing to fully
> support running dtests with off-heap memtables enabled (via the
> OFFHEAP_MEMTABLES="true" environment variable)
> {code}[node2 ERROR] java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:394)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:361)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:577)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:554)
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:887)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:354)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:110)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:179)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException:
> offheap_objects are not available in 3.0. They will be re-introduced in a
> future release, see https://issues.apache.org/jira/browse/CASSANDRA-9472 for
> details
> at
> org.apache.cassandra.config.DatabaseDescriptor.getMemtableAllocatorPool(DatabaseDescriptor.java:1907)
> at org.apache.cassandra.db.Memtable.(Memtable.java:65)
> ... 14 more
> {code}
--
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-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
[ https://issues.apache.org/jira/browse/CASSANDRA-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517743#comment-16517743 ] Alex Lourie commented on CASSANDRA-14054: - [~mkjellman] This one is laying around for awhile. Do you still have issues in the tests? If not, maybe we should close this off. > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > - > > Key: CASSANDRA-14054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14054 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Michael Kjellman >Assignee: Alex Lourie >Priority: Major > > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > Fails about 25% of the time. It is currently our only flaky unit test on > trunk so it would be great to get this one fixed up so we can be confident in > unit test failures going forward. > junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of > type int), expected <2> but got <1> > at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973) > at > org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380) -- 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-14456) Repair session fails with buffer overflow
[
https://issues.apache.org/jira/browse/CASSANDRA-14456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482181#comment-16482181
]
Alex Lourie commented on CASSANDRA-14456:
-
[~jasobrown] indeed it is from the trunk. I'm using SHA 42687616952; so it's
pretty recent.
Not sure if it's reproducible by script/dtests, I'll see if I can reproduce in
a controlled environment. It's a running test cluster at the moment.
> Repair session fails with buffer overflow
> -
>
> Key: CASSANDRA-14456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14456
> Project: Cassandra
> Issue Type: Bug
> Environment: 6 Node cluster, RF=3. The ks/table is:
>
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS alex with replication = { 'class':
> 'NetworkTopologyStrategy', 'DC': 3 };
> CREATE TABLE IF NOT EXISTS alex.test2 (
> part text,
> clus int,
> data text,
> PRIMARY KEY (part, clus);
> );
> ALTER TABLE alex.test2 WITH compaction = {'class' :
> 'LeveledCompactionStrategy', 'enabled': 'false'};
> {code}
>
> Compactions are off. Loaded with random data, then shut down 1 node and kept
> loading with random data. Then turned the node back on. Run repairs.
>Reporter: Alex Lourie
>Priority: Minor
> Attachments: log.txt
>
>
> When running a repair, a stream session fails with BufferOverflow error. The
> log excerpt is attached to the ticket.
--
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-14456) Repair session fails with buffer overflow
[
https://issues.apache.org/jira/browse/CASSANDRA-14456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Lourie updated CASSANDRA-14456:
Attachment: log.txt
> Repair session fails with buffer overflow
> -
>
> Key: CASSANDRA-14456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14456
> Project: Cassandra
> Issue Type: Bug
> Environment: 6 Node cluster, RF=3. The ks/table is:
>
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS alex with replication = { 'class':
> 'NetworkTopologyStrategy', 'DC': 3 };
> CREATE TABLE IF NOT EXISTS alex.test2 (
> part text,
> clus int,
> data text,
> PRIMARY KEY (part, clus);
> );
> ALTER TABLE alex.test2 WITH compaction = {'class' :
> 'LeveledCompactionStrategy', 'enabled': 'false'};
> {code}
>
> Compactions are off. Loaded with random data, then shut down 1 node and kept
> loading with random data. Then turned the node back on. Run repairs.
>Reporter: Alex Lourie
>Priority: Minor
> Attachments: log.txt
>
>
> When running a repair, a stream session fails with BufferOverflow error. The
> log excerpt is attached to the ticket.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14456) Repair session fails with buffer overflow
Alex Lourie created CASSANDRA-14456:
---
Summary: Repair session fails with buffer overflow
Key: CASSANDRA-14456
URL: https://issues.apache.org/jira/browse/CASSANDRA-14456
Project: Cassandra
Issue Type: Bug
Environment: 6 Node cluster, RF=3. The ks/table is:
{code:java}
CREATE KEYSPACE IF NOT EXISTS alex with replication = { 'class':
'NetworkTopologyStrategy', 'DC': 3 };
CREATE TABLE IF NOT EXISTS alex.test2 (
part text,
clus int,
data text,
PRIMARY KEY (part, clus);
);
ALTER TABLE alex.test2 WITH compaction = {'class' :
'LeveledCompactionStrategy', 'enabled': 'false'};
{code}
Compactions are off. Loaded with random data, then shut down 1 node and kept
loading with random data. Then turned the node back on. Run repairs.
Reporter: Alex Lourie
When running a repair, a stream session fails with BufferOverflow error. The
log excerpt is attached to the ticket.
--
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-14126) don't work udf javascripts
[
https://issues.apache.org/jira/browse/CASSANDRA-14126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471711#comment-16471711
]
Alex Lourie commented on CASSANDRA-14126:
-
[~umcanl] That's strange. I just ran a test for the patch and it seems to be
working fine. Could you show the complete set of commands, how do you define
the keyspace/table, and how do you query it later?
Thanks!
> don't work udf javascripts
> --
>
> Key: CASSANDRA-14126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14126
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Denis Pershin
>Assignee: Alex Lourie
>Priority: Minor
> Labels: security
> Fix For: 3.11.x
>
> Attachments: cassandra-01.yaml, cassandra-02.yaml, cassandra-03.yaml
>
>
> * config:
> {code}
> enable_user_defined_functions: true
> enable_scripted_user_defined_functions: true
> {code}
> * create keyspace:
> {code}
> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> {code}
> * in testkeyspace create function:
> {code}
> CREATE OR REPLACE FUNCTION first_int(input set) RETURNS NULL ON NULL
> INPUT RETURNS int LANGUAGE javascript AS '(function(){var result = 2;return
> result;})();';
> {code}
> * create table and insert:
> {code}
> create table A (id int primary key, val set);
> insert into A (id, val) values (1, {3,5,7,1});
> {code}
> * select:
> {code}
> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
> File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
> line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'testkeyspace.first_int[set]' failed:
> java.security.AccessControlException: access denied:
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {code}
> raw log:
> {code}
> root@001b19bd3cc6:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> USE testkeyspace ;
> cqlsh:testkeyspace> CREATE OR REPLACE FUNCTION first_int(input set)
> RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE javascript AS
> '(function(){var result = 2;return result;})();';
> cqlsh:testkeyspace> create table A (id int primary key, val set);
> cqlsh:testkeyspace> insert into A (id, val) values (1, {3,5,7,1});
> cqlsh:testkeyspace> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
> File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
> line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'testkeyspace.first_int[set]' failed:
> java.security.AccessControlException: access denied:
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {code}
--
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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439035#comment-16439035 ] Alex Lourie edited comment on CASSANDRA-13010 at 4/17/18 2:31 AM: -- [~rustyrazorblade] ok, sorry for the mess. I have still no idea how did that all got broken. But, I did fix it now, so github should work, but just in case I'm attaching the patch files as well. Please let me know if there are any more issues. Thanks. was (Author: alourie): [~rustyrazorblade] ok, sorry for the mess. I have still no idea how did that all got broken. But, I did fix it now, so github should work, and the patch it builds is applying on trunk without a problem. But just in case I'm attaching a patch file as well. Please let me know if there are any more issues. Thanks. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: 0001-Implementing-13010.patch, > 0002-Addition-more-info-option.patch, cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lourie updated CASSANDRA-13010: Attachment: (was: 0001-Implementing-13010.patch) > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: 0001-Implementing-13010.patch, > 0002-Addition-more-info-option.patch, cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lourie updated CASSANDRA-13010: Attachment: 0002-Addition-more-info-option.patch 0001-Implementing-13010.patch > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: 0001-Implementing-13010.patch, > 0002-Addition-more-info-option.patch, cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lourie updated CASSANDRA-13010: Attachment: 0001-Implementing-13010.patch > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: 0001-Implementing-13010.patch, cleanup.png, multiple > operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lourie updated CASSANDRA-13010: Attachment: (was: 13010.patch) > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: 0001-Implementing-13010.patch, cleanup.png, multiple > operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439035#comment-16439035 ] Alex Lourie commented on CASSANDRA-13010: - [~rustyrazorblade] ok, sorry for the mess. I have still no idea how did that all got broken. But, I did fix it now, so github should work, and the patch it builds is applying on trunk without a problem. But just in case I'm attaching a patch file as well. Please let me know if there are any more issues. Thanks. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: 13010.patch, cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438079#comment-16438079 ] Alex Lourie commented on CASSANDRA-13010: - [~rustyrazorblade] I have no idea what's going on. I'll check. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: 13010.patch, cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436764#comment-16436764 ] Alex Lourie commented on CASSANDRA-13010: - [~rustyrazorblade], I don't have a clue what happened during that previous "fix". I've rebased my local stuff again, so hopefully, that is now truly fixed. Additionally, I did a bit of cleanup and commenting, so now more stuff is commented on and the changeset got smaller by 2 files :) So I hope it's looking better now and is much easier to read and review. Thanks! > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: 13010.patch, cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433399#comment-16433399 ] Alex Lourie commented on CASSANDRA-13010: - No worries [~rustyrazorblade] , there's no rush. Thank you for reviewing! > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: 13010.patch, cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433267#comment-16433267 ] Alex Lourie commented on CASSANDRA-13010: - [~rustyrazorblade] Fixed. If any more updates needed, just let me know, I'm interested in pulling this in, so I'll be online for quite some time :) Thanks for the review! > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: 13010.patch, cleanup.png, multiple operations.png > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14363) system_distributed.repair_history is not properly updated if parent dies
Alex Lourie created CASSANDRA-14363: --- Summary: system_distributed.repair_history is not properly updated if parent dies Key: CASSANDRA-14363 URL: https://issues.apache.org/jira/browse/CASSANDRA-14363 Project: Cassandra Issue Type: Bug Reporter: Alex Lourie Fix For: 4.x When we start a repair on a node, the information is written to system_distributed.repair_history. If the node running it happens to be a parent (the one holding the repair session) and it dies, the entries for the repair that was running will be stuck in "STARTED" state without being updated. To resolve this, the node should check on start whether it was a parent before crash/restart, and if there are entries in the table (and in system_distributed.parent_repair_history too), and mark those entries as FAILED. -- 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-11559) Enhance node representation
[
https://issues.apache.org/jira/browse/CASSANDRA-11559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416572#comment-16416572
]
Alex Lourie commented on CASSANDRA-11559:
-
[~bdeggleston] I totally agree on VirtualEndpoint vs Endpoint.
There are indeed not that many changes except for using this changed object
where appropriate and initiating all the internal structures as required to
make it work.
Wrt to changing the Cassandra _behaviour_ - clearly that was not the purpose of
this ticket. This one is more of an infrastructure work to make the actual use
of it later. For example, https://issues.apache.org/jira/browse/CASSANDRA-12344
is going to rely on this one for solving node replacement issues when the
replacement node has same IP. But I'm also sure there are a lot of other
improvements that can be thought of further on, for instance, move
endpointStatesMap fields into this new Endpoint object, to make it easier for
Gossiper to handle this information.
I'm not yet overly familiar with the whole Cassandra to make other
suggestions,:) but would totally appreciate if there are any. If there's an
interest in improving other things that I don't know about (which is not that
hard), then I'd love to hear it and would definitely open tickets for any
suggestions.
Thanks.
> Enhance node representation
> ---
>
> Key: CASSANDRA-11559
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11559
> Project: Cassandra
> Issue Type: Sub-task
> Components: Distributed Metadata
>Reporter: Paulo Motta
>Assignee: Alex Lourie
>Priority: Minor
>
> We currently represent nodes as {{InetAddress}} objects on {{TokenMetadata}},
> what causes difficulties when replacing a node with the same address (see
> CASSANDRA-8523 and CASSANDRA-9244).
> Since CASSANDRA-4120 we index hosts by {{UUID}} in gossip, so I think it's
> time to move that representation to {{TokenMetadata}}.
> I propose representing nodes as {{InetAddress, UUID}} pairs on
> {{TokenMetadata}}, encapsulated in a {{VirtualNode}} interface, so it will
> backward compatible with the current representation, while still allowing us
> to enhance it in the future with additional metadata (and improved vnode
> handling) if needed.
> This change will probably affect interfaces of internal classes like
> {{TokenMetadata}} and {{AbstractReplicationStrategy}}, so I'd like to hear
> from integrators and other developers if it's possible to change these
> without major hassle or if we need to wait until 4.0.
> Besides updating {{TokenMetadata}} and {{AbstractReplicationStrategy}} (and
> subclasses), we will also need to replace all {{InetAddress}} uses with
> {{VirtualNode.getEndpoint()}} calls on {{StorageService}} and related classes
> and tests. We would probably already be able to replace some
> {{TokenMetadata.getHostId(InetAddress endpoint)}} calls with
> {{VirtualNode.getHostId()}}.
> While we will still be dealing with {{InetAddress}} on {{StorageService}} in
> this initial stage, in the future I think we should pass {{VirtualNode}}
> instances around and only translate from {{VirtualNode}} to {{InetAddress}}
> in the network layer.
> Public interfaces like {{IEndpointSnitch}} will not be affected by this.
--
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-14126) don't work udf javascripts
[
https://issues.apache.org/jira/browse/CASSANDRA-14126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415019#comment-16415019
]
Alex Lourie commented on CASSANDRA-14126:
-
[~dpershin] do you have any more comment on the issue?
> don't work udf javascripts
> --
>
> Key: CASSANDRA-14126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14126
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Denis Pershin
>Assignee: Alex Lourie
>Priority: Minor
> Labels: security
> Fix For: 3.11.x
>
> Attachments: cassandra-01.yaml, cassandra-02.yaml, cassandra-03.yaml
>
>
> * config:
> {code}
> enable_user_defined_functions: true
> enable_scripted_user_defined_functions: true
> {code}
> * create keyspace:
> {code}
> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> {code}
> * in testkeyspace create function:
> {code}
> CREATE OR REPLACE FUNCTION first_int(input set) RETURNS NULL ON NULL
> INPUT RETURNS int LANGUAGE javascript AS '(function(){var result = 2;return
> result;})();';
> {code}
> * create table and insert:
> {code}
> create table A (id int primary key, val set);
> insert into A (id, val) values (1, {3,5,7,1});
> {code}
> * select:
> {code}
> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
> File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
> line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'testkeyspace.first_int[set]' failed:
> java.security.AccessControlException: access denied:
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {code}
> raw log:
> {code}
> root@001b19bd3cc6:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> USE testkeyspace ;
> cqlsh:testkeyspace> CREATE OR REPLACE FUNCTION first_int(input set)
> RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE javascript AS
> '(function(){var result = 2;return result;})();';
> cqlsh:testkeyspace> create table A (id int primary key, val set);
> cqlsh:testkeyspace> insert into A (id, val) values (1, {3,5,7,1});
> cqlsh:testkeyspace> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
> File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
> line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'testkeyspace.first_int[set]' failed:
> java.security.AccessControlException: access denied:
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {code}
--
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-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
[ https://issues.apache.org/jira/browse/CASSANDRA-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415017#comment-16415017 ] Alex Lourie commented on CASSANDRA-14054: - [~mkjellman] this hasn't happened to me for a while. Do you reckon it still relevant? > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > - > > Key: CASSANDRA-14054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14054 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Michael Kjellman >Assignee: Alex Lourie >Priority: Major > > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > Fails about 25% of the time. It is currently our only flaky unit test on > trunk so it would be great to get this one fixed up so we can be confident in > unit test failures going forward. > junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of > type int), expected <2> but got <1> > at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973) > at > org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380) -- 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-14056) Many dtests fail with ConfigurationException: offheap_objects are not available in 3.0 when OFFHEAP_MEMTABLES="true"
[
https://issues.apache.org/jira/browse/CASSANDRA-14056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415016#comment-16415016
]
Alex Lourie commented on CASSANDRA-14056:
-
[~jasobrown] [~mkjellman] Just checking with you if you have any more comments
or feedback. Thanks!
> Many dtests fail with ConfigurationException: offheap_objects are not
> available in 3.0 when OFFHEAP_MEMTABLES="true"
>
>
> Key: CASSANDRA-14056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14056
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>Priority: Major
>
> Tons of dtests are running when they shouldn't as it looks like the path is
> no longer supported.. we need to add a bunch of logic that's missing to fully
> support running dtests with off-heap memtables enabled (via the
> OFFHEAP_MEMTABLES="true" environment variable)
> {code}[node2 ERROR] java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:394)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:361)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:577)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:554)
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:887)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:354)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:110)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:179)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException:
> offheap_objects are not available in 3.0. They will be re-introduced in a
> future release, see https://issues.apache.org/jira/browse/CASSANDRA-9472 for
> details
> at
> org.apache.cassandra.config.DatabaseDescriptor.getMemtableAllocatorPool(DatabaseDescriptor.java:1907)
> at org.apache.cassandra.db.Memtable.(Memtable.java:65)
> ... 14 more
> {code}
--
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-14080) Handling 0 size hint files during start
[
https://issues.apache.org/jira/browse/CASSANDRA-14080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415011#comment-16415011
]
Alex Lourie commented on CASSANDRA-14080:
-
[~iamaleksey] I would appreciate if you could have a look at this. Thanks!
> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>Priority: Major
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra
> version: 3.0.14
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API
> version: 20.1.0
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> ~[na:1.8.0_141]
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:88)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:63)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803)
> ~[na:1.8.0_141]
> at
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's
> possible that the original patch didn't consider 0 byte files (I don't have
> time to go back and look at the commit, and it was long enough ago that I've
> forgotten) - were all of your files 0 bytes?
> Not all, 8..10 hints files were with 0 size.
--
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-13010) nodetool compactionstats should say which disk a compaction is writing to
[
https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414970#comment-16414970
]
Alex Lourie commented on CASSANDRA-13010:
-
Awesome. I just pushed an update of the patch to the github at
[https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#files_bucket.]
The option for more info is --
{noformat}-v/--with-more-info{noformat}
Please let me know what you think.
> nodetool compactionstats should say which disk a compaction is writing to
> -
>
> Key: CASSANDRA-13010
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13010
> Project: Cassandra
> Issue Type: New Feature
> Components: Compaction, Tools
>Reporter: Jon Haddad
>Assignee: Alex Lourie
>Priority: Major
> Labels: lhf
> Attachments: 13010.patch, cleanup.png, multiple operations.png
>
>
--
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-11559) Enhance node representation
[
https://issues.apache.org/jira/browse/CASSANDRA-11559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Lourie updated CASSANDRA-11559:
Comment: was deleted
(was:
https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-11559#files_bucket)
> Enhance node representation
> ---
>
> Key: CASSANDRA-11559
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11559
> Project: Cassandra
> Issue Type: Sub-task
> Components: Distributed Metadata
>Reporter: Paulo Motta
>Assignee: Alex Lourie
>Priority: Minor
>
> We currently represent nodes as {{InetAddress}} objects on {{TokenMetadata}},
> what causes difficulties when replacing a node with the same address (see
> CASSANDRA-8523 and CASSANDRA-9244).
> Since CASSANDRA-4120 we index hosts by {{UUID}} in gossip, so I think it's
> time to move that representation to {{TokenMetadata}}.
> I propose representing nodes as {{InetAddress, UUID}} pairs on
> {{TokenMetadata}}, encapsulated in a {{VirtualNode}} interface, so it will
> backward compatible with the current representation, while still allowing us
> to enhance it in the future with additional metadata (and improved vnode
> handling) if needed.
> This change will probably affect interfaces of internal classes like
> {{TokenMetadata}} and {{AbstractReplicationStrategy}}, so I'd like to hear
> from integrators and other developers if it's possible to change these
> without major hassle or if we need to wait until 4.0.
> Besides updating {{TokenMetadata}} and {{AbstractReplicationStrategy}} (and
> subclasses), we will also need to replace all {{InetAddress}} uses with
> {{VirtualNode.getEndpoint()}} calls on {{StorageService}} and related classes
> and tests. We would probably already be able to replace some
> {{TokenMetadata.getHostId(InetAddress endpoint)}} calls with
> {{VirtualNode.getHostId()}}.
> While we will still be dealing with {{InetAddress}} on {{StorageService}} in
> this initial stage, in the future I think we should pass {{VirtualNode}}
> instances around and only translate from {{VirtualNode}} to {{InetAddress}}
> in the network layer.
> Public interfaces like {{IEndpointSnitch}} will not be affected by this.
--
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-11559) Enhance node representation
[
https://issues.apache.org/jira/browse/CASSANDRA-11559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Lourie updated CASSANDRA-11559:
Status: Patch Available (was: In Progress)
https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-11559#files_bucket
> Enhance node representation
> ---
>
> Key: CASSANDRA-11559
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11559
> Project: Cassandra
> Issue Type: Sub-task
> Components: Distributed Metadata
>Reporter: Paulo Motta
>Assignee: Alex Lourie
>Priority: Minor
>
> We currently represent nodes as {{InetAddress}} objects on {{TokenMetadata}},
> what causes difficulties when replacing a node with the same address (see
> CASSANDRA-8523 and CASSANDRA-9244).
> Since CASSANDRA-4120 we index hosts by {{UUID}} in gossip, so I think it's
> time to move that representation to {{TokenMetadata}}.
> I propose representing nodes as {{InetAddress, UUID}} pairs on
> {{TokenMetadata}}, encapsulated in a {{VirtualNode}} interface, so it will
> backward compatible with the current representation, while still allowing us
> to enhance it in the future with additional metadata (and improved vnode
> handling) if needed.
> This change will probably affect interfaces of internal classes like
> {{TokenMetadata}} and {{AbstractReplicationStrategy}}, so I'd like to hear
> from integrators and other developers if it's possible to change these
> without major hassle or if we need to wait until 4.0.
> Besides updating {{TokenMetadata}} and {{AbstractReplicationStrategy}} (and
> subclasses), we will also need to replace all {{InetAddress}} uses with
> {{VirtualNode.getEndpoint()}} calls on {{StorageService}} and related classes
> and tests. We would probably already be able to replace some
> {{TokenMetadata.getHostId(InetAddress endpoint)}} calls with
> {{VirtualNode.getHostId()}}.
> While we will still be dealing with {{InetAddress}} on {{StorageService}} in
> this initial stage, in the future I think we should pass {{VirtualNode}}
> instances around and only translate from {{VirtualNode}} to {{InetAddress}}
> in the network layer.
> Public interfaces like {{IEndpointSnitch}} will not be affected by this.
--
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-11559) Enhance node representation
[
https://issues.apache.org/jira/browse/CASSANDRA-11559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414721#comment-16414721
]
Alex Lourie commented on CASSANDRA-11559:
-
I've done some work on this ticket and it's available at
[https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-11559#files_bucket].
Few pointers:
* I've refactored InetAddressAndPort class into VirtualEndpoint class across
all the codebase (this will be responsible for the majority of the code
changes).
* I've added a UUID field to hold the hostID value of the endpoint and added
additional methods for working with it.
* I've reworked the TokenMetadata to hold structures other than maps for
UUID-host references and they would no longer be needed, i.e. keeping just a
set of endpoints is enough to hold both address data and the hostID data and to
also look up hosts by IDs or the vice versa.
* I've reworked the SystemKeyspace to also acknowledge the hostIDs where
significant (in local data/peer data storing/fetching), and also only create
new local id if requested (in most cases only when the node is created for the
first time, but also useful for tests that require initiating multiple "nodes"
on the same machine)
I've added a field in DatabaseDescriptor to mark that SystemKeyspace is ready
to be read. This is required for many unit tests that set up clusters "on the
fly" and for further endpoint information discovery during the test run.
* I've updated required unit tests to properly utilise the new object and
initialise and clean others as required.
* I've updated the code in some other locations to incorporate this change,
which does make it simpler on many occasions.
The current state is everything _seems_ to be working and the unit tests pass
([https://circleci.com/gh/alourie/cassandra/97])
The complication that comes out of this work is with building unit tests - the
host ID would now be kept in multiple structures:
* a VirtualEndpoint object when instantiated.
* SystemKeyspace.localHost (queries the DB)
* SystemKeyspace.peersInfo (queries the DB)
* TokenMetadata lists (such as allEndpoints, tokenMap, etc)
* Gossip.instance.endpointState maps (the specific endpoint is added including
the uuid)
* FBUtilities also keeps local reference once fetched
As a result, when creating tests, one needs to update or clear the
hostID-related information in all relevant places, otherwise, tests would fail
with really confusing messages (in most cases because in some thread an
endpoint comparison will happen and UUIDs won't match), such as "no seeds
found", "host cannot be contacted" or various kinds of timeouts and NPEs.
Additionally, when SystemKeyspace is ready to be read within a test flow, a
DatabaseDescriptor.canReadSystemKeyspace field will need to be set to true so
that the UUID would be fetched from SystemKeyspace.
Additionally, at the moment we are keeping EndpointState separately from this
object (in Gossip). Considering that now this VirtualEndpoint can include
basically any information about the endpoint, it may as well incorporate its
own state, and then all handling of the network/state information about an
endpoint will be in one place. Supposedly this should simplify things further
and allow clearing a lot of code.
[~aweisberg] - you have done the previous move away from InetAddress
representation to InetAddressAndPort, which this current patch changes
considerably. I'd love your feedback on this.
Any and all feedback is very welcome.
> Enhance node representation
> ---
>
> Key: CASSANDRA-11559
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11559
> Project: Cassandra
> Issue Type: Sub-task
> Components: Distributed Metadata
>Reporter: Paulo Motta
>Assignee: Alex Lourie
>Priority: Minor
>
> We currently represent nodes as {{InetAddress}} objects on {{TokenMetadata}},
> what causes difficulties when replacing a node with the same address (see
> CASSANDRA-8523 and CASSANDRA-9244).
> Since CASSANDRA-4120 we index hosts by {{UUID}} in gossip, so I think it's
> time to move that representation to {{TokenMetadata}}.
> I propose representing nodes as {{InetAddress, UUID}} pairs on
> {{TokenMetadata}}, encapsulated in a {{VirtualNode}} interface, so it will
> backward compatible with the current representation, while still allowing us
> to enhance it in the future with additional metadata (and improved vnode
> handling) if needed.
> This change will probably affect interfaces of internal classes like
> {{TokenMetadata}} and {{AbstractReplicationStrategy}}, so I'd like to hear
> from integrators and other developers if it's possible to change these
> without major hassle or if we need to wait until 4.0.
> Besides updating {{TokenMetadata}} and
[jira] [Comment Edited] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16405779#comment-16405779 ] Alex Lourie edited comment on CASSANDRA-13010 at 3/20/18 4:12 AM: -- [~rustyrazorblade] Thinking about your suggestion, and with some discussion with others, I think that adding an additional option flag to *compactionstats* would be more beneficial. I really like that I can see _all_ the information about all running compactions at the same time, including the directories. Hence, we could keep the current presentation intact and just add a flag to show any additional info. Also, if we wanted to, we could then expand *compactionstats* to accept an ID and only show info for that specific compaction. What do you think? was (Author: alourie): [~rustyrazorblade] Thinking about your suggestion, and with some discussion with others, I think that adding an additional option flag to compactionstats would be more beneficial. I really like that I can see _all_ the information about all running compactions at the same time, including the directories. Hence, we could keep the current presentation intact and just add a flag to show any additional info. Also, if we wanted to, we could then expand compactionstats to accept an ID and only show info for that specific compaction. What do you think? > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: 13010.patch, cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16405779#comment-16405779 ] Alex Lourie edited comment on CASSANDRA-13010 at 3/20/18 4:10 AM: -- [~rustyrazorblade] Thinking about your suggestion, and with some discussion with others, I think that adding an additional option flag to compactionstats would be more beneficial. I really like that I can see _all_ the information about all running compactions at the same time, including the directories. Hence, we could keep the current presentation intact and just add a flag to show any additional info. Also, if we wanted to, we could then expand compactionstats to accept an ID and only show info for that specific compaction. What do you think? was (Author: alourie): [~rustyrazorblade] Thinking about your suggestion, and with some discussion with others, I think that adding an additional option flag to `compactionstats` would be more beneficial. I really like that I can see _all_ the information about all running compactions at the same time, including the directories. Hence, we could keep the current presentation intact and just add a flag to show any additional info. Also, if we wanted to, we could then expand `compactionstats` to accept an ID and only show info for that specific compaction. What do you think? > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: 13010.patch, cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16405779#comment-16405779 ] Alex Lourie commented on CASSANDRA-13010: - [~rustyrazorblade] Thinking about your suggestion, and with some discussion with others, I think that adding an additional option flag to `compactionstats` would be more beneficial. I really like that I can see _all_ the information about all running compactions at the same time, including the directories. Hence, we could keep the current presentation intact and just add a flag to show any additional info. Also, if we wanted to, we could then expand `compactionstats` to accept an ID and only show info for that specific compaction. What do you think? > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: 13010.patch, cleanup.png, multiple operations.png > > -- 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-11559) Enhance node representation
[
https://issues.apache.org/jira/browse/CASSANDRA-11559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372373#comment-16372373
]
Alex Lourie commented on CASSANDRA-11559:
-
I'm going to take a swing at this one.
I'm going to tentatively call the interface IVirtualEndpoint (but clearly open
to other suggestions), and will start using the implementation in all instances
instead of InetAddressAndPort where relevant. I'd love to hear other's opinions
before I go too deep into refactoring spree.
Thanks!
> Enhance node representation
> ---
>
> Key: CASSANDRA-11559
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11559
> Project: Cassandra
> Issue Type: Sub-task
> Components: Distributed Metadata
>Reporter: Paulo Motta
>Assignee: Alex Lourie
>Priority: Minor
>
> We currently represent nodes as {{InetAddress}} objects on {{TokenMetadata}},
> what causes difficulties when replacing a node with the same address (see
> CASSANDRA-8523 and CASSANDRA-9244).
> Since CASSANDRA-4120 we index hosts by {{UUID}} in gossip, so I think it's
> time to move that representation to {{TokenMetadata}}.
> I propose representing nodes as {{InetAddress, UUID}} pairs on
> {{TokenMetadata}}, encapsulated in a {{VirtualNode}} interface, so it will
> backward compatible with the current representation, while still allowing us
> to enhance it in the future with additional metadata (and improved vnode
> handling) if needed.
> This change will probably affect interfaces of internal classes like
> {{TokenMetadata}} and {{AbstractReplicationStrategy}}, so I'd like to hear
> from integrators and other developers if it's possible to change these
> without major hassle or if we need to wait until 4.0.
> Besides updating {{TokenMetadata}} and {{AbstractReplicationStrategy}} (and
> subclasses), we will also need to replace all {{InetAddress}} uses with
> {{VirtualNode.getEndpoint()}} calls on {{StorageService}} and related classes
> and tests. We would probably already be able to replace some
> {{TokenMetadata.getHostId(InetAddress endpoint)}} calls with
> {{VirtualNode.getHostId()}}.
> While we will still be dealing with {{InetAddress}} on {{StorageService}} in
> this initial stage, in the future I think we should pass {{VirtualNode}}
> instances around and only translate from {{VirtualNode}} to {{InetAddress}}
> in the network layer.
> Public interfaces like {{IEndpointSnitch}} will not be affected by this.
--
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] [Assigned] (CASSANDRA-11559) Enhance node representation
[
https://issues.apache.org/jira/browse/CASSANDRA-11559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Lourie reassigned CASSANDRA-11559:
---
Assignee: Alex Lourie
> Enhance node representation
> ---
>
> Key: CASSANDRA-11559
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11559
> Project: Cassandra
> Issue Type: Sub-task
> Components: Distributed Metadata
>Reporter: Paulo Motta
>Assignee: Alex Lourie
>Priority: Minor
>
> We currently represent nodes as {{InetAddress}} objects on {{TokenMetadata}},
> what causes difficulties when replacing a node with the same address (see
> CASSANDRA-8523 and CASSANDRA-9244).
> Since CASSANDRA-4120 we index hosts by {{UUID}} in gossip, so I think it's
> time to move that representation to {{TokenMetadata}}.
> I propose representing nodes as {{InetAddress, UUID}} pairs on
> {{TokenMetadata}}, encapsulated in a {{VirtualNode}} interface, so it will
> backward compatible with the current representation, while still allowing us
> to enhance it in the future with additional metadata (and improved vnode
> handling) if needed.
> This change will probably affect interfaces of internal classes like
> {{TokenMetadata}} and {{AbstractReplicationStrategy}}, so I'd like to hear
> from integrators and other developers if it's possible to change these
> without major hassle or if we need to wait until 4.0.
> Besides updating {{TokenMetadata}} and {{AbstractReplicationStrategy}} (and
> subclasses), we will also need to replace all {{InetAddress}} uses with
> {{VirtualNode.getEndpoint()}} calls on {{StorageService}} and related classes
> and tests. We would probably already be able to replace some
> {{TokenMetadata.getHostId(InetAddress endpoint)}} calls with
> {{VirtualNode.getHostId()}}.
> While we will still be dealing with {{InetAddress}} on {{StorageService}} in
> this initial stage, in the future I think we should pass {{VirtualNode}}
> instances around and only translate from {{VirtualNode}} to {{InetAddress}}
> in the network layer.
> Public interfaces like {{IEndpointSnitch}} will not be affected by this.
--
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-14056) Many dtests fail with ConfigurationException: offheap_objects are not available in 3.0 when OFFHEAP_MEMTABLES="true"
[
https://issues.apache.org/jira/browse/CASSANDRA-14056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16353320#comment-16353320
]
Alex Lourie commented on CASSANDRA-14056:
-
[~jasobrown] [~mkjellman] Yes, this would still be an issue with the new
dtests. Someone might want to test with the "offheap_objects" configuration
option set. The new dtests supports this with a command-line parameter,
"--use-off-heap-memtables"; as a result, I've updated the patch and opened a PR
at [https://github.com/apache/cassandra-dtest/pull/18.]
Please let me know if you think this is the appropriate solution, and if there
are any problems with the patch.
Thanks!
> Many dtests fail with ConfigurationException: offheap_objects are not
> available in 3.0 when OFFHEAP_MEMTABLES="true"
>
>
> Key: CASSANDRA-14056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14056
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>Priority: Major
>
> Tons of dtests are running when they shouldn't as it looks like the path is
> no longer supported.. we need to add a bunch of logic that's missing to fully
> support running dtests with off-heap memtables enabled (via the
> OFFHEAP_MEMTABLES="true" environment variable)
> {code}[node2 ERROR] java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:394)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:361)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:577)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:554)
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:887)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:354)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:110)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:179)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException:
> offheap_objects are not available in 3.0. They will be re-introduced in a
> future release, see https://issues.apache.org/jira/browse/CASSANDRA-9472 for
> details
> at
> org.apache.cassandra.config.DatabaseDescriptor.getMemtableAllocatorPool(DatabaseDescriptor.java:1907)
> at org.apache.cassandra.db.Memtable.(Memtable.java:65)
> ... 14 more
> {code}
--
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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348178#comment-16348178 ] Alex Lourie commented on CASSANDRA-13010: - [~rustyrazorblade] Would you be able to have a look at the patch? Thanks! > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie >Priority: Major > Labels: lhf > Attachments: 13010.patch, cleanup.png, multiple operations.png > > -- 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-14080) Handling 0 size hint files during start
[
https://issues.apache.org/jira/browse/CASSANDRA-14080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348176#comment-16348176
]
Alex Lourie edited comment on CASSANDRA-14080 at 2/1/18 8:19 AM:
-
[~iamaleksey] it would be great if you could give a feedback on the previous
comment. Thanks!
was (Author: alourie):
[~iamaleksey] it would be great if you could give a feedback on previous
comment. Thanks!
> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>Priority: Major
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra
> version: 3.0.14
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API
> version: 20.1.0
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> ~[na:1.8.0_141]
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:88)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:63)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803)
> ~[na:1.8.0_141]
> at
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's
> possible that the original patch didn't consider 0 byte files (I don't have
> time to go back and look at the commit, and it was long enough ago that I've
> forgotten) - were all of your files 0 bytes?
> Not all, 8..10 hints files were with 0 size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail:
[jira] [Commented] (CASSANDRA-14080) Handling 0 size hint files during start
[
https://issues.apache.org/jira/browse/CASSANDRA-14080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348176#comment-16348176
]
Alex Lourie commented on CASSANDRA-14080:
-
[~iamaleksey] it would be great if you could give a feedback on previous
comment. Thanks!
> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>Priority: Major
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra
> version: 3.0.14
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API
> version: 20.1.0
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> ~[na:1.8.0_141]
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:88)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:63)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803)
> ~[na:1.8.0_141]
> at
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's
> possible that the original patch didn't consider 0 byte files (I don't have
> time to go back and look at the commit, and it was long enough ago that I've
> forgotten) - were all of your files 0 bytes?
> Not all, 8..10 hints files were with 0 size.
--
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-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
[ https://issues.apache.org/jira/browse/CASSANDRA-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348175#comment-16348175 ] Alex Lourie commented on CASSANDRA-14054: - [~mkjellman] bumping this one too. > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > - > > Key: CASSANDRA-14054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14054 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Michael Kjellman >Assignee: Alex Lourie >Priority: Major > > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > Fails about 25% of the time. It is currently our only flaky unit test on > trunk so it would be great to get this one fixed up so we can be confident in > unit test failures going forward. > junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of > type int), expected <2> but got <1> > at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973) > at > org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380) -- 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-14056) Many dtests fail with ConfigurationException: offheap_objects are not available in 3.0 when OFFHEAP_MEMTABLES="true"
[
https://issues.apache.org/jira/browse/CASSANDRA-14056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348166#comment-16348166
]
Alex Lourie commented on CASSANDRA-14056:
-
[~mkjellman] poke. I hope you find some time to have a look at the patch.
> Many dtests fail with ConfigurationException: offheap_objects are not
> available in 3.0 when OFFHEAP_MEMTABLES="true"
>
>
> Key: CASSANDRA-14056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14056
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>Priority: Major
>
> Tons of dtests are running when they shouldn't as it looks like the path is
> no longer supported.. we need to add a bunch of logic that's missing to fully
> support running dtests with off-heap memtables enabled (via the
> OFFHEAP_MEMTABLES="true" environment variable)
> {code}[node2 ERROR] java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:394)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:361)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:577)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:554)
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:887)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:354)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:110)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:179)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException:
> offheap_objects are not available in 3.0. They will be re-introduced in a
> future release, see https://issues.apache.org/jira/browse/CASSANDRA-9472 for
> details
> at
> org.apache.cassandra.config.DatabaseDescriptor.getMemtableAllocatorPool(DatabaseDescriptor.java:1907)
> at org.apache.cassandra.db.Memtable.(Memtable.java:65)
> ... 14 more
> {code}
--
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-14056) Many dtests fail with ConfigurationException: offheap_objects are not available in 3.0 when OFFHEAP_MEMTABLES="true"
[
https://issues.apache.org/jira/browse/CASSANDRA-14056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Lourie updated CASSANDRA-14056:
Reproduced In: 3.11.1
Status: Patch Available (was: In Progress)
> Many dtests fail with ConfigurationException: offheap_objects are not
> available in 3.0 when OFFHEAP_MEMTABLES="true"
>
>
> Key: CASSANDRA-14056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14056
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>
> Tons of dtests are running when they shouldn't as it looks like the path is
> no longer supported.. we need to add a bunch of logic that's missing to fully
> support running dtests with off-heap memtables enabled (via the
> OFFHEAP_MEMTABLES="true" environment variable)
> {code}[node2 ERROR] java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:394)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:361)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:577)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:554)
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:887)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:354)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:110)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:179)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException:
> offheap_objects are not available in 3.0. They will be re-introduced in a
> future release, see https://issues.apache.org/jira/browse/CASSANDRA-9472 for
> details
> at
> org.apache.cassandra.config.DatabaseDescriptor.getMemtableAllocatorPool(DatabaseDescriptor.java:1907)
> at org.apache.cassandra.db.Memtable.(Memtable.java:65)
> ... 14 more
> {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] [Updated] (CASSANDRA-14126) don't work udf javascripts
[
https://issues.apache.org/jira/browse/CASSANDRA-14126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Lourie updated CASSANDRA-14126:
Status: Patch Available (was: In Progress)
> don't work udf javascripts
> --
>
> Key: CASSANDRA-14126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14126
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Denis Pershin
>Assignee: Alex Lourie
>Priority: Minor
> Labels: security
> Fix For: 3.11.x
>
> Attachments: cassandra-01.yaml, cassandra-02.yaml, cassandra-03.yaml
>
>
> * config:
> {code}
> enable_user_defined_functions: true
> enable_scripted_user_defined_functions: true
> {code}
> * create keyspace:
> {code}
> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> {code}
> * in testkeyspace create function:
> {code}
> CREATE OR REPLACE FUNCTION first_int(input set) RETURNS NULL ON NULL
> INPUT RETURNS int LANGUAGE javascript AS '(function(){var result = 2;return
> result;})();';
> {code}
> * create table and insert:
> {code}
> create table A (id int primary key, val set);
> insert into A (id, val) values (1, {3,5,7,1});
> {code}
> * select:
> {code}
> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
> File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
> line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'testkeyspace.first_int[set]' failed:
> java.security.AccessControlException: access denied:
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {code}
> raw log:
> {code}
> root@001b19bd3cc6:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> USE testkeyspace ;
> cqlsh:testkeyspace> CREATE OR REPLACE FUNCTION first_int(input set)
> RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE javascript AS
> '(function(){var result = 2;return result;})();';
> cqlsh:testkeyspace> create table A (id int primary key, val set);
> cqlsh:testkeyspace> insert into A (id, val) values (1, {3,5,7,1});
> cqlsh:testkeyspace> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
> File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
> line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'testkeyspace.first_int[set]' failed:
> java.security.AccessControlException: access denied:
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {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] [Commented] (CASSANDRA-14126) don't work udf javascripts
[
https://issues.apache.org/jira/browse/CASSANDRA-14126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16300902#comment-16300902
]
Alex Lourie commented on CASSANDRA-14126:
-
The reason it doesn't work is that creating _functions_ in JS requires a couple
more packages to be added to "allowed" list in the sandbox.
I've created a patch here
https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-14126 for
the trunk. It fixes the issue, but the question is whether the functions should
be allowed at all.
If the functions are not allowed in the javascript UFDs, then it should be
clearly stated in the documentation.
> don't work udf javascripts
> --
>
> Key: CASSANDRA-14126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14126
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Denis Pershin
>Assignee: Alex Lourie
>Priority: Minor
> Labels: security
> Fix For: 3.11.x
>
> Attachments: cassandra-01.yaml, cassandra-02.yaml, cassandra-03.yaml
>
>
> * config:
> {code}
> enable_user_defined_functions: true
> enable_scripted_user_defined_functions: true
> {code}
> * create keyspace:
> {code}
> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> {code}
> * in testkeyspace create function:
> {code}
> CREATE OR REPLACE FUNCTION first_int(input set) RETURNS NULL ON NULL
> INPUT RETURNS int LANGUAGE javascript AS '(function(){var result = 2;return
> result;})();';
> {code}
> * create table and insert:
> {code}
> create table A (id int primary key, val set);
> insert into A (id, val) values (1, {3,5,7,1});
> {code}
> * select:
> {code}
> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
> File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
> line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'testkeyspace.first_int[set]' failed:
> java.security.AccessControlException: access denied:
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {code}
> raw log:
> {code}
> root@001b19bd3cc6:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> USE testkeyspace ;
> cqlsh:testkeyspace> CREATE OR REPLACE FUNCTION first_int(input set)
> RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE javascript AS
> '(function(){var result = 2;return result;})();';
> cqlsh:testkeyspace> create table A (id int primary key, val set);
> cqlsh:testkeyspace> insert into A (id, val) values (1, {3,5,7,1});
> cqlsh:testkeyspace> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
> File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
> line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'testkeyspace.first_int[set]' failed:
> java.security.AccessControlException: access denied:
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {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-14126) don't work udf javascripts
[
https://issues.apache.org/jira/browse/CASSANDRA-14126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Lourie reassigned CASSANDRA-14126:
---
Assignee: Alex Lourie
> don't work udf javascripts
> --
>
> Key: CASSANDRA-14126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14126
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Denis Pershin
>Assignee: Alex Lourie
>Priority: Minor
> Labels: security
> Fix For: 3.11.x
>
> Attachments: cassandra-01.yaml, cassandra-02.yaml, cassandra-03.yaml
>
>
> * config:
> {code}
> enable_user_defined_functions: true
> enable_scripted_user_defined_functions: true
> {code}
> * create keyspace:
> {code}
> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> {code}
> * in testkeyspace create function:
> {code}
> CREATE OR REPLACE FUNCTION first_int(input set) RETURNS NULL ON NULL
> INPUT RETURNS int LANGUAGE javascript AS '(function(){var result = 2;return
> result;})();';
> {code}
> * create table and insert:
> {code}
> create table A (id int primary key, val set);
> insert into A (id, val) values (1, {3,5,7,1});
> {code}
> * select:
> {code}
> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
> File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
> line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'testkeyspace.first_int[set]' failed:
> java.security.AccessControlException: access denied:
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {code}
> raw log:
> {code}
> root@001b19bd3cc6:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> USE testkeyspace ;
> cqlsh:testkeyspace> CREATE OR REPLACE FUNCTION first_int(input set)
> RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE javascript AS
> '(function(){var result = 2;return result;})();';
> cqlsh:testkeyspace> create table A (id int primary key, val set);
> cqlsh:testkeyspace> insert into A (id, val) values (1, {3,5,7,1});
> cqlsh:testkeyspace> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
> File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
> line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'testkeyspace.first_int[set]' failed:
> java.security.AccessControlException: access denied:
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {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] [Commented] (CASSANDRA-14126) don't work udf javascripts
[
https://issues.apache.org/jira/browse/CASSANDRA-14126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297849#comment-16297849
]
Alex Lourie commented on CASSANDRA-14126:
-
I'm going to have a poke at this one.
> don't work udf javascripts
> --
>
> Key: CASSANDRA-14126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14126
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Denis Pershin
>Priority: Minor
> Labels: security
> Fix For: 3.11.x
>
> Attachments: cassandra-01.yaml, cassandra-02.yaml, cassandra-03.yaml
>
>
> * config:
> {code}
> enable_user_defined_functions: true
> enable_scripted_user_defined_functions: true
> {code}
> * create keyspace:
> {code}
> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> {code}
> * in testkeyspace create function:
> {code}
> CREATE OR REPLACE FUNCTION first_int(input set) RETURNS NULL ON NULL
> INPUT RETURNS int LANGUAGE javascript AS '(function(){var result = 2;return
> result;})();';
> {code}
> * create table and insert:
> {code}
> create table A (id int primary key, val set);
> insert into A (id, val) values (1, {3,5,7,1});
> {code}
> * select:
> {code}
> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
> File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
> line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'testkeyspace.first_int[set]' failed:
> java.security.AccessControlException: access denied:
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {code}
> raw log:
> {code}
> root@001b19bd3cc6:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE testkeyspace WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> cqlsh> USE testkeyspace ;
> cqlsh:testkeyspace> CREATE OR REPLACE FUNCTION first_int(input set)
> RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE javascript AS
> '(function(){var result = 2;return result;})();';
> cqlsh:testkeyspace> create table A (id int primary key, val set);
> cqlsh:testkeyspace> insert into A (id, val) values (1, {3,5,7,1});
> cqlsh:testkeyspace> select first_int(val) from A where id = 1;
> Traceback (most recent call last):
> File "/usr/bin/cqlsh.py", line 1044, in perform_simple_statement
> result = future.result()
> File
> "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.10.zip/cassandra-driver-3.10/cassandra/cluster.py",
> line 3826, in result
> raise self._final_exception
> FunctionFailure: Error from server: code=1400 [User Defined Function failure]
> message="execution of 'testkeyspace.first_int[set]' failed:
> java.security.AccessControlException: access denied:
> ("java.lang.RuntimePermission" "accessClassInPackage.java.io")"
> {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] [Commented] (CASSANDRA-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
[
https://issues.apache.org/jira/browse/CASSANDRA-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297816#comment-16297816
]
Alex Lourie commented on CASSANDRA-14054:
-
[~mkjellman]
I've run the test on CircleCI with your configuration another 20 times and all
pass successfully. So it might indeed be some kind of a racing condition in
your environment.
The following is the code tested:
{code:java}
updateView("UPDATE %s USING TIMESTAMP 1 SET c = ?, val = ? WHERE k = ?", 0, 0,
0);
updateView("UPDATE %s USING TIMESTAMP 3 SET c = ? WHERE k = ?", 1, 0);
updateView("UPDATE %s USING TIMESTAMP 2 SET val = ? WHERE k = ?", 1, 0);
updateView("UPDATE %s USING TIMESTAMP 4 SET c = ? WHERE k = ?", 2, 0);
updateView("UPDATE %s USING TIMESTAMP 3 SET val = ? WHERE k = ?", 2, 0);
assertRows(execute("SELECT c, k, val FROM mv_rctstest"), row(2, 0, 2));
assertRows(execute("SELECT c, k, val FROM mv_rctstest limit 1"), row(2, 0, 2));
{code}
This code works on the same data, as it updates the same row. It is possible
that due to unclear timing peculiarities, the assert runs before the update had
propagated to all the replicas; or that it runs even before the update has
applied to the row on any replica. Even though that would be extremeley strange
in the environment where the tests are run.
We could do something like you suggesting, adding
"getCurrentColumnFamilyStore().forceBlockingFlush();" before the asserts.
It seems that I can't reproduce this in my environment. Is there anything
specific that your environment may have that mine doesn't?
> testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is
> flaky: expected <2> but got <1>
> -
>
> Key: CASSANDRA-14054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14054
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>
> testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is
> flaky: expected <2> but got <1>
> Fails about 25% of the time. It is currently our only flaky unit test on
> trunk so it would be great to get this one fixed up so we can be confident in
> unit test failures going forward.
> junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of
> type int), expected <2> but got <1>
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973)
> at
> org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380)
--
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-14080) Handling 0 size hint files during start
[
https://issues.apache.org/jira/browse/CASSANDRA-14080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295098#comment-16295098
]
Alex Lourie commented on CASSANDRA-14080:
-
[~iamaleksey]
I was under the impression that CRC check would handle that.
I had a look at the deserialization code that does the CRC check, and the
problem is that _any_ CRC check error (including incomplete header or file size
0) will end up as an FSError, which will cause C* to fail on start. So I've
reworked a patch from just checking the size to be > 0 to ignoring the
corrupted files instead (including one of size 0). Would that be a better
solution for the types of issues you were thinking about?
Thanks.
> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra
> version: 3.0.14
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API
> version: 20.1.0
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> ~[na:1.8.0_141]
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:88)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:63)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803)
> ~[na:1.8.0_141]
> at
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's
> possible that the original patch didn't consider 0 byte files (I don't have
> time to go back and look at the commit, and it was long enough ago that I've
> forgotten) - were all of your files 0
[jira] [Commented] (CASSANDRA-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
[ https://issues.apache.org/jira/browse/CASSANDRA-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16281337#comment-16281337 ] Alex Lourie commented on CASSANDRA-14054: - [~mkjellman] Thanks Michael, that's exactly what I was looking for! I'll need to go over this, but it's a really good start. Will update you after I read this all and have anything additional :-) > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > - > > Key: CASSANDRA-14054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14054 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Michael Kjellman >Assignee: Alex Lourie > > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > Fails about 25% of the time. It is currently our only flaky unit test on > trunk so it would be great to get this one fixed up so we can be confident in > unit test failures going forward. > junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of > type int), expected <2> but got <1> > at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973) > at > org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380) -- 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-14080) Handling 0 size hint files during start
[
https://issues.apache.org/jira/browse/CASSANDRA-14080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16281313#comment-16281313
]
Alex Lourie commented on CASSANDRA-14080:
-
[~iamaleksey] Would you mind elaborating, please, which other manifestations of
corruption you have in mind? I thought crc32 checks are supposed to cover those
other cases.
Thanks.
> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra
> version: 3.0.14
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API
> version: 20.1.0
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> ~[na:1.8.0_141]
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:88)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:63)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803)
> ~[na:1.8.0_141]
> at
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's
> possible that the original patch didn't consider 0 byte files (I don't have
> time to go back and look at the commit, and it was long enough ago that I've
> forgotten) - were all of your files 0 bytes?
> Not all, 8..10 hints files were with 0 size.
--
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] [Comment Edited] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16273867#comment-16273867 ] Alex Lourie edited comment on CASSANDRA-13010 at 12/7/17 4:06 AM: -- [~rustyrazorblade] I've got back to working on this ticket. I think I've covered all possible operations and the patch is now in a good shape. I've tested it with compactions(including split and user-defined), repair, scrub, upgradesstables and cleanup operations; I also tested with multiple data directories. It looks ok for all of them, here are a couple of screenshots: [^cleanup.png] [^multiple operations.png] I think that the patch is ready for review at github (https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010) or as a patch [^13010.patch] Would appreciate any feedback. Thanks. was (Author: alourie): [~rustyrazorblade] I've got back to working on this ticket. I think I've covered all possible operations and the patch is now in a good shape. I've tested it with compactions(including split and user-defined), repair, scrub and cleanup operations; I also tested with multiple data directories. It looks ok for all of them, here are a couple of screenshots: [^cleanup.png] [^multiple operations.png] I think that the patch is ready for review at github (https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010) or as a patch [^13010.patch] Would appreciate any feedback. Thanks. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > Attachments: 13010.patch, cleanup.png, multiple operations.png > > -- 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-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
[ https://issues.apache.org/jira/browse/CASSANDRA-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16281281#comment-16281281 ] Alex Lourie commented on CASSANDRA-14054: - [~mkjellman] I've finished running additional 20k cycles for this specific method and for the whole org.apache.cassandra.cql3.ViewTest; all tests pass (I'm running locally on Linux and Mac). Are there any more links, pointers or details that I could use to investigate it further? At the moment I can't reproduce it. Thanks > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > - > > Key: CASSANDRA-14054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14054 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Michael Kjellman >Assignee: Alex Lourie > > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > Fails about 25% of the time. It is currently our only flaky unit test on > trunk so it would be great to get this one fixed up so we can be confident in > unit test failures going forward. > junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of > type int), expected <2> but got <1> > at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973) > at > org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380) -- 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-14056) Many dtests fail with ConfigurationException: offheap_objects are not available in 3.0 when OFFHEAP_MEMTABLES="true"
[
https://issues.apache.org/jira/browse/CASSANDRA-14056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16281256#comment-16281256
]
Alex Lourie commented on CASSANDRA-14056:
-
[~mkjellman] I've added a check for a specific C* version to avoid actually
running any tests if the C* version is 3.0.x and less than 3.4; the patch is
https://github.com/alourie/cassandra-dtest/commit/0a9661e3ed404856302ab05de4d51b2d65e9e872.
Please have a look whether that's what you had in mind.
Thanks.
> Many dtests fail with ConfigurationException: offheap_objects are not
> available in 3.0 when OFFHEAP_MEMTABLES="true"
>
>
> Key: CASSANDRA-14056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14056
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>
> Tons of dtests are running when they shouldn't as it looks like the path is
> no longer supported.. we need to add a bunch of logic that's missing to fully
> support running dtests with off-heap memtables enabled (via the
> OFFHEAP_MEMTABLES="true" environment variable)
> {code}[node2 ERROR] java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:394)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:361)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:577)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:554)
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:887)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:354)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:110)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:179)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException:
> offheap_objects are not available in 3.0. They will be re-introduced in a
> future release, see https://issues.apache.org/jira/browse/CASSANDRA-9472 for
> details
> at
> org.apache.cassandra.config.DatabaseDescriptor.getMemtableAllocatorPool(DatabaseDescriptor.java:1907)
> at org.apache.cassandra.db.Memtable.(Memtable.java:65)
> ... 14 more
> {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] [Commented] (CASSANDRA-14056) Many dtests fail with ConfigurationException: offheap_objects are not available in 3.0 when OFFHEAP_MEMTABLES="true"
[
https://issues.apache.org/jira/browse/CASSANDRA-14056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16277850#comment-16277850
]
Alex Lourie commented on CASSANDRA-14056:
-
I'll have a poke at this.
> Many dtests fail with ConfigurationException: offheap_objects are not
> available in 3.0 when OFFHEAP_MEMTABLES="true"
>
>
> Key: CASSANDRA-14056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14056
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>
> Tons of dtests are running when they shouldn't as it looks like the path is
> no longer supported.. we need to add a bunch of logic that's missing to fully
> support running dtests with off-heap memtables enabled (via the
> OFFHEAP_MEMTABLES="true" environment variable)
> {code}[node2 ERROR] java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:394)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:361)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:577)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:554)
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:887)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:354)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:110)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:179)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException:
> offheap_objects are not available in 3.0. They will be re-introduced in a
> future release, see https://issues.apache.org/jira/browse/CASSANDRA-9472 for
> details
> at
> org.apache.cassandra.config.DatabaseDescriptor.getMemtableAllocatorPool(DatabaseDescriptor.java:1907)
> at org.apache.cassandra.db.Memtable.(Memtable.java:65)
> ... 14 more
> {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-14056) Many dtests fail with ConfigurationException: offheap_objects are not available in 3.0 when OFFHEAP_MEMTABLES="true"
[
https://issues.apache.org/jira/browse/CASSANDRA-14056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Lourie reassigned CASSANDRA-14056:
---
Assignee: Alex Lourie
> Many dtests fail with ConfigurationException: offheap_objects are not
> available in 3.0 when OFFHEAP_MEMTABLES="true"
>
>
> Key: CASSANDRA-14056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14056
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>
> Tons of dtests are running when they shouldn't as it looks like the path is
> no longer supported.. we need to add a bunch of logic that's missing to fully
> support running dtests with off-heap memtables enabled (via the
> OFFHEAP_MEMTABLES="true" environment variable)
> {code}[node2 ERROR] java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:394)
> at
> org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:361)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:577)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:554)
> at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.(Keyspace.java:305)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106)
> at
> org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:887)
> at
> org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:354)
> at
> org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:110)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:179)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> Caused by: org.apache.cassandra.exceptions.ConfigurationException:
> offheap_objects are not available in 3.0. They will be re-introduced in a
> future release, see https://issues.apache.org/jira/browse/CASSANDRA-9472 for
> details
> at
> org.apache.cassandra.config.DatabaseDescriptor.getMemtableAllocatorPool(DatabaseDescriptor.java:1907)
> at org.apache.cassandra.db.Memtable.(Memtable.java:65)
> ... 14 more
> {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] [Commented] (CASSANDRA-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
[ https://issues.apache.org/jira/browse/CASSANDRA-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16277842#comment-16277842 ] Alex Lourie commented on CASSANDRA-14054: - Could you send me a link? At the moment I have no information that would help to investigate this. Thanks! > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > - > > Key: CASSANDRA-14054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14054 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Michael Kjellman >Assignee: Alex Lourie > > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > Fails about 25% of the time. It is currently our only flaky unit test on > trunk so it would be great to get this one fixed up so we can be confident in > unit test failures going forward. > junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of > type int), expected <2> but got <1> > at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973) > at > org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380) -- 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-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
[
https://issues.apache.org/jira/browse/CASSANDRA-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16277826#comment-16277826
]
Alex Lourie commented on CASSANDRA-14054:
-
[~mkjellman] I've ran the following test more than 5k times since yesterday
without a single failure:
{code:java}
ant test -S -Dtest.name=org.apache.cassandra.cql3.ViewTest
-Dtest.methods=testRegularColumnTimestampUpdates
{code}
I still have 2 cycles test running (to be done in a few hours) to make sure
I haven't missed anything. Is there more information about the failure you
experienced or more details about your circumstances?
Thanks.
> testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is
> flaky: expected <2> but got <1>
> -
>
> Key: CASSANDRA-14054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14054
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>
> testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is
> flaky: expected <2> but got <1>
> Fails about 25% of the time. It is currently our only flaky unit test on
> trunk so it would be great to get this one fixed up so we can be confident in
> unit test failures going forward.
> junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of
> type int), expected <2> but got <1>
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973)
> at
> org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380)
--
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] [Comment Edited] (CASSANDRA-14080) Handling 0 size hint files during start
[
https://issues.apache.org/jira/browse/CASSANDRA-14080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16277796#comment-16277796
]
Alex Lourie edited comment on CASSANDRA-14080 at 12/5/17 12:26 AM:
---
[~iamaleksey] That should prevent empty hint files to be written as much as C*
is concerned. The problem is that we have no way to reproduce creation of the
empty hint files and for all we know these hint files could have been created
from external circumstances such as corrupt disks. We should still handle 0
length files but this isn't a ticket for a long drawn out investigation with
possibly no results.
was (Author: alourie):
[~iamaleksey] while that should prevent empty hint files to be written, there
could be other, external, circumstances for their existence. The patch in this
ticket is to make sure C* doesn't crash if that happens.
> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra
> version: 3.0.14
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API
> version: 20.1.0
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> ~[na:1.8.0_141]
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:88)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:63)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803)
> ~[na:1.8.0_141]
> at
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's
> possible that the
[jira] [Commented] (CASSANDRA-14080) Handling 0 size hint files during start
[
https://issues.apache.org/jira/browse/CASSANDRA-14080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16277796#comment-16277796
]
Alex Lourie commented on CASSANDRA-14080:
-
[~iamaleksey] while that should prevent empty hint files to be written, there
could be other, external, circumstances for their existence. The patch in this
ticket is to make sure C* doesn't crash if that happens.
> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra
> version: 3.0.14
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API
> version: 20.1.0
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> ~[na:1.8.0_141]
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:88)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:63)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803)
> ~[na:1.8.0_141]
> at
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's
> possible that the original patch didn't consider 0 byte files (I don't have
> time to go back and look at the commit, and it was long enough ago that I've
> forgotten) - were all of your files 0 bytes?
> Not all, 8..10 hints files were with 0 size.
--
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:
[jira] [Commented] (CASSANDRA-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
[ https://issues.apache.org/jira/browse/CASSANDRA-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16276241#comment-16276241 ] Alex Lourie commented on CASSANDRA-14054: - I'm looking into this. > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > - > > Key: CASSANDRA-14054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14054 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Michael Kjellman >Assignee: Alex Lourie > > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > Fails about 25% of the time. It is currently our only flaky unit test on > trunk so it would be great to get this one fixed up so we can be confident in > unit test failures going forward. > junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of > type int), expected <2> but got <1> > at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973) > at > org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380) -- 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-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
[ https://issues.apache.org/jira/browse/CASSANDRA-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lourie reassigned CASSANDRA-14054: --- Assignee: Alex Lourie > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > - > > Key: CASSANDRA-14054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14054 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Michael Kjellman >Assignee: Alex Lourie > > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > Fails about 25% of the time. It is currently our only flaky unit test on > trunk so it would be great to get this one fixed up so we can be confident in > unit test failures going forward. > junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of > type int), expected <2> but got <1> > at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973) > at > org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380) -- 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-14080) Handling 0 size hint files during start
[
https://issues.apache.org/jira/browse/CASSANDRA-14080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Lourie updated CASSANDRA-14080:
Reproduced In: 3.0.14, 4.x (was: 3.0.14)
Status: Patch Available (was: In Progress)
> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra
> version: 3.0.14
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API
> version: 20.1.0
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> ~[na:1.8.0_141]
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:88)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:63)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803)
> ~[na:1.8.0_141]
> at
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's
> possible that the original patch didn't consider 0 byte files (I don't have
> time to go back and look at the commit, and it was long enough ago that I've
> forgotten) - were all of your files 0 bytes?
> Not all, 8..10 hints files were with 0 size.
--
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-14080) Handling 0 size hint files during start
[
https://issues.apache.org/jira/browse/CASSANDRA-14080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16276232#comment-16276232
]
Alex Lourie commented on CASSANDRA-14080:
-
A patch for trunk in
https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-14080
> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra
> version: 3.0.14
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API
> version: 20.1.0
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> ~[na:1.8.0_141]
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:88)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:63)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803)
> ~[na:1.8.0_141]
> at
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's
> possible that the original patch didn't consider 0 byte files (I don't have
> time to go back and look at the commit, and it was long enough ago that I've
> forgotten) - were all of your files 0 bytes?
> Not all, 8..10 hints files were with 0 size.
--
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] [Comment Edited] (CASSANDRA-14080) Handling 0 size hint files during start
[
https://issues.apache.org/jira/browse/CASSANDRA-14080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16276232#comment-16276232
]
Alex Lourie edited comment on CASSANDRA-14080 at 12/4/17 2:48 AM:
--
A patch for trunk is in
https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-14080
was (Author: alourie):
A patch for trunk in
https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-14080
> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra
> version: 3.0.14
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API
> version: 20.1.0
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> ~[na:1.8.0_141]
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:88)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:63)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803)
> ~[na:1.8.0_141]
> at
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's
> possible that the original patch didn't consider 0 byte files (I don't have
> time to go back and look at the commit, and it was long enough ago that I've
> forgotten) - were all of your files 0 bytes?
> Not all, 8..10 hints files were with 0 size.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For
[jira] [Assigned] (CASSANDRA-14080) Handling 0 size hint files during start
[
https://issues.apache.org/jira/browse/CASSANDRA-14080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Lourie reassigned CASSANDRA-14080:
---
Assignee: Alex Lourie
> Handling 0 size hint files during start
> ---
>
> Key: CASSANDRA-14080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14080
> Project: Cassandra
> Issue Type: Bug
> Components: Hints
>Reporter: Aleksandr Ivanov
>Assignee: Alex Lourie
>
> Continuation of CASSANDRA-12728 bug.
> Problem: Cassandra didn't start due to 0 size hints files
> Log form v3.0.14:
> {code:java}
> INFO [main] 2017-11-28 19:10:13,554 StorageService.java:575 - Cassandra
> version: 3.0.14
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:576 - Thrift API
> version: 20.1.0
> INFO [main] 2017-11-28 19:10:13,555 StorageService.java:577 - CQL supported
> versions: 3.4.0 (default: 3.4.0)
> ERROR [main] 2017-11-28 19:10:13,592 CassandraDaemon.java:710 - Exception
> encountered during startup
> org.apache.cassandra.io.FSReadError: java.io.EOFException
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:142)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> ~[na:1.8.0_141]
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> ~[na:1.8.0_141]
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> ~[na:1.8.0_141]
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> ~[na:1.8.0_141]
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> ~[na:1.8.0_141]
> at org.apache.cassandra.hints.HintsCatalog.load(HintsCatalog.java:65)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:88)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsService.(HintsService.java:63)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageProxy.(StorageProxy.java:121)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Class.forName0(Native Method) ~[na:1.8.0_141]
> at java.lang.Class.forName(Class.java:264) ~[na:1.8.0_141]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:346)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697)
> [apache-cassandra-3.0.14.jar:3.0.14]
> Caused by: java.io.EOFException: null
> at java.io.RandomAccessFile.readInt(RandomAccessFile.java:803)
> ~[na:1.8.0_141]
> at
> org.apache.cassandra.hints.HintsDescriptor.deserialize(HintsDescriptor.java:237)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.hints.HintsDescriptor.readFromFile(HintsDescriptor.java:138)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 20 common frames omitted
> {code}
> After several 0 size hints files deletion Cassandra started successfully.
> Jeff Jirsa added a comment - Yesterday
> Aleksandr Ivanov can you open a new JIRA and link it back to this one? It's
> possible that the original patch didn't consider 0 byte files (I don't have
> time to go back and look at the commit, and it was long enough ago that I've
> forgotten) - were all of your files 0 bytes?
> Not all, 8..10 hints files were with 0 size.
--
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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lourie updated CASSANDRA-13010: Attachment: (was: Pasted image at 2017_12_01 11_44 AM.png) > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > Attachments: 13010.patch, cleanup.png, multiple operations.png > > -- 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] [Issue Comment Deleted] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lourie updated CASSANDRA-13010: Comment: was deleted (was: MultipleDirectoriesScreenshot) > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > Attachments: 13010.patch, Pasted image at 2017_12_01 11_44 AM.png, > cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lourie updated CASSANDRA-13010: Attachment: Pasted image at 2017_12_01 11_44 AM.png MultipleDirectoriesScreenshot > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > Attachments: 13010.patch, Pasted image at 2017_12_01 11_44 AM.png, > cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16273867#comment-16273867 ] Alex Lourie commented on CASSANDRA-13010: - [~rustyrazorblade] I've got back to working on this ticket. I think I've covered all possible operations and the patch is now in a good shape. I've tested it with compactions(including split and user-defined), repair, scrub and cleanup operations; I also tested with multiple data directories. It looks ok for all of them, here are a couple of screenshots: [^cleanup.png] [^multiple operations.png] I think that the patch is ready for review at github (https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010) or as a patch [^13010.patch] Would appreciate any feedback. Thanks. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > Attachments: 13010.patch, cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lourie updated CASSANDRA-13010: Attachment: multiple operations.png > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > Attachments: 13010.patch, cleanup.png, multiple operations.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lourie updated CASSANDRA-13010: Attachment: cleanup.png > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > Attachments: 13010.patch, cleanup.png > > -- 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-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lourie updated CASSANDRA-13010: Attachment: 13010.patch > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Compaction, Tools >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > Attachments: 13010.patch > > -- 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] [Comment Edited] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15902276#comment-15902276 ] Alex Lourie edited comment on CASSANDRA-13010 at 3/9/17 4:39 AM: - [~rustyrazorblade] I've updated the code with a couple of code style fixes and a couple of code updates as well. At the moment I'm having a trouble with https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-2106480b863a1ea6485772847314cb06, https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-c0089857a31093b8546a1ec95541a529 and https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-d4e3b82e9bebfd2cb466b4a30af07fa4 These are instances where I can't figure out an SSTableWriter not any other writer or reader object, so I'd need some help on figuring this out. I hope that in other instances I got them right though. was (Author: alourie): [~rustyrazorblade] I've updated the code with a couple of code style fixes and a couple of code updates as well. At the moment I'm having a trouble with https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-2106480b863a1ea6485772847314cb06, https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-c0089857a31093b8546a1ec95541a529 and https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-d4e3b82e9bebfd2cb466b4a30af07fa4. These are instances where I can't figure out an SSTableWriter not any other writer or reader object. I hope that in other instances I got them right though. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15902276#comment-15902276 ] Alex Lourie edited comment on CASSANDRA-13010 at 3/9/17 1:25 AM: - [~rustyrazorblade] I've updated the code with a couple of code style fixes and couple of code updates as well. At the moment I'm having a trouble with https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-2106480b863a1ea6485772847314cb06 https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-c0089857a31093b8546a1ec95541a529 https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-d4e3b82e9bebfd2cb466b4a30af07fa4. These are instances where I can't figure out an SSTableWriter not any other writer or reader object. I hope that in other instances I got them right though. was (Author: alourie): [~rustyrazorblade] I've updated the code with a couple of code style fixes and couple of code updates as well. At the moment I'm having a trouble with https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-2106480b863a1ea6485772847314cb06, https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-c0089857a31093b8546a1ec95541a529 and https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-d4e3b82e9bebfd2cb466b4a30af07fa4. These are instances where I can't figure out an SSTableWriter not any other writer or reader object. I hope that in other instances I got them right though. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15902276#comment-15902276 ] Alex Lourie edited comment on CASSANDRA-13010 at 3/9/17 1:26 AM: - [~rustyrazorblade] I've updated the code with a couple of code style fixes and a couple of code updates as well. At the moment I'm having a trouble with https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-2106480b863a1ea6485772847314cb06, https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-c0089857a31093b8546a1ec95541a529 and https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-d4e3b82e9bebfd2cb466b4a30af07fa4. These are instances where I can't figure out an SSTableWriter not any other writer or reader object. I hope that in other instances I got them right though. was (Author: alourie): [~rustyrazorblade] I've updated the code with a couple of code style fixes and couple of code updates as well. At the moment I'm having a trouble with https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-2106480b863a1ea6485772847314cb06 https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-c0089857a31093b8546a1ec95541a529 https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-d4e3b82e9bebfd2cb466b4a30af07fa4. These are instances where I can't figure out an SSTableWriter not any other writer or reader object. I hope that in other instances I got them right though. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15902276#comment-15902276 ] Alex Lourie commented on CASSANDRA-13010: - [~rustyrazorblade] I've updated the code with a couple of code style fixes and couple of code updates as well. At the moment I'm having a trouble with https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-2106480b863a1ea6485772847314cb06, https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-c0089857a31093b8546a1ec95541a529 and https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010#diff-d4e3b82e9bebfd2cb466b4a30af07fa4. These are instances where I can't figure out an SSTableWriter not any other writer or reader object. I hope that in other instances I got them right though. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15900569#comment-15900569 ] Alex Lourie commented on CASSANDRA-13010: - [~rustyrazorblade] totally fair. I'll ensure the conformity to the style guide. Thanks. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15899894#comment-15899894 ] Alex Lourie commented on CASSANDRA-13010: - [~rustyrazorblade] I've updated the patch with the suggested UI changes. It will now group compactions by a directory. Please let me know how it looks, and also I'd love a feedback for the actual implementation of the feature. Thanks! > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15890376#comment-15890376 ] Alex Lourie commented on CASSANDRA-13010: - Hi [~rustyrazorblade] In essence, I'd like to know if I'm on the right path. There are a lot of things in the codebase that I don't understand, but I hope that I'm at least going in right direction. Thanks. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature >Reporter: Jon Haddad >Assignee: Alex Lourie > Labels: lhf > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15887049#comment-15887049 ] Alex Lourie commented on CASSANDRA-13010: - [~jjirsa] Thanks! [~rustyrazorblade] please be gentle :-) > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature >Reporter: Jon Haddad > Labels: lhf > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15886937#comment-15886937 ] Alex Lourie commented on CASSANDRA-13010: - [~jjirsa] I've created a branch with my work at https://github.com/apache/cassandra/compare/trunk...alourie:CASSANDRA-13010, please provide feedback and whether I'm on the right path. Thanks a lot! > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature >Reporter: Jon Haddad > Labels: lhf > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884908#comment-15884908 ] Alex Lourie edited comment on CASSANDRA-13010 at 2/27/17 2:21 PM: -- Thanks [~jjirsa]! I've started by adding a targetDirectory to the *CompactionInfo* class. Then I'm working backwards handling new instantiations with appropriate path parameters. The problem I got at the moment is finding the correct *path* parameter for every such new call. For instance, in https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CollatedViewIndexBuilder.java#L54; I can't find a proper argument to add as a target directory. Am I going the right direction? I've tried running the test with building ccm cluster and causing it to run compactions, but the target dir shown for a running compaction is empty, so I probably do something wrong somewhere. Thanks. was (Author: alourie): Thanks [~jjirsa]! I've started by adding a targetDirectory to the *CompactionInfo* object. Then I'm working backwards handling new instantiations with appropriate path parameters. The problem I got at the moment is finding the correct *path* parameter for every such new call. For instance, in https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CollatedViewIndexBuilder.java#L54; I can't find a proper argument to add as a target directory. Am I going the right direction? I've tried running the test with building ccm cluster and causing it to run compactions, but the target dir shown for a running compaction is empty, so I probably do something wrong somewhere. Thanks. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature >Reporter: Jon Haddad > Labels: lhf > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884908#comment-15884908 ] Alex Lourie edited comment on CASSANDRA-13010 at 2/26/17 8:58 PM: -- Thanks [~jjirsa]! I've started by adding a targetDirectory to the *CompactionInfo* object. Then I'm working backwards handling new instantiations with appropriate path parameters. The problem I got at the moment is finding the correct *path* parameter for every such new call. For instance, in https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CollatedViewIndexBuilder.java#L54; I can't find a proper argument to add as a target directory. Am I going the right direction? I've tried running the test with building ccm cluster and causing it to run compactions, but the target dir shown for a running compaction is empty, so I probably do something wrong somewhere. Thanks. was (Author: alourie): Thanks [~jjirsa]! I've started by adding a `targetDirectory` to the `CompactionInfo` object. Then I'm working backwards handling new instantiations with appropriate path parameters. The problem I got at the moment is finding the correct `path` parameter for every such `new` call. For instance, in https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CollatedViewIndexBuilder.java#L54; I can't find a proper argument to add as a target directory. Am I going the right direction? I've tried running the test with building ccm cluster and causing it to run compactions, but the target dir shown for a running compaction is empty, so I probably do something wrong somewhere. Thanks. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature >Reporter: Jon Haddad > Labels: lhf > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884908#comment-15884908 ] Alex Lourie commented on CASSANDRA-13010: - Thanks [~jjirsa]! I've started by adding a `targetDirectory` to the `CompactionInfo` object. Then I'm working backwards handling new instantiations with appropriate path parameters. The problem I got at the moment is finding the correct `path` parameter for every such `new` call. For instance, in https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CollatedViewIndexBuilder.java#L54; I can't find a proper argument to add as a target directory. Am I going the right direction? I've tried running the test with building ccm cluster and causing it to run compactions, but the target dir shown for a running compaction is empty, so I probably do something wrong somewhere. Thanks. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature >Reporter: Jon Haddad > Labels: lhf > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875247#comment-15875247 ] Alex Lourie commented on CASSANDRA-13010: - I'm interested in taking on this task. I'm new to the project and would appreciate any guidance. Thanks. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature >Reporter: Jon Haddad > Labels: lhf > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
