Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BACKPORT] Calculate the initial frame size of the client messages correctly #499

Merged
merged 3 commits into from
Oct 14, 2021

Conversation

mdumandag
Copy link
Contributor

While calculating the initial frame size of the client messages,
we were adding SIZE_OF_FRAME_LENGTH_AND_FLAGS twice. That extra
addition is removed from the create_initial_buffer.

To make the create_initial_buffer_custom alike, I also removed
the addition from there, although there was no such problem for that
method. To make it work again, I have modified the protocol template
to perform one less subtraction of SIZE_OF_FRAME_LENGTH_AND_FLAGS
from the initial frame size.

Also, while I was there, I have updated the sql_execute_codec, and
added support for the newly added parameter.

  • add a unit test that verifies the encoded requests produce the same bytearray as the Java client

While calculating the initial frame size of the client messages,
we were adding `SIZE_OF_FRAME_LENGTH_AND_FLAGS` twice. That extra
addition is removed from the `create_initial_buffer`.

To make the `create_initial_buffer_custom` alike, I also removed
the addition from there, although there was no such problem for that
method. To make it work again, I have modified the protocol template
to perform one less subtraction of `SIZE_OF_FRAME_LENGTH_AND_FLAGS`
from the initial frame size.

Also, while I was there, I have updated the `sql_execute_codec`, and
added support for the newly added parameter.

* add a unit test that verifies the encoded requests produce the same bytearray as the Java client
@codecov-commenter
Copy link

codecov-commenter commented Oct 14, 2021

Codecov Report

Merging #499 (0929cc1) into 5.0.z (ac57ce7) will decrease coverage by 0.34%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##            5.0.z     #499      +/-   ##
==========================================
- Coverage   95.22%   94.88%   -0.35%     
==========================================
  Files         346      346              
  Lines       17680    17680              
==========================================
- Hits        16836    16775      -61     
- Misses        844      905      +61     
Impacted Files Coverage Δ
hazelcast/protocol/client_message.py 93.45% <ø> (-1.85%) ⬇️
hazelcast/sql.py 97.44% <ø> (ø)
hazelcast/__init__.py 60.00% <100.00%> (ø)
hazelcast/protocol/codec/custom/address_codec.py 73.07% <100.00%> (ø)
...rotocol/codec/custom/bitmap_index_options_codec.py 73.07% <100.00%> (ø)
.../protocol/codec/custom/endpoint_qualifier_codec.py 73.07% <100.00%> (ø)
...elcast/protocol/codec/custom/error_holder_codec.py 96.87% <100.00%> (ø)
...elcast/protocol/codec/custom/index_config_codec.py 71.87% <100.00%> (ø)
...zelcast/protocol/codec/custom/member_info_codec.py 75.00% <100.00%> (ø)
...cast/protocol/codec/custom/member_version_codec.py 74.19% <100.00%> (ø)
... and 14 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ac57ce7...0929cc1. Read the comment docs.

@mdumandag mdumandag merged commit f1db480 into hazelcast:5.0.z Oct 14, 2021
@mdumandag mdumandag deleted the protocol-fix-5.0.z branch October 14, 2021 10:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants