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

[fix] Fix MessageId serialization when it's a batched message #153

Merged

Conversation

BewareMyPower
Copy link
Contributor

Motivation

The serialization and deserialization of MessageId became wrong after #132.

  1. The batch size is not serialized.
  2. BatchedMessageIdImpl could never be deserialized.

The wrong behaviors could lead to a result that all MessageId objects created from deserialization does not have a batch size, which might make ReaderTest.testReaderOnSpecificMessageWithBatches fail when the cmake build type is Debug. What's worse is that a MessageId created from deserialization is always treated as a MessageIdImpl, on which the acknowledgment will have wrong behavior.

Modifications

Serialize the batch size if it's valid. In deserialization, create a BatchedMessageIdImpl when the batch index and the batch size are valid as a batched message.

There is a problem that if a MessageId is created from deserialization, it cannot share a BatchMessageAcker with other MessageId objects. In this case, create a fake BatchMessageAcker that returns false for both ackIndividual and ackCumulative methods. It will make acknowledgment always fail but will fall back to batch index ACK if batch index ACK is enabled.

Add the -DCMAKE_BUILD_TYPE=Debug for tests to enable assertions.

### Motivation

The serialization and deserialization of `MessageId` became wrong after
apache#132.
1. The batch size is not serialized.
2. `BatchedMessageIdImpl` could never be deserialized.

The wrong behaviors could lead to a result that all MessageId objects
created from deserialization does not have a batch size, which might
make `ReaderTest.testReaderOnSpecificMessageWithBatches` fail when the
cmake build type is `Debug`. What's worse is that a MessageId created
from deserialization is always treated as a `MessageIdImpl`, on which
the acknowledgment will have wrong behavior.

### Modifications

Serialize the batch size if it's valid. In deserialization, create a
`BatchedMessageIdImpl` when the batch index and the batch size are valid
as a batched message.

There is a problem that if a `MessageId` is created from
deserialization, it cannot share a `BatchMessageAcker` with other
`MessageId` objects. In this case, create a fake `BatchMessageAcker`
that returns false for both `ackIndividual` and `ackCumulative` methods.
It will make acknowledgment always fail but will fall back to batch
index ACK if batch index ACK is enabled.

Add the `-DCMAKE_BUILD_TYPE=Debug` for tests to enable assertions.
@BewareMyPower BewareMyPower added the bug Something isn't working label Dec 22, 2022
@BewareMyPower BewareMyPower self-assigned this Dec 22, 2022
@shibd
Copy link
Member

shibd commented Dec 23, 2022

@BewareMyPower It seems that compilation does not pass in the macOS environment.

@BewareMyPower
Copy link
Contributor Author

@shibd I see. I will fix it soon.

@BewareMyPower
Copy link
Contributor Author

@merlimat @RobertIndie @Demogorgon314 Could you take a second look?

@RobertIndie RobertIndie added this to the 3.2.0 milestone Dec 28, 2022
@RobertIndie RobertIndie merged commit d03ff20 into apache:main Dec 28, 2022
@BewareMyPower BewareMyPower deleted the bewaremypower/fix-batch-size-assertion branch December 28, 2022 11:11
BewareMyPower added a commit to BewareMyPower/pulsar-client-cpp that referenced this pull request Jan 17, 2023
### Motivation

Currently the main branch is broken by the concurrent merge of
apache#153 and
apache#151. It's because when
a batched message id is constructed from deserialization, there is no
`getBitSet` implementation of the internal acker.

### Modifications

Add a `bool` parameter to `MessageIdImpl::getBitSet` to indicate whether
the message ID is batched. The logic is similar with

https://github.com/apache/pulsar/blob/299bd70fdfa023768e94a8ee4347d39337b6cbd4/pulsar-client/src/main/java/org/apache/pulsar/client/impl/PersistentAcknowledgmentsGroupingTracker.java#L325-L327

and

https://github.com/apache/pulsar/blob/299bd70fdfa023768e94a8ee4347d39337b6cbd4/pulsar-client/src/main/java/org/apache/pulsar/client/impl/PersistentAcknowledgmentsGroupingTracker.java#L345-L347

Add a `testMessageIdFromBuild` to test the acknowledgment for a message
ID without an acker could succeed for a consumer that enables batch
index ACK.

### TODO

In future, apache/pulsar#19031 might be migrated
into the C++ client to fix the consumer that disables batch index ACK.
BewareMyPower added a commit to BewareMyPower/pulsar-client-cpp that referenced this pull request Jan 18, 2023
### Motivation

Currently the main branch is broken by the concurrent merge of
apache#153 and
apache#151.

### Modifications

Add a dummy `getBitSet` implementation to `BatchMessageAcker` and the
correct implementation for `BatchMessageAckerImpl`.
Demogorgon314 pushed a commit that referenced this pull request Jan 18, 2023
### Motivation

Currently the main branch is broken by the concurrent merge of
#153 and
#151.

### Modifications

Add a dummy `getBitSet` implementation to `BatchMessageAcker` and the
correct implementation for `BatchMessageAckerImpl`.
BewareMyPower added a commit to BewareMyPower/pulsar-client-cpp that referenced this pull request Oct 27, 2024
Fix the regression introduced in apache#153

----
9.006, 8.860, 9.113
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants