[jira] [Commented] (CASSANDRA-11462) IncomingStreamingConnection version check message wrong
[
https://issues.apache.org/jira/browse/CASSANDRA-11462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15223527#comment-15223527
]
Ryan Magnusson commented on CASSANDRA-11462:
[~snazy], how does it look now?
> IncomingStreamingConnection version check message wrong
> ---
>
> Key: CASSANDRA-11462
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11462
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
>Priority: Trivial
>
> If compares against {{StreamMessage.CURRENT_VERSION}} but prints
> {{MessagingService.current_version}}. The error message is confusing tho.
> {code}
> if (version != StreamMessage.CURRENT_VERSION)
> throw new IOException(String.format("Received stream using
> protocol version %d (my version %d). Terminating connection", version,
> MessagingService.current_version));
> {code}
> EDIT: That message is only printed at debug log level
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11462) IncomingStreamingConnection version check message wrong
[
https://issues.apache.org/jira/browse/CASSANDRA-11462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Magnusson updated CASSANDRA-11462:
---
Status: Patch Available (was: Open)
> IncomingStreamingConnection version check message wrong
> ---
>
> Key: CASSANDRA-11462
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11462
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
>Priority: Trivial
>
> If compares against {{StreamMessage.CURRENT_VERSION}} but prints
> {{MessagingService.current_version}}. The error message is confusing tho.
> {code}
> if (version != StreamMessage.CURRENT_VERSION)
> throw new IOException(String.format("Received stream using
> protocol version %d (my version %d). Terminating connection", version,
> MessagingService.current_version));
> {code}
> EDIT: That message is only printed at debug log level
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11462) IncomingStreamingConnection version check message wrong
[
https://issues.apache.org/jira/browse/CASSANDRA-11462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15223076#comment-15223076
]
Ryan Magnusson commented on CASSANDRA-11462:
Updated this quick fix here:
[11462-trunk|https://github.com/RyanMagnusson/cassandra/tree/11462-trunk].
> IncomingStreamingConnection version check message wrong
> ---
>
> Key: CASSANDRA-11462
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11462
> Project: Cassandra
> Issue Type: Bug
>Reporter: Robert Stupp
>Priority: Trivial
>
> If compares against {{StreamMessage.CURRENT_VERSION}} but prints
> {{MessagingService.current_version}}. The error message is confusing tho.
> {code}
> if (version != StreamMessage.CURRENT_VERSION)
> throw new IOException(String.format("Received stream using
> protocol version %d (my version %d). Terminating connection", version,
> MessagingService.current_version));
> {code}
> EDIT: That message is only printed at debug log level
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-5992) Add a logger.trace call to Tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15223047#comment-15223047 ] Ryan Magnusson commented on CASSANDRA-5992: --- Was this change ever committed? > Add a logger.trace call to Tracing > -- > > Key: CASSANDRA-5992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5992 > Project: Cassandra > Issue Type: Improvement >Reporter: Jeremiah Jordan >Priority: Minor > Labels: lhf > Attachments: CASSANDRA-5992.txt > > > A bunch of stuff is now written to Tracing, and there are no logging trace > calls any more. If a node is having issues on the read/write path and > tracing can't actually save data, there is no way to see through logging what > is going on. Would be nice if we made all Tracing messages also go out at > logger.trace so that you could enable that to debug stuff. > Being able to change the RF of the system_traces KS might also help here, but > there would still be classes of problems that it would be good to have the > logging there for. Added CASSANDRA-6016 for that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11402) Alignment wrong in tpstats output for PerDiskMemtableFlushWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Magnusson updated CASSANDRA-11402: --- Status: Patch Available (was: Open) > Alignment wrong in tpstats output for PerDiskMemtableFlushWriter > > > Key: CASSANDRA-11402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11402 > Project: Cassandra > Issue Type: Bug >Reporter: Joel Knighton >Priority: Trivial > Labels: lhf > Attachments: 11402-trunk.txt > > > With the accompanying designation of which memtableflushwriter it is, this > threadpool name is too long for the hardcoded padding in tpstats output. > We should dynamically calculate padding so that we don't need to check this > every time we add a threadpool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11402) Alignment wrong in tpstats output for PerDiskMemtableFlushWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15220338#comment-15220338 ] Ryan Magnusson commented on CASSANDRA-11402: Please let me know if this looks correct. I've also uploaded my changes to github @ https://github.com/RyanMagnusson/cassandra/tree/11402-3.0 > Alignment wrong in tpstats output for PerDiskMemtableFlushWriter > > > Key: CASSANDRA-11402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11402 > Project: Cassandra > Issue Type: Bug >Reporter: Joel Knighton >Priority: Trivial > Labels: lhf > Attachments: 11402-trunk.txt > > > With the accompanying designation of which memtableflushwriter it is, this > threadpool name is too long for the hardcoded padding in tpstats output. > We should dynamically calculate padding so that we don't need to check this > every time we add a threadpool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11402) Alignment wrong in tpstats output for PerDiskMemtableFlushWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Magnusson updated CASSANDRA-11402: --- Attachment: 11402-trunk.txt > Alignment wrong in tpstats output for PerDiskMemtableFlushWriter > > > Key: CASSANDRA-11402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11402 > Project: Cassandra > Issue Type: Bug >Reporter: Joel Knighton >Priority: Trivial > Labels: lhf > Attachments: 11402-trunk.txt > > > With the accompanying designation of which memtableflushwriter it is, this > threadpool name is too long for the hardcoded padding in tpstats output. > We should dynamically calculate padding so that we don't need to check this > every time we add a threadpool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11402) Alignment wrong in tpstats output for PerDiskMemtableFlushWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Magnusson updated CASSANDRA-11402: --- Attachment: (was: 11402-trunk.txt) > Alignment wrong in tpstats output for PerDiskMemtableFlushWriter > > > Key: CASSANDRA-11402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11402 > Project: Cassandra > Issue Type: Bug >Reporter: Joel Knighton >Priority: Trivial > Labels: lhf > > With the accompanying designation of which memtableflushwriter it is, this > threadpool name is too long for the hardcoded padding in tpstats output. > We should dynamically calculate padding so that we don't need to check this > every time we add a threadpool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11402) Alignment wrong in tpstats output for PerDiskMemtableFlushWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Magnusson updated CASSANDRA-11402: --- Attachment: 11402-trunk.txt > Alignment wrong in tpstats output for PerDiskMemtableFlushWriter > > > Key: CASSANDRA-11402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11402 > Project: Cassandra > Issue Type: Bug >Reporter: Joel Knighton >Priority: Trivial > Labels: lhf > Attachments: 11402-trunk.txt > > > With the accompanying designation of which memtableflushwriter it is, this > threadpool name is too long for the hardcoded padding in tpstats output. > We should dynamically calculate padding so that we don't need to check this > every time we add a threadpool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-5992) Add a logger.trace call to Tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14662457#comment-14662457 ] Ryan Magnusson edited comment on CASSANDRA-5992 at 8/7/15 9:09 PM: --- adding calls to logger.trace whenever Tracing.trace is called as well as where tracing is done inside TraceState as well. was (Author: ryanmagnusson): add logger.trace whenever Tracing.trace is called. > Add a logger.trace call to Tracing > -- > > Key: CASSANDRA-5992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5992 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jeremiah Jordan >Priority: Minor > Labels: lhf > Fix For: 2.0.x > > Attachments: CASSANDRA-5992.txt > > > A bunch of stuff is now written to Tracing, and there are no logging trace > calls any more. If a node is having issues on the read/write path and > tracing can't actually save data, there is no way to see through logging what > is going on. Would be nice if we made all Tracing messages also go out at > logger.trace so that you could enable that to debug stuff. > Being able to change the RF of the system_traces KS might also help here, but > there would still be classes of problems that it would be good to have the > logging there for. Added CASSANDRA-6016 for that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-5992) Add a logger.trace call to Tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Magnusson updated CASSANDRA-5992: -- Attachment: CASSANDRA-5992.txt add logger.trace whenever Tracing.trace is called. > Add a logger.trace call to Tracing > -- > > Key: CASSANDRA-5992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5992 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jeremiah Jordan >Priority: Minor > Labels: lhf > Fix For: 2.0.x > > Attachments: CASSANDRA-5992.txt > > > A bunch of stuff is now written to Tracing, and there are no logging trace > calls any more. If a node is having issues on the read/write path and > tracing can't actually save data, there is no way to see through logging what > is going on. Would be nice if we made all Tracing messages also go out at > logger.trace so that you could enable that to debug stuff. > Being able to change the RF of the system_traces KS might also help here, but > there would still be classes of problems that it would be good to have the > logging there for. Added CASSANDRA-6016 for that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8777) Streaming operations should log both endpoint and port associated with the operation
[ https://issues.apache.org/jira/browse/CASSANDRA-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651892#comment-14651892 ] Ryan Magnusson edited comment on CASSANDRA-8777 at 8/3/15 2:24 PM: --- Thanks @Gary Dusbabek. Is there any reservation from the group with using InetSocketAddress instead of just InetAddress with Stream operations? was (Author: ryanmagnusson): Thanks Gary Dusbabek. Is there any reservation from the group with using InetSocketAddress instead of just InetAddress with Stream operations? > Streaming operations should log both endpoint and port associated with the > operation > > > Key: CASSANDRA-8777 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8777 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jeremy Hanna > Labels: lhf > Fix For: 2.1.x > > > Currently we log the endpoint for a streaming operation. If the port has > been overridden, it would be valuable to know that that setting is getting > picked up. Therefore, when logging the endpoint address, it would be nice to > also log the port it's trying to use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8777) Streaming operations should log both endpoint and port associated with the operation
[ https://issues.apache.org/jira/browse/CASSANDRA-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651892#comment-14651892 ] Ryan Magnusson edited comment on CASSANDRA-8777 at 8/3/15 2:24 PM: --- Thanks [~gdusbabek] Is there any reservation from the group with using InetSocketAddress instead of just InetAddress with Stream operations? was (Author: ryanmagnusson): Thanks @Gary Dusbabek. Is there any reservation from the group with using InetSocketAddress instead of just InetAddress with Stream operations? > Streaming operations should log both endpoint and port associated with the > operation > > > Key: CASSANDRA-8777 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8777 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jeremy Hanna > Labels: lhf > Fix For: 2.1.x > > > Currently we log the endpoint for a streaming operation. If the port has > been overridden, it would be valuable to know that that setting is getting > picked up. Therefore, when logging the endpoint address, it would be nice to > also log the port it's trying to use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8777) Streaming operations should log both endpoint and port associated with the operation
[ https://issues.apache.org/jira/browse/CASSANDRA-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651892#comment-14651892 ] Ryan Magnusson commented on CASSANDRA-8777: --- Thanks Gary Dusbabek. Is there any reservation from the group with using InetSocketAddress instead of just InetAddress with Stream operations? > Streaming operations should log both endpoint and port associated with the > operation > > > Key: CASSANDRA-8777 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8777 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jeremy Hanna > Labels: lhf > Fix For: 2.1.x > > > Currently we log the endpoint for a streaming operation. If the port has > been overridden, it would be valuable to know that that setting is getting > picked up. Therefore, when logging the endpoint address, it would be nice to > also log the port it's trying to use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8777) Streaming operations should log both endpoint and port associated with the operation
[ https://issues.apache.org/jira/browse/CASSANDRA-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14649328#comment-14649328 ] Ryan Magnusson commented on CASSANDRA-8777: --- I would like to take this on, but have some questions to clarify the request. The description says that "we currently log the endpoint for a streaming operation", but in the example provided I only see the planId being shown. I see in some parts of the code we do log out InetAddress, but it isn't in the example provided. Is the goal of this task to also add the address to messages for stream operations where it currently is not shown? > Streaming operations should log both endpoint and port associated with the > operation > > > Key: CASSANDRA-8777 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8777 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jeremy Hanna > Labels: lhf > Fix For: 2.1.x > > > Currently we log the endpoint for a streaming operation. If the port has > been overridden, it would be valuable to know that that setting is getting > picked up. Therefore, when logging the endpoint address, it would be nice to > also log the port it's trying to use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
