PetterIsberg closed pull request #85:
URL: https://github.com/apache/pulsar-dotpulsar/pull/85
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-
PetterIsberg commented on issue #84:
URL: https://github.com/apache/pulsar-dotpulsar/issues/84#issuecomment-931009908
I also think adding pings to the client is a good idea.
I closed my PR as it was meant as an example of how it could be solved. I
should probably have marked it WIP.
--
+1 (binding)
Thanks for the great work.
Penghui
On Thu, Sep 30, 2021 at 12:38 PM Enrico Olivelli
wrote:
> +1 (binding)
>
> Enrico
>
> Il Gio 30 Set 2021, 06:08 Yunze Xu ha
> scritto:
>
> > Hi folks,
> >
> > It has been about two weeks since I opened the PIP-96 issue and the
> design
> > has
arihantdaga commented on issue #161:
URL:
https://github.com/apache/pulsar-client-node/issues/161#issuecomment-931241256
I am facing the same. I installed pulsar cpp client in ubuntu following the
instructions on https://pulsar.apache.org/docs/en/client-libraries-cpp/, using
the deb packa
dunkymole commented on issue #84:
URL: https://github.com/apache/pulsar-dotpulsar/issues/84#issuecomment-931340162
OK great. Agree sending pings is a much better way to detect the half-broken
status. I wasnt sure whether it would be feasible with the wire-protocol, I
never checked. Thanks
I have two questions:
1. Does close imply immediate shutdown?
2. Does close imply flush?
There is not yet consensus on 1, and 2 is only relevant if 1's answer is "no".
Thus far, the conversation has centered on the `Producer#close`
method. I'd like to broaden the discussion to include some other
LGTM +1
--
Matteo Merli
On Mon, Sep 27, 2021 at 1:43 PM Michael Marshall wrote:
>
> Hi Pulsar Community,
>
> I would like to start a VOTE for PIP-97 Asynchronous Authentication Provider.
>
> The issue for this PIP is here:
> https://github.com/apache/pulsar/issues/12105.
>
> The PR for all int
+1 (binding)
Enrico
Il Gio 30 Set 2021, 19:54 Matteo Merli ha scritto:
> LGTM +1
>
>
> --
> Matteo Merli
>
>
> On Mon, Sep 27, 2021 at 1:43 PM Michael Marshall
> wrote:
> >
> > Hi Pulsar Community,
> >
> > I would like to start a VOTE for PIP-97 Asynchronous Authentication
> Provider.
> >
>
Following up here. I am pretty sure part of this conversation has been
based on a misunderstanding of the code. From what I can tell, the
behavior for `Producer#closeAsync` in the client (mostly) aligns with
the current Javadocs.
> The existing implementation of producer close is:
> 1. Cancel all
blankensteiner commented on issue #84:
URL: https://github.com/apache/pulsar-dotpulsar/issues/84#issuecomment-931642288
Hi @PetterIsberg, @Flipbed, and @dunkymole. Thanks for the heads up on this!
:-)
Since I can't reproduce the problem locally I'm hoping you might help me
test the bite
You're right that before a CommandCloseProducer request was completed, the
pending messages should be persisted before this close request was completed
in normal cases. It’s guaranteed by broker side.
Then there’s no inconsistency between the implementation and JavaDocs now.
The key point is whet
Thanks for your analysis, Yunze. I identified above that the messages
in the batch container were not getting completed correctly, so I put
together a PR to fix the problematic behavior. This PR will be valid
regardless of our decision to add flush logic to the close method.
Here is the PR: https:
12 matches
Mail list logo
