nkurihar closed issue #13: Implement Serialize/Deserialize for MessageId
URL: https://github.com/apache/pulsar-client-node/issues/13
This is an automated message from the Apache Git Service.
To respond to the message, please
nkurihar commented on issue #13: Implement Serialize/Deserialize for MessageId
URL:
https://github.com/apache/pulsar-client-node/issues/13#issuecomment-512637859
Fixed by
https://github.com/apache/pulsar-client-node/pull/37
---
hrsakai merged pull request #37: added serialize/deserialize methods to set
custom startMessageId in createReader
URL: https://github.com/apache/pulsar-client-node/pull/37
This is an automated message from the Apache Git Se
I think there are some issues about integration tests on CI. It seems to be
failing on building the python wheel file using python 35.
I would recommend stop triggering the integration tests with "run
integration tests" until we fix the issue
https://github.com/apache/pulsar/issues/4748
Thanks,
S
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 Masakazu,
Do you mean we will have a file that contains a table with those columns
and a modification against the file (table) will be shown as the diff? It
sounds like creating an Issue instead is enough to me.
https://swimlanes.io/d/8L04SRASw
Yes, you are correct, your workflow illustrates m
Hi Jennifer,
On Wed, Jul 17, 2019 at 8:38 PM Jinfeng Huang wrote:
> Hi Masakazu,
>> Thanks for your reply.
>>
>> It is designed to create a pull request with the schedule ("Topic,
>> translator, reviewer, status (translated/approved)), and provide a platform
>> for effective communication betwee
>
> Hi Masakazu,
> Thanks for your reply.
>
> It is designed to create a pull request with the schedule ("Topic,
> translator, reviewer, status (translated/approved)), and provide a platform
> for effective communication between translators and reviewers.
>
> Surely, contributors can contribute to
nkurihar commented on issue #36: When will release 2.4？
URL:
https://github.com/apache/pulsar-client-node/issues/36#issuecomment-512213133
Hi, thank you for your comment!
Please let me confirm that what you meant "2.4 release":
* Do you wait for the release announcement of the nod
Thanks for the explanation. It seems like the attachment was lost at
somewhere. I couldn't find the workflow.
I understand the background and I'm fine with using GitHub to improve our
translation process. I also think it doesn't have to be an established way.
We can try it. I just thought it might
2019-07-16 09:41:42 UTC - Rui Fu: @Rui Fu has joined the channel
2019-07-16 10:49:21 UTC - pradeep: Hi Team,
Can someone help here with written document for multiple cluster setup and
multiple DC ?
2019-07-16 10:58:37 UTC - Zhenhao Li: hi team, is there a Nix build for Pulsar?
Like the
12 matches
Mail list logo
