You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2012/06/06 04:19:22 UTC
[jira] [Created] (CASSANDRA-4311) clean up messagingservice
protocol limitations
Jonathan Ellis created CASSANDRA-4311:
-----------------------------------------
Summary: clean up messagingservice protocol limitations
Key: CASSANDRA-4311
URL: https://issues.apache.org/jira/browse/CASSANDRA-4311
Project: Cassandra
Issue Type: Bug
Reporter: Jonathan Ellis
Fix For: 1.2
Weaknesses of the existing protocol:
- information asymmetry: node A can know what version node B expects, but not vice versa (see CASSANDRA-4101)
- delayed information: node A will often not know what version node B expects, until after first contacting node B -- forcing it to throw that first message away and retry for the next one
- protocol cannot handle both cross-dc forwarding and broadcast_address != socket address (see bottom of CASSANDRA-4099)
- version is partly global, partly per-connection, and partly per-message, resulting in some interesting hacks (CASSANDRA-3166) and difficulty layering more sophisticated OutputStreams on the socket (CASSANDRA-3127, CASSANDRA-4139)
--
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-4311) clean up messagingservice
protocol limitations
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291160#comment-13291160 ]
Brandon Williams edited comment on CASSANDRA-4311 at 6/7/12 5:50 PM:
---------------------------------------------------------------------
MS.setVersion needs a minor fix to prevent NPE:
{noformat}
public Integer setVersion(InetAddress address, int version)
{
logger.debug("Setting version {} for {}", version, address);
Integer v = versions.put(address, version);
return v == null ? version : v;
}
{noformat}
+1 otherwise.
was (Author: brandon.williams):
MS.setVersion needs a minor fix to prevent NPE:
{noformat}
public Integer setVersion(InetAddress address, int version)
{
logger.debug("Setting version {} for {}", version, address);
return versions.put(address, version);
Integer v = versions.put(address, version);
return v == null ? version : v;
}
{noformat}
+1 otherwise.
> clean up messagingservice protocol limitations
> ----------------------------------------------
>
> Key: CASSANDRA-4311
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4311
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Labels: jmx
> Fix For: 1.2
>
> Attachments: 4311-skeleton.txt
>
>
> Weaknesses of the existing protocol:
> - information asymmetry: node A can know what version node B expects, but not vice versa (see CASSANDRA-4101)
> - delayed information: node A will often not know what version node B expects, until after first contacting node B -- forcing it to throw that first message away and retry for the next one
> - protocol cannot handle both cross-dc forwarding and broadcast_address != socket address (see bottom of CASSANDRA-4099)
> - version is partly global, partly per-connection, and partly per-message, resulting in some interesting hacks (CASSANDRA-3166) and difficulty layering more sophisticated OutputStreams on the socket (CASSANDRA-3127, CASSANDRA-4139)
--
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-4311) clean up messagingservice
protocol limitations
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289905#comment-13289905 ]
Jonathan Ellis commented on CASSANDRA-4311:
-------------------------------------------
I think we can address all of these by making these changes to VERSION_12 protocol:
- send version and connection metadata just once per connection. This will give the other side enough information to know whether to expect a compressed or varint stream
- *both* sides exchange CURRENT_VERSION when connection is established; each side will then have version information immediately upon contacting another node
As a consequence,
- When version changes, we need to drop existing connections and reconnect (already implied but not yet implemented by CASSANDRA-3127)
> clean up messagingservice protocol limitations
> ----------------------------------------------
>
> Key: CASSANDRA-4311
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4311
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
> Fix For: 1.2
>
>
> Weaknesses of the existing protocol:
> - information asymmetry: node A can know what version node B expects, but not vice versa (see CASSANDRA-4101)
> - delayed information: node A will often not know what version node B expects, until after first contacting node B -- forcing it to throw that first message away and retry for the next one
> - protocol cannot handle both cross-dc forwarding and broadcast_address != socket address (see bottom of CASSANDRA-4099)
> - version is partly global, partly per-connection, and partly per-message, resulting in some interesting hacks (CASSANDRA-3166) and difficulty layering more sophisticated OutputStreams on the socket (CASSANDRA-3127, CASSANDRA-4139)
--
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-4311) clean up messagingservice
protocol limitations
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291160#comment-13291160 ]
Brandon Williams commented on CASSANDRA-4311:
---------------------------------------------
MS.setVersion needs a minor fix to prevent NPE:
{noformat}
public Integer setVersion(InetAddress address, int version)
{
logger.debug("Setting version {} for {}", version, address);
return versions.put(address, version);
Integer v = versions.put(address, version);
return v == null ? version : v;
}
{noformat}
+1 otherwise.
> clean up messagingservice protocol limitations
> ----------------------------------------------
>
> Key: CASSANDRA-4311
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4311
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Labels: jmx
> Fix For: 1.2
>
> Attachments: 4311-skeleton.txt
>
>
> Weaknesses of the existing protocol:
> - information asymmetry: node A can know what version node B expects, but not vice versa (see CASSANDRA-4101)
> - delayed information: node A will often not know what version node B expects, until after first contacting node B -- forcing it to throw that first message away and retry for the next one
> - protocol cannot handle both cross-dc forwarding and broadcast_address != socket address (see bottom of CASSANDRA-4099)
> - version is partly global, partly per-connection, and partly per-message, resulting in some interesting hacks (CASSANDRA-3166) and difficulty layering more sophisticated OutputStreams on the socket (CASSANDRA-3127, CASSANDRA-4139)
--
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-4311) clean up messagingservice
protocol limitations
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290264#comment-13290264 ]
Brandon Williams commented on CASSANDRA-4311:
---------------------------------------------
This looks like a good solution so far.
bq. When version changes, we need to drop existing connections and reconnect
Let me take this opportunity to suggest that set/getVersion be moved out of Gossiper (which does nothing but expose a Map) and into MS.
> clean up messagingservice protocol limitations
> ----------------------------------------------
>
> Key: CASSANDRA-4311
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4311
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 1.2
>
> Attachments: 4311-skeleton.txt
>
>
> Weaknesses of the existing protocol:
> - information asymmetry: node A can know what version node B expects, but not vice versa (see CASSANDRA-4101)
> - delayed information: node A will often not know what version node B expects, until after first contacting node B -- forcing it to throw that first message away and retry for the next one
> - protocol cannot handle both cross-dc forwarding and broadcast_address != socket address (see bottom of CASSANDRA-4099)
> - version is partly global, partly per-connection, and partly per-message, resulting in some interesting hacks (CASSANDRA-3166) and difficulty layering more sophisticated OutputStreams on the socket (CASSANDRA-3127, CASSANDRA-4139)
--
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] [Assigned] (CASSANDRA-4311) clean up messagingservice
protocol limitations
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis reassigned CASSANDRA-4311:
-----------------------------------------
Assignee: Jonathan Ellis
> clean up messagingservice protocol limitations
> ----------------------------------------------
>
> Key: CASSANDRA-4311
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4311
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 1.2
>
>
> Weaknesses of the existing protocol:
> - information asymmetry: node A can know what version node B expects, but not vice versa (see CASSANDRA-4101)
> - delayed information: node A will often not know what version node B expects, until after first contacting node B -- forcing it to throw that first message away and retry for the next one
> - protocol cannot handle both cross-dc forwarding and broadcast_address != socket address (see bottom of CASSANDRA-4099)
> - version is partly global, partly per-connection, and partly per-message, resulting in some interesting hacks (CASSANDRA-3166) and difficulty layering more sophisticated OutputStreams on the socket (CASSANDRA-3127, CASSANDRA-4139)
--
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-4311) clean up messagingservice
protocol limitations
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-4311:
--------------------------------------
Attachment: 4311-skeleton.txt
I think the changes to ITC demonstrate what I have in mind pretty clearly (attached). I'll flesh the rest of this out shortly.
> clean up messagingservice protocol limitations
> ----------------------------------------------
>
> Key: CASSANDRA-4311
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4311
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 1.2
>
> Attachments: 4311-skeleton.txt
>
>
> Weaknesses of the existing protocol:
> - information asymmetry: node A can know what version node B expects, but not vice versa (see CASSANDRA-4101)
> - delayed information: node A will often not know what version node B expects, until after first contacting node B -- forcing it to throw that first message away and retry for the next one
> - protocol cannot handle both cross-dc forwarding and broadcast_address != socket address (see bottom of CASSANDRA-4099)
> - version is partly global, partly per-connection, and partly per-message, resulting in some interesting hacks (CASSANDRA-3166) and difficulty layering more sophisticated OutputStreams on the socket (CASSANDRA-3127, CASSANDRA-4139)
--
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-4311) clean up messagingservice
protocol limitations
Posted by "Marcus Eriksson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290969#comment-13290969 ]
Marcus Eriksson commented on CASSANDRA-4311:
--------------------------------------------
looks good to me, just a bit confusing calling it a 'header' when it is essentially a handshake packet
could we negotiate SSL the way we do compression? nothing 'secret' is shared during the handshake phase anyway, after that we could upgrade sockets
> clean up messagingservice protocol limitations
> ----------------------------------------------
>
> Key: CASSANDRA-4311
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4311
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Labels: jmx
> Fix For: 1.2
>
> Attachments: 4311-skeleton.txt
>
>
> Weaknesses of the existing protocol:
> - information asymmetry: node A can know what version node B expects, but not vice versa (see CASSANDRA-4101)
> - delayed information: node A will often not know what version node B expects, until after first contacting node B -- forcing it to throw that first message away and retry for the next one
> - protocol cannot handle both cross-dc forwarding and broadcast_address != socket address (see bottom of CASSANDRA-4099)
> - version is partly global, partly per-connection, and partly per-message, resulting in some interesting hacks (CASSANDRA-3166) and difficulty layering more sophisticated OutputStreams on the socket (CASSANDRA-3127, CASSANDRA-4139)
--
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