I think there are two parts about "lazy deserialization" that Penghui
mentioned.
The first part is more about "delay deserialization" until the messages are
consumed by the consumer applications.
So you don't need to deserialize the objects immediately once the client
receives it.
The second part
Thanks for the reply.
> Another benefit as mentioned in the last part of the proposal, this
can allow lazy deserialization and object
We can do this but not sure how useful to users this will actually be.
In what scenario will a user read a batch of messages but not actually
want to examine the
Hi jerry,
There are two important benefits:
1. It is a simple interface for users, without requiring user to make a
message collector by himself.
There are many scenarios where users will use batch processing. For
example bulk insert database rows,
if user goes to implement a bulk message
Hi Penghui,
So what is the major benefit of using the proposed batch receive API
versus just buffering messages in my application code? In terms of
performance, consumers already receive messages as batches from the
broker. Though the current API only allows the user to retrieve a
message one at
Dear all
This is a PIP to add feature of batch receiving messages
https://github.com/apache/pulsar/wiki/PIP-38%3A-Batch-Receiving-Messages
Please take a look.
—
Regards,
Penghui Li