[ 
https://issues.apache.org/jira/browse/CASSANDRA-14485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16662320#comment-16662320
 ] 

Benedict edited comment on CASSANDRA-14485 at 10/24/18 2:12 PM:
----------------------------------------------------------------

bq. change paramSize (which is currently the number of parameters in the 
header), encoded as a 4-byte int, to represent the count of bytes in the 
parameters as a whole, encoded as a vint.

Just wondering the reason for this?  It makes it very hard to decode a message 
without using the netty path, which is fairly limiting (particularly for 
CASSANDRA-14821), and I don't see a clear benefit to the change?  The number of 
parameters is smaller to encode as a vint, and we can decode with nothing but a 
{{DataInputPlus}}.

Hmm, so I can see that the goal is probably to make it easier to defer 
deserialization until the entire contents are in memory.  It would be nice if 
we could handle this without hamstringing direct deserialization from a 
{{DataInputPlus}}.


was (Author: benedict):
bq. change paramSize (which is currently the number of parameters in the 
header), encoded as a 4-byte int, to represent the count of bytes in the 
parameters as a whole, encoded as a vint.

Just wondering the reason for this?  It makes it very hard to decode a message 
without using the netty path, which is fairly limiting (particularly for 
CASSANDRA-14821), and I don't see a clear benefit to the change?  The number of 
parameters is smaller to encode as a vint, and we can decode with nothing but a 
{{DataInputPlus}}.

> Optimize internode messaging protocol
> -------------------------------------
>
>                 Key: CASSANDRA-14485
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14485
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Streaming and Messaging
>            Reporter: Jason Brown
>            Assignee: Jason Brown
>            Priority: Major
>             Fix For: 4.0
>
>
> There's some dead wood and places for optimization in the internode messaging 
> protocol. Currently, we include the sender's \{{IPAddressAndPort}} in *every* 
> internode message, even though we already sent that in the handshake that 
> established the connection/session. Further, there are several places where 
> we can use vints instead of a fixed, 4-byte integer value- especially as 
> those values will almost always be less than one byte.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to