You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stu Hood (JIRA)" <ji...@apache.org> on 2011/06/24 03:13:47 UTC
[jira] [Created] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Split rpc timeout for read and write ops
----------------------------------------
Key: CASSANDRA-2819
URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Stu Hood
Fix For: 1.0
Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058684#comment-13058684 ]
Melvin Wang commented on CASSANDRA-2819:
----------------------------------------
how about add the creation timestamp to the header of the message? MDT is executed nearly immediately after it is created. Thus the construction time of MDT is too close to the checkpoint we have in run(). I am just concerned with the effectiveness of the current logic in MDT, although I am not sure about the consequences of adding 4 bytes to all the messages we created.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Vijay (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399041#comment-13399041 ]
Vijay commented on CASSANDRA-2819:
----------------------------------
{quote}
The target can be null when the host is killed before it fires
{quote}
I think the NPE is because CallbackInfo.sentMessage is null right?
i think it is better to move store the timeout value in the CallbackInfo...
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Jonathan Ellis
> Fix For: 1.2
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058715#comment-13058715 ]
Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------
Let's keep the scope of this ticket to splitting the rpc timeout. We can open another for "make request dropping more accurate/aggressive."
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058176#comment-13058176 ]
Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------
We check before processing to see if we can skip it entirely; probably not worth doing another check after processing too.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-timeouts-per-verb.diff
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058212#comment-13058212 ]
Melvin Wang commented on CASSANDRA-2819:
----------------------------------------
sure. However, the current logic in MessageDeliveryTask doesnt seem right. It compares against the creation time of MessageDeliveryTask itself. I added the creation time to Message class to address this.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Vijay (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398605#comment-13398605 ]
Vijay commented on CASSANDRA-2819:
----------------------------------
+1
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.1.2
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: (was: rpc-rw-timeouts.patch)
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-timeouts-per-verb.diff
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131256#comment-13131256 ]
Melvin Wang commented on CASSANDRA-2819:
----------------------------------------
bq. Writes still use the old rpc_timeout
Changed to getWriteRpcTimeout()
bq. looks like most remaining uses of old rpc_timeout should really be max(different timeouts)
wanna modify the getRpcTimeout in DD so that it returns the max of the other get*RpcTimeout()?
bq. currently, expiring map checks callbacks for expiration every 1/2 of default timeout. This means short timeouts could go much longer than desired, before being cancelled. I see two options: go back to direct await(timeout) in the callback/response handlers, or update EM to scan much more frequently (which could burn a lot of CPU for a system with many outstanding callbacks)
Not a so elegant solution in this patch. It uses the corresponding get*RpcTimeout in different callbacks.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0.1
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, c2819-v6, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: (was: rpc-timeouts-per-verb.diff)
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: (was: rpc-jira.patch)
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071729#comment-13071729 ]
Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------
Are you still working on this, Melvin?
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: (was: rpc-jira.patch)
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: c2819.patch
make ReadCallback, RepairCallback cancellable through timeoutReporter;
make it possible to get the timeout value by verb so that DroppableRunnable can drop according to different verbs.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: 2819-v4.txt, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131145#comment-13131145 ]
Melvin Wang commented on CASSANDRA-2819:
----------------------------------------
bq. - currently, expiring map checks callbacks for expiration every 1/2 of default timeout. This means short timeouts could go much longer than desired, before being cancelled. I see two options: go back to direct await(timeout) in the callback/response handlers, or update EM to scan much more frequently (which could burn a lot of CPU for a system with many outstanding callbacks)
yeah, i guess, calling getReadRpcTimeout/getWriteRpcTimeout explicitly in ReadCallback/RepairCallback would be simpler and more correct.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0.1
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058539#comment-13058539 ]
Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------
That is the wrong place for it because Message is used both to send and to receive. MDT creation time is effectively identical.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang reassigned CASSANDRA-2819:
--------------------------------------
Assignee: Melvin Wang
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: (was: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff)
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13089951#comment-13089951 ]
Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------
Sounds reasonable to me.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: 2819-v4.txt, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: rpc-jira.patch
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073317#comment-13073317 ]
Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------
(reverted)
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-2819.
---------------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.1.2)
1.2
Committed to trunk. I'm okay with backporting to 1.1 should someone step up to do that; my quick look is that it should be straightforward but not automatic (runs into things like the underscore removal).
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.2
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams reopened CASSANDRA-2819:
-----------------------------------------
Assignee: Jonathan Ellis (was: Melvin Wang)
The target can be null when the host is killed before it fires:
{noformat}
ERROR [EXPIRING-MAP-REAPER:1] 2012-06-21 15:55:27,708 AbstractCassandraDaemon.java (line 133) Exception in thread Thread[EXPIRING-MAP-REAPER:1,5,main]
java.lang.NullPointerException
at org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:326)
at org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:322)
at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:99)
at org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:75)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{noformat}
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Jonathan Ellis
> Fix For: 1.2
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-2819:
--------------------------------------
Attachment: 2819-v4.txt
v4 attached (against trunk), with compilation fixes.
Looks like it needs another check for uses of DD.getRpcTimeout. Here are some suspicious ones:
- MS.timeoutReporter
- ReadCallback
- RepairCallback
- StorageProxy.DroppableRunnable
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: 2819-v4.txt, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: rpc-jira.patch
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073795#comment-13073795 ]
Melvin Wang commented on CASSANDRA-2819:
----------------------------------------
looks like readcallback, repaircallback, abstractWriteresponseHandler all assume the timeout value from getRpcTimeout(); however with this patch, ExpiringMap will timeout different messages with different values, so we may have situation where expiringMap already expires the message while the get() still blocks if we have different read_rpc_timeout/write_rpc_timeout with the 'default' rpc timeout. I'm wondering if we could modify the IAsyncCallback so that we expiringMap expires a message, it will signal the callback and mark it as a failure, and hence in get() we don't need to have the logic to track the timeout.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: 2819-v4.txt, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060125#comment-13060125 ]
Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------
(that's CASSANDRA-2858)
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058103#comment-13058103 ]
Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------
Why not just do a lookup base on verb type which is already part of Message?
OTC should probably hardcode something reasonable, no reason for it to be related to RPC calls.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-rw-timeouts.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058113#comment-13058113 ]
Melvin Wang commented on CASSANDRA-2819:
----------------------------------------
yep, a simple look up will do. I guess I was confused by Request_Response messages. When we create request_response we don't record which type of message it replies to so in MessageDeliveryTask it's difficult to figure it out. Thus I wanted some way to associate the info to the request_response messages so that we could better time them out in MessageDeliveryTask. This is certainly complicated.
Also in OutboundTcpConnection we better honor the per-verb timeout as well by providing a way to set the timeout value before we try to connect. If we want to hardcode, then it needs to be the max of (read, range read, write) since it lies on the path of these operations.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-rw-timeouts.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: c2819-v7
Please take another look. Following changes made
* CassandraServer.java, set the timeout when we schedule individual Rpcs
* outboundtcpconnection uses per message timeout.
there are still couple of places undetermined.
* FailureDetector.java:249, we need a getGossipTimeout() here?
* MessagingService.java, in expiringMap we probably want getMaxRpcTimeout()
* StorageService.java:sendReplicationNotification()/truncateResponseHander/FileStreamTask, we use getGenericRpcTimeout()?
* StorageProxy.java, 3 waitOnFutures calls for repairs, they should bear the timeout of the enclosing call?
* StorageProxy.java, describeSchema and truncate should use getGenericRpcTimeout()?
* OutboundTcpConnection.java, in connect(), shall we have a getSocketTimeout() or use getGenericRpcTimeout()?
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.1
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098324#comment-13098324 ]
Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------
Melvin, are you still working on this?
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: 2819-v4.txt, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-2819:
--------------------------------------
Reviewer: vijay2win@yahoo.com (was: jbellis)
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Jonathan Ellis
> Fix For: 1.2
>
> Attachments: 0001-additional-fix-for-2819.patch, 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073266#comment-13073266 ]
Melvin Wang commented on CASSANDRA-2819:
----------------------------------------
getMessageTimeout moved to Message.java
set the default value for the timeouts to be 10s in Config.java
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073323#comment-13073323 ]
Melvin Wang commented on CASSANDRA-2819:
----------------------------------------
fix the calling sendrr in bootstrapper.java
need another integration?
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073319#comment-13073319 ]
Hudson commented on CASSANDRA-2819:
-----------------------------------
Integrated in Cassandra #988 (See [https://builds.apache.org/job/Cassandra/988/])
split rpc_timeout into read,write, scan, and "other" timeouts
patch by Melvin Wang; reviewed by jbellis for CASSANDRA-2819
jbellis : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1152541
Files :
* /cassandra/trunk/src/java/org/apache/cassandra/net/MessagingService.java
* /cassandra/trunk/CHANGES.txt
* /cassandra/trunk/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
* /cassandra/trunk/conf/cassandra.yaml
* /cassandra/trunk/src/java/org/apache/cassandra/net/Message.java
* /cassandra/trunk/src/java/org/apache/cassandra/config/Config.java
* /cassandra/trunk/src/java/org/apache/cassandra/net/MessageDeliveryTask.java
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399052#comment-13399052 ]
Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------
We already have the timeout info in the EM entry, probably simplest to just pass that to the reporter method instead of storing it redundantly in the callback as well.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Jonathan Ellis
> Fix For: 1.2
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: rpc-timeouts-per-verb.diff
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-timeouts-per-verb.diff
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-2819.
---------------------------------------
Resolution: Fixed
lgtm, committed
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Jonathan Ellis
> Fix For: 1.2
>
> Attachments: 0001-additional-fix-for-2819.patch, 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: rpc-jira.patch
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151611#comment-13151611 ]
Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------
bq. wanna modify the getRpcTimeout in DD so that it returns the max of the other get*RpcTimeout()?
I think we need to split it into getGenericRpcTimeout (getMiscellaneousRpcTimeout?) and getMaxRpcTimeout.
bq. Not a so elegant solution in this patch. It uses the corresponding get*RpcTimeout in different callbacks.
looks good to me.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.1
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, c2819-v6, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-2819) Split rpc timeout for read
and write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398692#comment-13398692 ]
Jonathan Ellis edited comment on CASSANDRA-2819 at 6/21/12 6:20 PM:
--------------------------------------------------------------------
Committed to trunk. I'm okay with backporting to 1.1 should someone step up to do that for 1.1.2; my quick look is that it should be straightforward but not automatic (runs into things like the underscore removal).
was (Author: jbellis):
Committed to trunk. I'm okay with backporting to 1.1 should someone step up to do that; my quick look is that it should be straightforward but not automatic (runs into things like the underscore removal).
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.2
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.patch
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: rpc-rw-timeouts.patch
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-rw-timeouts.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073112#comment-13073112 ]
Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------
Thanks, Melvin!
should we move MS.getMessageTimeout to an instance method of Message? This would make per-Message timeouts easier in the future as well.
Let's make the default values in Config 10s as well, to avoid surprising people who upgrade but keep their old config file around.
Otherwise LGTM.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-2819:
--------------------------------------
Attachment: 2819-v8.txt
v8 adds truncate timeout and rebases.
I don't think separate gossip or socket timeouts are crucial. Happy to leave them using the generic one.
Updated the repair waits to use write timeout.
Still todo:
- handle expiringmap somehow. max(timeouts) would be technically correct but with truncate taking a (much) longer timeout (since it has to wait for compaction to finish), that could leave a lot of garbage in the map
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.1.1
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058101#comment-13058101 ]
Melvin Wang commented on CASSANDRA-2819:
----------------------------------------
a better way to go would be that we make the timeout part of Message obj so that when adding callback in MessagingService, we can pass in proper timeout to ExpiringMap and also in MessageDeliveryTask we can drop the message based on its own timeout. Not sure how complicated this is would be though.
OutboundTcpConnection uses getRpcTimeout during connection which is a surprise to me.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-rw-timeouts.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072953#comment-13072953 ]
Melvin Wang commented on CASSANDRA-2819:
----------------------------------------
Sorry for the waiting. I reverted the changes I made to Message.java and MessageDeliveryTask.java while keep the changes elsewhere. This is based on the previous discussions where we a separate ticket to make the timeout more accurate.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399042#comment-13399042 ]
Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------
Right. This is broken, reverted.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Jonathan Ellis
> Fix For: 1.2
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058144#comment-13058144 ]
Melvin Wang commented on CASSANDRA-2819:
----------------------------------------
scratch my comments about the OTC part. It is not true. What I want is a checkpoint after the server has processed the verb where we check if we are already timed out so that we won't bother to use the network bandwidth to send back the response. I will move this logic into MessagingService.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-timeouts-per-verb.diff
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Vijay (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vijay updated CASSANDRA-2819:
-----------------------------
Attachment: 0001-additional-fix-for-2819.patch
Fix for NPE.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Jonathan Ellis
> Fix For: 1.2
>
> Attachments: 0001-additional-fix-for-2819.patch, 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Ryan King (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060119#comment-13060119 ]
Ryan King commented on CASSANDRA-2819:
--------------------------------------
Opened https://issues.apache.org/jira/browse/CASSANDRA-2819 for the followup.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis reopened CASSANDRA-2819:
---------------------------------------
Sorry, it applied (almost) cleanly to trunk so I thought we were good, but it creates problems with the CASSANDRA-2644 code.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-2819:
--------------------------------------
Attachment: 2819-v9.txt
I was thinking about this wrong... we actually want to set up the EM with min(timeouts); as long as most of the operations are reasonably close to that, we'll be fine. Which, since the main outlier for us are truncates which are relatively rare, matches our requirements nicely.
v9 attached with that added.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.1.2
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, 2819-v8.txt, 2819-v9.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072464#comment-13072464 ]
Stu Hood commented on CASSANDRA-2819:
-------------------------------------
He is, but he's out sick: we'll post something soon.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: c2819-v6
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0.1
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, c2819-v6, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-2819:
--------------------------------------
Attachment: 2819-v5-rebased.txt
rebased to trunk. (IAsyncCancellableCallback is not included in the patch, so I took my best guess at one.)
Comments:
- Writes still use the old rpc_timeout
- would prefer to rename old rpc_timeout to other_rpc_timout and comment what it's used for (truncate, ?)
- looks like most remaining uses of old rpc_timeout should really be max(different timeouts)
- currently, expiring map checks callbacks for expiration every 1/2 of default timeout. This means short timeouts could go much longer than desired, before being cancelled. I see two options: go back to direct await(timeout) in the callback/response handlers, or update EM to scan much more frequently (which could burn a lot of CPU for a system with many outstanding callbacks)
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0.1
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2819) Split rpc timeout
for read and write ops
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13054201#comment-13054201 ]
Stu Hood edited comment on CASSANDRA-2819 at 6/24/11 1:14 AM:
--------------------------------------------------------------
This issue relates to 959, which additionally proposed splitting out timeouts for multi-row operations, which is slightly more challenging. EDIT: And not worth doing here, imo.
was (Author: stuhood):
This issue relates to 959, which additionally proposed splitting out timeouts for multi-row operations, which is slightly more challenging.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Fix For: 1.0
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057575#comment-13057575 ]
Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------
- read_repair is a write and should use that timeout
- should distinguish b/t multirow (range/index) reads, and single-row lookups
- REQUEST_RESPONSE should drop based on what kind of query the request being responded to was
- ExpiringMap should use expiration of max (read, read multirow, write)
- which means the REQUEST_RESPONSE drop-messages block isn't entirely redundant wrt ExpiringMap, but if it's too difficult to look up what the message type was it's probably not a big deal to ignore
- DD.getRpcTimeout should be removed and replace w/ the appropriate op timeout. If there are any internal operations that rely on rpctimeout (can't think of any that do) then we may want to add an "internal" timeout as well. (Or it may be evidence of a bug and we should fix it.)
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-rw-timeouts.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073781#comment-13073781 ]
Melvin Wang commented on CASSANDRA-2819:
----------------------------------------
In MS.timeoutReporter, we blindly add default rpc timeout as the latency. Since different messages may have different timeout now, in ExpiringMap.CacheMonitor, probably we need to pass the individual expiration time when we call apply().
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: 2819-v4.txt, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Melvin Wang updated CASSANDRA-2819:
-----------------------------------
Attachment: (was: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.patch)
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Chris Goffinet (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13198109#comment-13198109 ]
Chris Goffinet commented on CASSANDRA-2819:
-------------------------------------------
We really want to get this in 1.1, can we get some feedback?
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.1
>
> Attachments: 2819-v4.txt, 2819-v5-rebased.txt, c2819-v6, c2819-v7, c2819.patch, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and
write ops
Posted by "Melvin Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099155#comment-13099155 ]
Melvin Wang commented on CASSANDRA-2819:
----------------------------------------
I was on vacation since mid last week. Picking it up now.
> Split rpc timeout for read and write ops
> ----------------------------------------
>
> Key: CASSANDRA-2819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Melvin Wang
> Fix For: 1.0
>
> Attachments: 2819-v4.txt, rpc-jira.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira