[jira] [Comment Edited] (CASSANDRA-13649) Uncaught exceptions in Netty pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200616#comment-16200616
]
Varun Gupta edited comment on CASSANDRA-13649 at 10/11/17 5:18 PM:
---
[~norman] I rolled out this patch to one of our production cluster, I still see
syscall:read exception in the logs.
INFO [epollEventLoopGroup-11-9] 2017-10-11 17:01:10,074 Message.java:641 -
Unexpected exception during request; channel = [id: 0x72599f85, L:/X.X.X.X:
- R:/X.X.X.X:]
io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
Connection reset by peer
was (Author: varung):
[~norman] I rolled out this patch to one of our production cluster, I still see
sys.read exception in the logs.
INFO [epollEventLoopGroup-11-9] 2017-10-11 17:01:10,074 Message.java:641 -
Unexpected exception during request; channel = [id: 0x72599f85, L:/X.X.X.X:
- R:/X.X.X.X:]
io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
Connection reset by peer
> Uncaught exceptions in Netty pipeline
> -
>
> Key: CASSANDRA-13649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13649
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging, Testing
>Reporter: Stefan Podkowinski
>Assignee: Norman Maurer
> Labels: patch
> Fix For: 2.2.11, 3.0.15, 3.11.1, 4.0
>
> Attachments:
> 0001-CASSANDRA-13649-Ensure-all-exceptions-are-correctly-.patch,
> test_stdout.txt
>
>
> I've noticed some netty related errors in trunk in [some of the dtest
> results|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/106/#showFailuresLink].
> Just want to make sure that we don't have to change anything related to the
> exception handling in our pipeline and that this isn't a netty issue.
> Actually if this causes flakiness but is otherwise harmless, we should do
> something about it, even if it's just on the dtest side.
> {noformat}
> WARN [epollEventLoopGroup-2-9] 2017-06-28 17:23:49,699 Slf4JLogger.java:151
> - An exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
> Connection reset by peer
> at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown
> Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> {noformat}
> And again in another test:
> {noformat}
> WARN [epollEventLoopGroup-2-8] 2017-06-29 02:27:31,300 Slf4JLogger.java:151
> - An exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
> Connection reset by peer
> at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown
> Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> {noformat}
> Edit:
> The {{io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)()
> failed}} error also causes tests to fail for 3.0 and 3.11.
--
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-13649) Uncaught exceptions in Netty pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200616#comment-16200616
]
Varun Gupta edited comment on CASSANDRA-13649 at 10/11/17 5:18 PM:
---
[~norman] I rolled out this patch to one of our production cluster, I still see
sys.read exception in the logs.
INFO [epollEventLoopGroup-11-9] 2017-10-11 17:01:10,074 Message.java:641 -
Unexpected exception during request; channel = [id: 0x72599f85, L:/X.X.X.X:
- R:/X.X.X.X:]
io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
Connection reset by peer
was (Author: varung):
[~norman] I rolled out this patch to one of our production cluster, I still
sys.read exception in the logs.
INFO [epollEventLoopGroup-11-9] 2017-10-11 17:01:10,074 Message.java:641 -
Unexpected exception during request; channel = [id: 0x72599f85, L:/X.X.X.X:
- R:/X.X.X.X:]
io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
Connection reset by peer
> Uncaught exceptions in Netty pipeline
> -
>
> Key: CASSANDRA-13649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13649
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging, Testing
>Reporter: Stefan Podkowinski
>Assignee: Norman Maurer
> Labels: patch
> Fix For: 2.2.11, 3.0.15, 3.11.1, 4.0
>
> Attachments:
> 0001-CASSANDRA-13649-Ensure-all-exceptions-are-correctly-.patch,
> test_stdout.txt
>
>
> I've noticed some netty related errors in trunk in [some of the dtest
> results|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/106/#showFailuresLink].
> Just want to make sure that we don't have to change anything related to the
> exception handling in our pipeline and that this isn't a netty issue.
> Actually if this causes flakiness but is otherwise harmless, we should do
> something about it, even if it's just on the dtest side.
> {noformat}
> WARN [epollEventLoopGroup-2-9] 2017-06-28 17:23:49,699 Slf4JLogger.java:151
> - An exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
> Connection reset by peer
> at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown
> Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> {noformat}
> And again in another test:
> {noformat}
> WARN [epollEventLoopGroup-2-8] 2017-06-29 02:27:31,300 Slf4JLogger.java:151
> - An exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
> Connection reset by peer
> at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown
> Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> {noformat}
> Edit:
> The {{io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)()
> failed}} error also causes tests to fail for 3.0 and 3.11.
--
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-13649) Uncaught exceptions in Netty pipeline
[
https://issues.apache.org/jira/browse/CASSANDRA-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200616#comment-16200616
]
Varun Gupta commented on CASSANDRA-13649:
-
[~norman] I rolled out this patch to one of our production cluster, I still
sys.read exception in the logs.
INFO [epollEventLoopGroup-11-9] 2017-10-11 17:01:10,074 Message.java:641 -
Unexpected exception during request; channel = [id: 0x72599f85, L:/X.X.X.X:
- R:/X.X.X.X:]
io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
Connection reset by peer
> Uncaught exceptions in Netty pipeline
> -
>
> Key: CASSANDRA-13649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13649
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging, Testing
>Reporter: Stefan Podkowinski
>Assignee: Norman Maurer
> Labels: patch
> Fix For: 2.2.11, 3.0.15, 3.11.1, 4.0
>
> Attachments:
> 0001-CASSANDRA-13649-Ensure-all-exceptions-are-correctly-.patch,
> test_stdout.txt
>
>
> I've noticed some netty related errors in trunk in [some of the dtest
> results|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/106/#showFailuresLink].
> Just want to make sure that we don't have to change anything related to the
> exception handling in our pipeline and that this isn't a netty issue.
> Actually if this causes flakiness but is otherwise harmless, we should do
> something about it, even if it's just on the dtest side.
> {noformat}
> WARN [epollEventLoopGroup-2-9] 2017-06-28 17:23:49,699 Slf4JLogger.java:151
> - An exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
> Connection reset by peer
> at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown
> Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> {noformat}
> And again in another test:
> {noformat}
> WARN [epollEventLoopGroup-2-8] 2017-06-29 02:27:31,300 Slf4JLogger.java:151
> - An exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
> io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed:
> Connection reset by peer
> at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown
> Source) ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> {noformat}
> Edit:
> The {{io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)()
> failed}} error also causes tests to fail for 3.0 and 3.11.
--
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-13431) Streaming error occurred org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
[ https://issues.apache.org/jira/browse/CASSANDRA-13431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Gupta updated CASSANDRA-13431: Attachment: Stream_Error_Broken_Pipe > Streaming error occurred org.apache.cassandra.io.FSReadError: > java.io.IOException: Broken pipe > -- > > Key: CASSANDRA-13431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13431 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging > Environment: ubuntu, cassandra 2.2.7, AWS EC2 >Reporter: krish > Labels: features, patch, performance > Fix For: 2.2.7 > > Attachments: Stream_Error_Broken_Pipe > > > I am trying to add a node to the cluster. > Adding new node to cluster fails with broken pipe. cassandra fails after > starting with in 2 mints. > removed the node from the ring. Adding back fails. > OS info: 4.4.0-59-generic #80-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux. > ERROR [STREAM-OUT-/123.120.56.71] 2017-04-10 23:46:15,410 > StreamSession.java:532 - [Stream #cbb7a150-1e47-11e7-a556-a98ec456f4de] > Streaming error occurred > org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe > at > org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144) > ~[apache-cassandra-2.2.7.jar:2.2.7] > at > org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:91) > ~[apache-cassandra-2.2.7.jar:2.2. > 7] > at > org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:88) > ~[apache-cassandra-2.2.7.jar:2.2. > 7] > at > org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.applyToChannel(BufferedDataOutputStreamPlus.java:297) > ~[apache-cassandra-2.2.7 > .jar:2.2.7] > at > org.apache.cassandra.streaming.compress.CompressedStreamWriter.write(CompressedStreamWriter.java:87) > ~[apache-cassandra-2.2.7.jar:2.2.7] > at > org.apache.cassandra.streaming.messages.OutgoingFileMessage.serialize(OutgoingFileMessage.java:90) > ~[apache-cassandra-2.2.7.jar:2.2.7] > at > org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:48) > ~[apache-cassandra-2.2.7.jar:2.2.7] > at > org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:40) > ~[apache-cassandra-2.2.7.jar:2.2.7] > at > org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:47) > ~[apache-cassandra-2.2.7.jar:2.2.7] > at > org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:389) > ~[apache-cassandra-2.2.7 > .jar:2.2.7] > at > org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:361) > ~[apache-cassandra-2.2.7.jar:2.2.7] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101] > Caused by: java.io.IOException: Broken pipe > at sun.nio.ch.FileChannelImpl.transferTo0(Native Method) > ~[na:1.8.0_101] > at > sun.nio.ch.FileChannelImpl.transferToDirectlyInternal(FileChannelImpl.java:428) > ~[na:1.8.0_101] > at > sun.nio.ch.FileChannelImpl.transferToDirectly(FileChannelImpl.java:493) > ~[na:1.8.0_101] > at sun.nio.ch.FileChannelImpl.transferTo(FileChannelImpl.java:608) > ~[na:1.8.0_101] > at > org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:140) > ~[apache-cassandra-2.2.7.jar:2.2.7] > ... 11 common frames omitted > INFO [STREAM-OUT-/123.120.56.71] 2017-04-10 23:46:15,424 > StreamResultFuture.java:183 - [Stream #cbb7a150-1e47-11e7-a556-a98ec456f4de] > Session with / 123.120.56.71 > is complete > WARN [STREAM-OUT-/123.120.56.71] 2017-04-10 23:46:15,425 > StreamResultFuture.java:210 - [Stream #cbb7a150-1e47-11e7-a556-a98ec456f4de] > Stream failed -- 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-13431) Streaming error occurred org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
[ https://issues.apache.org/jira/browse/CASSANDRA-13431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199115#comment-16199115 ] Varun Gupta commented on CASSANDRA-13431: - I am seeing similar error at 3.0.14 as well. > Streaming error occurred org.apache.cassandra.io.FSReadError: > java.io.IOException: Broken pipe > -- > > Key: CASSANDRA-13431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13431 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging > Environment: ubuntu, cassandra 2.2.7, AWS EC2 >Reporter: krish > Labels: features, patch, performance > Fix For: 2.2.7 > > > I am trying to add a node to the cluster. > Adding new node to cluster fails with broken pipe. cassandra fails after > starting with in 2 mints. > removed the node from the ring. Adding back fails. > OS info: 4.4.0-59-generic #80-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux. > ERROR [STREAM-OUT-/123.120.56.71] 2017-04-10 23:46:15,410 > StreamSession.java:532 - [Stream #cbb7a150-1e47-11e7-a556-a98ec456f4de] > Streaming error occurred > org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe > at > org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144) > ~[apache-cassandra-2.2.7.jar:2.2.7] > at > org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:91) > ~[apache-cassandra-2.2.7.jar:2.2. > 7] > at > org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:88) > ~[apache-cassandra-2.2.7.jar:2.2. > 7] > at > org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.applyToChannel(BufferedDataOutputStreamPlus.java:297) > ~[apache-cassandra-2.2.7 > .jar:2.2.7] > at > org.apache.cassandra.streaming.compress.CompressedStreamWriter.write(CompressedStreamWriter.java:87) > ~[apache-cassandra-2.2.7.jar:2.2.7] > at > org.apache.cassandra.streaming.messages.OutgoingFileMessage.serialize(OutgoingFileMessage.java:90) > ~[apache-cassandra-2.2.7.jar:2.2.7] > at > org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:48) > ~[apache-cassandra-2.2.7.jar:2.2.7] > at > org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:40) > ~[apache-cassandra-2.2.7.jar:2.2.7] > at > org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:47) > ~[apache-cassandra-2.2.7.jar:2.2.7] > at > org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:389) > ~[apache-cassandra-2.2.7 > .jar:2.2.7] > at > org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:361) > ~[apache-cassandra-2.2.7.jar:2.2.7] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101] > Caused by: java.io.IOException: Broken pipe > at sun.nio.ch.FileChannelImpl.transferTo0(Native Method) > ~[na:1.8.0_101] > at > sun.nio.ch.FileChannelImpl.transferToDirectlyInternal(FileChannelImpl.java:428) > ~[na:1.8.0_101] > at > sun.nio.ch.FileChannelImpl.transferToDirectly(FileChannelImpl.java:493) > ~[na:1.8.0_101] > at sun.nio.ch.FileChannelImpl.transferTo(FileChannelImpl.java:608) > ~[na:1.8.0_101] > at > org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:140) > ~[apache-cassandra-2.2.7.jar:2.2.7] > ... 11 common frames omitted > INFO [STREAM-OUT-/123.120.56.71] 2017-04-10 23:46:15,424 > StreamResultFuture.java:183 - [Stream #cbb7a150-1e47-11e7-a556-a98ec456f4de] > Session with / 123.120.56.71 > is complete > WARN [STREAM-OUT-/123.120.56.71] 2017-04-10 23:46:15,425 > StreamResultFuture.java:210 - [Stream #cbb7a150-1e47-11e7-a556-a98ec456f4de] > Stream failed -- 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-13710) Add a nodetool command to display details of any tables containing unowned tokens
[
https://issues.apache.org/jira/browse/CASSANDRA-13710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160700#comment-16160700
]
Varun Gupta commented on CASSANDRA-13710:
-
[~beobal] I want to work on this ticket, can you please assign this to me.
For implementation, I am thinking to support below three options.
* nodetool cleanup dry-run (prints tables for all the keyspaces)
* nodetool cleanup keyspace dry-run (prints tables for that particular
keyspace).
* nodetool cleanup keyspace table1 table2 dry-run (if the tables provided in
the list have unowned token ranges)
> Add a nodetool command to display details of any tables containing unowned
> tokens
> -
>
> Key: CASSANDRA-13710
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13710
> Project: Cassandra
> Issue Type: Sub-task
> Components: Observability, Tools
>Reporter: Sam Tunnicliffe
>
> This could be implemented as a {{dry-run}} switch for {{nodetool cleanup}}
--
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-13728) Provide max hint window as part of nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16148478#comment-16148478
]
Varun Gupta commented on CASSANDRA-13728:
-
I am good with skipping 3.0.
> Provide max hint window as part of nodetool
> ---
>
> Key: CASSANDRA-13728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13728
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Milan Milosevic
>Assignee: Varun Gupta
>Priority: Minor
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: Add-nodetool-cmd-to-print-hinted-handoff-window.patch
>
>
> Currently it is not possible to get max_hint_window over nodetool. The
> information is available through StorageProxyMBean, though. Since max hint
> window information is needed in order to asses what kind of failure recovery
> should be performed for a node that goes down (bootstrap or just restart), it
> would be handy if max hint window is easily accessible using nodetool.
> Currently nodetool statushandoff output is:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running
> {code}
> The output could be improved to look like this:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running with max hint window (ms): 1080
> {code}
> Implementation is quite trivial (fetch the info from the StorageProxyMBean
> from the StatusHandoff class). I can provide the patch for this, if it is
> agreed that this it right approach.
--
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-11334) Make compaction operations (scrub, etc) asynchronous
[
https://issues.apache.org/jira/browse/CASSANDRA-11334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137211#comment-16137211
]
Varun Gupta commented on CASSANDRA-11334:
-
[~michaelsembwever] Can you please review the patch?
> Make compaction operations (scrub, etc) asynchronous
>
>
> Key: CASSANDRA-11334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11334
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tools
>Reporter: Yuki Morishita
>Priority: Minor
> Fix For: 4.x
>
> Attachments: make-compaction-manager-return-Future.patch
>
>
> Prior to make nodetool to use JMX notification, we need to make scrub,
> verify, cleanup etc. to asynchronous.
> Right now, those operations block in {{CompactionManager}}, so instead we
> want to be able to get {{Future}} object that can be listened for completion.
--
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-11334) Make compaction operations (scrub, etc) asynchronous
[
https://issues.apache.org/jira/browse/CASSANDRA-11334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Gupta updated CASSANDRA-11334:
Attachment: make-compaction-manager-return-Future.patch
> Make compaction operations (scrub, etc) asynchronous
>
>
> Key: CASSANDRA-11334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11334
> Project: Cassandra
> Issue Type: Sub-task
> Components: Tools
>Reporter: Yuki Morishita
>Priority: Minor
> Fix For: 4.x
>
> Attachments: make-compaction-manager-return-Future.patch
>
>
> Prior to make nodetool to use JMX notification, we need to make scrub,
> verify, cleanup etc. to asynchronous.
> Right now, those operations block in {{CompactionManager}}, so instead we
> want to be able to get {{Future}} object that can be listened for completion.
--
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-13728) Provide max hint window as part of nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16133307#comment-16133307
]
Varun Gupta commented on CASSANDRA-13728:
-
[~jjirsa] Please find the updated patch!
> Provide max hint window as part of nodetool
> ---
>
> Key: CASSANDRA-13728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13728
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Milan Milosevic
>Assignee: Varun Gupta
>Priority: Minor
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: Add-nodetool-cmd-to-print-hinted-handoff-window.patch
>
>
> Currently it is not possible to get max_hint_window over nodetool. The
> information is available through StorageProxyMBean, though. Since max hint
> window information is needed in order to asses what kind of failure recovery
> should be performed for a node that goes down (bootstrap or just restart), it
> would be handy if max hint window is easily accessible using nodetool.
> Currently nodetool statushandoff output is:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running
> {code}
> The output could be improved to look like this:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running with max hint window (ms): 1080
> {code}
> Implementation is quite trivial (fetch the info from the StorageProxyMBean
> from the StatusHandoff class). I can provide the patch for this, if it is
> agreed that this it right approach.
--
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-13728) Provide max hint window as part of nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Gupta updated CASSANDRA-13728:
Attachment: Add-nodetool-cmd-to-print-hinted-handoff-window.patch
> Provide max hint window as part of nodetool
> ---
>
> Key: CASSANDRA-13728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13728
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Milan Milosevic
>Assignee: Varun Gupta
>Priority: Minor
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: Add-nodetool-cmd-to-print-hinted-handoff-window.patch
>
>
> Currently it is not possible to get max_hint_window over nodetool. The
> information is available through StorageProxyMBean, though. Since max hint
> window information is needed in order to asses what kind of failure recovery
> should be performed for a node that goes down (bootstrap or just restart), it
> would be handy if max hint window is easily accessible using nodetool.
> Currently nodetool statushandoff output is:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running
> {code}
> The output could be improved to look like this:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running with max hint window (ms): 1080
> {code}
> Implementation is quite trivial (fetch the info from the StorageProxyMBean
> from the StatusHandoff class). I can provide the patch for this, if it is
> agreed that this it right approach.
--
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-13728) Provide max hint window as part of nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Gupta updated CASSANDRA-13728:
Attachment: (was: display-max-hint-handoff-period.patch)
> Provide max hint window as part of nodetool
> ---
>
> Key: CASSANDRA-13728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13728
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Milan Milosevic
>Assignee: Varun Gupta
>Priority: Minor
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Currently it is not possible to get max_hint_window over nodetool. The
> information is available through StorageProxyMBean, though. Since max hint
> window information is needed in order to asses what kind of failure recovery
> should be performed for a node that goes down (bootstrap or just restart), it
> would be handy if max hint window is easily accessible using nodetool.
> Currently nodetool statushandoff output is:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running
> {code}
> The output could be improved to look like this:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running with max hint window (ms): 1080
> {code}
> Implementation is quite trivial (fetch the info from the StorageProxyMBean
> from the StatusHandoff class). I can provide the patch for this, if it is
> agreed that this it right approach.
--
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-13633) Data not loading to keyspace using sstable create via CQLSSTableWriter
[
https://issues.apache.org/jira/browse/CASSANDRA-13633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16131464#comment-16131464
]
Varun Gupta commented on CASSANDRA-13633:
-
[~arpanps] 3.11 supports loading UDT.
> Data not loading to keyspace using sstable create via CQLSSTableWriter
> --
>
> Key: CASSANDRA-13633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13633
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Linux
>Reporter: Arpan Khandelwal
> Fix For: 3.11.x
>
> Attachments: dataloading_result.png
>
>
> Scenario : Need to read CSV, Write SSTable using CQLSSTableWriter and load it
> to the keyspace. [Explained
> here|https://stackoverflow.com/questions/44713777/json-cassandra-field-value-parsing-using-antlr4]
> . That was not working so tried a simple test case available
> here[https://github.com/apache/cassandra/blob/cassandra-3.11/test/unit/org/apache/cassandra/io/sstable/CQLSSTableWriterTest.java#L378]
> Which did not worked either. Following is what i tried.
> Created cql_keyspace3 with below table and types.
> {code:java}
> CREATE TYPE cql_keyspace3.tuple2 (a int, b int);
> CREATE TYPE cql_keyspace3.tuple3 (a int, b int, c int)
> CREATE TABLE cql_keyspace3.table3 ( k int, v1 list, v2
> frozen, PRIMARY KEY (k));
> {code}
> ran code
> {code:java}
> final String KS = "cql_keyspace3";
> final String TABLE = "table3";
> final String schema = "CREATE TABLE " + KS + "." + TABLE + " (" + "
> k int," + " v1 list,"
> + " v2 frozen," + " PRIMARY KEY (k)" + ")";
> File tempdir = Files.createTempDir();
> File dataDir = new File(tempdir.getAbsolutePath() + File.separator +
> KS + File.separator + TABLE);
> System.out.println(dataDir);
> assert dataDir.mkdirs();
> CQLSSTableWriter writer =
> CQLSSTableWriter.builder().inDirectory(dataDir)
> .withType("CREATE TYPE " + KS + ".tuple2 (a int, b int)")
> .withType("CREATE TYPE " + KS + ".tuple3 (a int, b int, c
> int)").forTable(schema)
> .using("INSERT INTO " + KS + "." + TABLE + " (k, v1, v2) " +
> "VALUES (?, ?, ?)").build();
>
>
> UserType tuple2Type = writer.getUDType("tuple2");
> UserType tuple3Type = writer.getUDType("tuple3");
> for (int i = 0; i < 100; i++) {
> writer.addRow(i,
>
> ImmutableList.builder().add(tuple2Type.newValue().setInt("a", i *
> 10).setInt("b", i * 20))
> .add(tuple2Type.newValue().setInt("a", i *
> 30).setInt("b", i * 40)).build(),
> tuple3Type.newValue().setInt("a", i * 100).setInt("b", i
> * 200).setInt("c", i * 300));
> }
> writer.close();
> {code}
> It generated sstable in "/tmp/1498224996687-0/cql_keyspace3" dir
> Loaded data using following command
> {code:java}
> /tmp/1498224996687-0/cql_keyspace3 $ sstableloader -d localhost
> table3-e6e0fa61581911e78be6a72ebce4c745/
> Established connection to initial hosts
> Opening sstables and calculating sections to stream
> Streaming relevant part of
> /tmp/1498224996687-0/cql_keyspace3/table3-e6e0fa61581911e78be6a72ebce4c745/mc-2-big-Data.db
> to [localhost/127.0.0.1]
> progress: [localhost/127.0.0.1]0:1/1 100% total: 100% 1.060KiB/s (avg:
> 1.060KiB/s)
> progress: [localhost/127.0.0.1]0:1/1 100% total: 100% 0.000KiB/s (avg:
> 0.984KiB/s)
> Summary statistics:
>Connections per host: 1
>Total files transferred : 1
>Total bytes transferred : 5.572KiB
>Total duration : 5668 ms
>Average transfer rate : 0.982KiB/s
>Peak transfer rate : 1.060KiB/s
> {code}
> ||k||v1||v2||
> |92|[{a:920,b:1840}, {a:2760,b:3680}]|
> find full result in attached snapshot.
> Please let me know which version of cassandra I should which can allow me to
> load reseverd types, collections, UDT from sstable create using
> CQLSSTableWriter.
--
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-13728) Provide max hint window as part of nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Gupta updated CASSANDRA-13728:
Attachment: display-max-hint-handoff-period.patch
> Provide max hint window as part of nodetool
> ---
>
> Key: CASSANDRA-13728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13728
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Milan Milosevic
>Priority: Minor
> Labels: lhf
> Fix For: 3.0.15, 3.11.1
>
> Attachments: display-max-hint-handoff-period.patch
>
>
> Currently it is not possible to get max_hint_window over nodetool. The
> information is available through StorageProxyMBean, though. Since max hint
> window information is needed in order to asses what kind of failure recovery
> should be performed for a node that goes down (bootstrap or just restart), it
> would be handy if max hint window is easily accessible using nodetool.
> Currently nodetool statushandoff output is:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running
> {code}
> The output could be improved to look like this:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running with max hint window (ms): 1080
> {code}
> Implementation is quite trivial (fetch the info from the StorageProxyMBean
> from the StatusHandoff class). I can provide the patch for this, if it is
> agreed that this it right approach.
--
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-13728) Provide max hint window as part of nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16131358#comment-16131358
]
Varun Gupta commented on CASSANDRA-13728:
-
[~jasobrown] can you please review the patch?
> Provide max hint window as part of nodetool
> ---
>
> Key: CASSANDRA-13728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13728
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Milan Milosevic
>Priority: Minor
> Labels: lhf
> Fix For: 3.0.15, 3.11.1
>
> Attachments: display-max-hint-handoff-period.patch
>
>
> Currently it is not possible to get max_hint_window over nodetool. The
> information is available through StorageProxyMBean, though. Since max hint
> window information is needed in order to asses what kind of failure recovery
> should be performed for a node that goes down (bootstrap or just restart), it
> would be handy if max hint window is easily accessible using nodetool.
> Currently nodetool statushandoff output is:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running
> {code}
> The output could be improved to look like this:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running with max hint window (ms): 1080
> {code}
> Implementation is quite trivial (fetch the info from the StorageProxyMBean
> from the StatusHandoff class). I can provide the patch for this, if it is
> agreed that this it right approach.
--
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-12576) Setting read_request_timeout_in_ms more than one day causes login fails
[
https://issues.apache.org/jira/browse/CASSANDRA-12576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15987348#comment-15987348
]
Varun Gupta commented on CASSANDRA-12576:
-
I am able to cqlsh with read timeout value of 5. I am using version
3.0.11.
Which version of cassandra are you using?
> Setting read_request_timeout_in_ms more than one day causes login fails
> ---
>
> Key: CASSANDRA-12576
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12576
> Project: Cassandra
> Issue Type: Bug
> Components: Configuration
> Environment: Distro: "Debian GNU/Linux 8 (jessie)"
> cqlsh -u kartaca -p kartaca -e "select release_version from system.local;" =>
> 3.5
>
>Reporter: Erol GUZOĞLU
>Priority: Trivial
>
> I try to run "select count( * )" query
> To make query success, I set read_request_timeout_in_ms random big number
> then restart the service.
> When node is UN, login fails started.
> When I try to login cassandra, I came up with this irrelevant error.
> Connection error: ('Unable to connect to any servers', {'127.0.0.1':
> error(111, "Tried connecting to [('127.0.0.1',│
> 9042)]. Last error: Connection refused")})
> It probably occur when setting number bigger than one day. Because when I set
> 5 (~5.7 day) can not login but if i set 5000 (~0.5 day) login
> success.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-13479) Create schema file for keyspace as a part of snapshot
Varun Gupta created CASSANDRA-13479: --- Summary: Create schema file for keyspace as a part of snapshot Key: CASSANDRA-13479 URL: https://issues.apache.org/jira/browse/CASSANDRA-13479 Project: Cassandra Issue Type: Improvement Components: Schema Reporter: Varun Gupta Priority: Minor Fix For: 3.0.14 As of now, snapshot process create schema.cql file per column family. Restoring to new cluster is not feasible if keyspace schema is not present. So similar to schema.cql file created for each column family, a different schema.cql file should be created for keyspace too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-7545) Hints for a down node are written to a single partition in system.hints on the coordinator leading to contention
[ https://issues.apache.org/jira/browse/CASSANDRA-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15536742#comment-15536742 ] Varun Gupta commented on CASSANDRA-7545: Is writing hints to flat file rather system.hints available on 2.2.X version. Or a patch which I can locally apply? > Hints for a down node are written to a single partition in system.hints on > the coordinator leading to contention > > > Key: CASSANDRA-7545 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7545 > Project: Cassandra > Issue Type: Bug >Reporter: graham sanderson > > The worst side effect is potentially orders of magnitude larger than > suspected memory allocation due to a race condition updating the columns in > the memtable (see CASSANDRA-7546) > That said, having so many hints in a single partition has other negative side > effects (non linear growth of sorted tree data structure overhead in > memtable, just plain large number of tombstones in a row etc.) > Ideally, the hints would be partitioned by both the nodeUUID, and a fixed > number of (say 4) bits of a hash of the original rowmutation's partition > key... even this small spreading of load has a significant improvement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7190) Add schema to snapshot manifest
[ https://issues.apache.org/jira/browse/CASSANDRA-7190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Gupta updated CASSANDRA-7190: --- Status: Ready to Commit (was: Patch Available) > Add schema to snapshot manifest > --- > > Key: CASSANDRA-7190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7190 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Jonathan Ellis >Assignee: Alex Petrov >Priority: Minor > Labels: client-impacting, doc-impacting, lhf > Fix For: 3.10, 3.0.x > > > followup from CASSANDRA-6326 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12433) Create schema backup
[ https://issues.apache.org/jira/browse/CASSANDRA-12433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Gupta updated CASSANDRA-12433: Description: Currently cassandra support taking snapshot. Add feature to create a new schema directory per node and dump current schema per keyspace into it. (was: Currently cassandra support taking snapshot. Add feature to create a new schema directory per node and take dump current schema per keyspace into it.) > Create schema backup > > > Key: CASSANDRA-12433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12433 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Varun Gupta >Priority: Minor > Fix For: 2.2.x > > > Currently cassandra support taking snapshot. Add feature to create a new > schema directory per node and dump current schema per keyspace into it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12433) Create schema backup
[ https://issues.apache.org/jira/browse/CASSANDRA-12433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Gupta updated CASSANDRA-12433: Description: Currently cassandra support taking snapshot. Add feature to create a new schema directory per node and take dump current schema per keyspace into it. (was: Currently cassandra support taking snapshot. A feature to create a new schema directory per node and take dump current schema per keyspace into it.) > Create schema backup > > > Key: CASSANDRA-12433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12433 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Varun Gupta >Priority: Minor > Fix For: 2.2.x > > > Currently cassandra support taking snapshot. Add feature to create a new > schema directory per node and take dump current schema per keyspace into it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12433) Create schema backup
Varun Gupta created CASSANDRA-12433: --- Summary: Create schema backup Key: CASSANDRA-12433 URL: https://issues.apache.org/jira/browse/CASSANDRA-12433 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Varun Gupta Priority: Minor Fix For: 2.2.x Currently cassandra support taking snapshot. A feature to create a new schema directory per node and take dump current schema per keyspace into it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
