Re: [DISCUSS] PIP-224: Introduce TopicMessageId for consumer's MessageId related APIs
Hi Yunze, +1(non-binding) Thank you very much for your patience. I have no other problem now. Great PIP! Thanks, Bo Yunze Xu 于2022年12月22日周四 15:29写道： > > Hi Penghui and Bo, > > I realized this problem as well. No new APIs should be added. I added > the new API mainly to express that the semantics of seek will be > modified while the acknowledge semantics keeps not changed. Now I > removed the new APIs and updated this proposal. > > Thanks, > Yunze > > > On Thu, Dec 22, 2022 at 10:55 AM 丛搏 wrote: > > > > > Users can use > > > ``` > > > MessageId.fromByteArrayWithTopic() > > > ``` > > > or > > > ``` > > > TopicMessageId.fromByteArray(); > > > TopicMessageId.create(); > > > ``` > > > > I think this is a good point. `TopicName` don't in the `MessageId` > > means that multiConsumer must know that this topic is a partitioned > > topic and needs to assign `TopicName` to `MessageId` and doesn't need > > to add new interfaces. > > > > Thanks, > > Bo > > > > PengHui Li 于2022年12月22日周四 09:50写道： > > > > > > > Because `TopicMessageId` is constructed by the Pulsar Client library > > > itself, which can guarantee `getOwnerTopic()` returns the correct > > > topic name. The benefit of passing a `TopicMessageId` rather than the > > > combination of a topic name and a `MessageId` is, users won't need to > > > care about how to get the correct topic name for a given partition by > > > themselves. > > > > > > This is a good point of why we should not introduce seek(TopicName, > > > MessageId) > > > It's better also to mention this part in the proposal. It will help us to > > > understand > > > why seek(TopicName, MessageId) is not a good way for Pulsar. > > > > > > Thanks, > > > Penghui > > > > > > On Thu, Dec 22, 2022 at 9:48 AM PengHui Li wrote: > > > > > > > > In short, `seek(msgId)` will call `seek(TopicMessageId)` if `msgId` is > > > > a `TopicMessageId`. > > > > > > > > Does it look like we don't need to add the following new APIs? > > > > > > > > ``` > > > > void seek(TopicMessageId topicMessageId) throws PulsarClientException; > > > > CompletableFuture seekAsync(TopicMessageId topicMessageId); > > > > ``` > > > > > > > > Users can use > > > > ``` > > > > MessageId.fromByteArrayWithTopic() > > > > ``` > > > > or > > > > ``` > > > > TopicMessageId.fromByteArray(); > > > > TopicMessageId.create(); > > > > ``` > > > > to construct a TopicMessageId instance. > > > > > > > > But we can use the existing seek API with the constructed TopicMessageId > > > > instance > > > > > > > > ``` > > > > consumer.seek(MessageId messageId); > > > > ``` > > > > > > > > Thanks, > > > > Penghui > > > > > > > > On Thu, Dec 22, 2022 at 12:35 AM Yunze Xu > > > > wrote: > > > > > > > >> > but it needs to cast the `TopicMessageId` from `MessageId`, which is > > > >> very user-unfriendly. > > > >> > > > >> Sorry I think my proposal doesn't express it well. In my original > > > >> thought, no cast is needed, please see the update in > > > >> https://github.com/apache/pulsar/issues/18616. > > > >> > > > >> In short, `seek(msgId)` will call `seek(TopicMessageId)` if `msgId` is > > > >> a `TopicMessageId`. > > > >> > > > >> Thanks, > > > >> Yunze > > > >> > > > >> On Wed, Dec 21, 2022 at 11:26 PM 丛搏 wrote: > > > >> > > > > >> > > If you mean `msg.getTopicName()`, how can you declare it's better > > > >> > > than > > > >> > > `msgId.getOwnerTopic()`? > > > >> > > > > >> > > It can. Because the `TopicMessageIdImpl` already contains the > > > >> > > correct > > > >> > > topic. That's the point. > > > >> > > > > >> > ``` > > > >> > var msgId = (TopicMessageId) multiTopicsConsumer.getMessageId(); > > > >> > ``` > > > >> > if `msgId.getOwnerTopic()` is the interface of `MessageId`, I have > > > >> > no > > > >> > problem. but it needs to cast the `TopicMessageId` from `MessageId`, > > > >> > which is very user-unfriendly. And it doesn't make sense. > > > >> > > > > >> > > I don't know what you're thinking about using > > > >> > > `consumer.seek(msg.getTopicName(), msg.getMessageId()` for a single > > > >> > > topic consumer. If it's accepted, and you want to unify the use > > > >> > > case > > > >> > > of `seek`, the original `seek` API should be deprecated and much > > > >> > > existing code could be affected. If it's not accepted, users have > > > >> > > to > > > >> > > distinguish if a consumer is a multi-topics consumer. > > > >> > > > > >> > the same as `consumer.seek(TopicMessageId topicMessageId)` for a > > > >> > single topic consumer is also strange. My point is either TopicName > > > >> > belongs to MessageId or separate the two. it's not a good interface > > > >> > implementation to couple them together. Very unclear. > > > >> > > > > >> > Thanks, > > > >> > Bo > > > >> > > > > >> > Yunze Xu 于2022年12月21日周三 22:46写道： > > > >> > > > > > >> > > > If messageID does not contain `TopicName`, the `TopicName` is > > > >> > > > best > > > >> get from msg. > > > >> > > > > > >> > > If you mean `msg.getTopicName()`, how can you declare it's b
Re: [VOTE] Pulsar Node.js Client Release 1.8.0 Candidate 1
There is an issue when publishing the pulsar node client 1.8.0-rc1 to npm. Close this vote, and I will start releasing candidate 2 soon. Thanks, Zike Yang On Wed, Dec 21, 2022 at 5:28 PM Zike Yang wrote: > > Hi everyone, > > This is the first release candidate for the Apache Pulsar Node.js > client, version 1.8.0. > > It fixes the following issues: > https://github.com/apache/pulsar-client-node/milestone/13?closed=1 > > Please download the source files and review this release candidate: > - Download the source package, verify shasum and asc > - Follow the README.md to build and run the Pulsar Node.js client. > > I have created a repo here to help you verify it more easily: > https://github.com/RobertIndie/pulsar-client-node-validation. Please > read the README file for more information. > The automatic release validation has been passed: > https://github.com/RobertIndie/pulsar-client-node-validation/actions/runs/3747965037 > > The vote will be open for at least 72 hours. It is adopted by majority > approval, with at least 3 PMC affirmative votes. > > Source files: > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/pulsar-client-node-1.8.0-candidate-1/ > > Pulsar's KEYS file containing PGP keys we use to sign the release: > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > SHA-512 checksum: > 98326718eb7de20b3ebb12a4908ae195ec56e506b8c465b14eaa2e4191a2778bda6dbdbd1e2ceb654a1fdc7bb6d908a3bd8018e9f49e40215d3534a568105aff > pulsar-client-node-1.8.0.tar.gz > > The tag to be voted upon: > v1.8.0-rc.1 > https://github.com/apache/pulsar-client-node/releases/tag/v1.8.0-rc.1 > > Please review and vote on the release candidate #1 for the version > 1.8.0, as follows: > [ ] +1, Approve the release > [ ] -1, Do not approve the release (please provide specific comments) > > Thanks, > Zike Yang
Re: [VOTE] Pulsar Node.js Client Release 1.8.0 Candidate 1
Hi Zike, Thank you for driving this release. I have found 2 issues, vulnerable dependency and missing license headers, so could you include them to 1.8.0-rc2? * https://github.com/apache/pulsar-client-node/pull/261 * https://github.com/apache/pulsar-client-node/pull/262 Best Regards, Nozomi 2022年12月22日(木) 17:30 Zike Yang : > There is an issue when publishing the pulsar node client 1.8.0-rc1 to npm. > Close this vote, and I will start releasing candidate 2 soon. > > Thanks, > Zike Yang > > On Wed, Dec 21, 2022 at 5:28 PM Zike Yang wrote: > > > > Hi everyone, > > > > This is the first release candidate for the Apache Pulsar Node.js > > client, version 1.8.0. > > > > It fixes the following issues: > > https://github.com/apache/pulsar-client-node/milestone/13?closed=1 > > > > Please download the source files and review this release candidate: > > - Download the source package, verify shasum and asc > > - Follow the README.md to build and run the Pulsar Node.js client. > > > > I have created a repo here to help you verify it more easily: > > https://github.com/RobertIndie/pulsar-client-node-validation. Please > > read the README file for more information. > > The automatic release validation has been passed: > > > https://github.com/RobertIndie/pulsar-client-node-validation/actions/runs/3747965037 > > > > The vote will be open for at least 72 hours. It is adopted by majority > > approval, with at least 3 PMC affirmative votes. > > > > Source files: > > > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/pulsar-client-node-1.8.0-candidate-1/ > > > > Pulsar's KEYS file containing PGP keys we use to sign the release: > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > > > SHA-512 checksum: > > > 98326718eb7de20b3ebb12a4908ae195ec56e506b8c465b14eaa2e4191a2778bda6dbdbd1e2ceb654a1fdc7bb6d908a3bd8018e9f49e40215d3534a568105aff > > pulsar-client-node-1.8.0.tar.gz > > > > The tag to be voted upon: > > v1.8.0-rc.1 > > https://github.com/apache/pulsar-client-node/releases/tag/v1.8.0-rc.1 > > > > Please review and vote on the release candidate #1 for the version > > 1.8.0, as follows: > > [ ] +1, Approve the release > > [ ] -1, Do not approve the release (please provide specific comments) > > > > Thanks, > > Zike Yang >
[VOTE] PIP-229: Add a common interface to get fields of MessageIdData
Hi all, I'm starting the VOTE for PIP-229: Add a common interface to get fields of MessageIdData: https://github.com/apache/pulsar/issues/18950 Discussion thread: https://lists.apache.org/thread/25rzflmkfmvxhf3my0ombnbpv7bvgy32 The vote will be open for at least 3 days. Thanks, Yunze
Re: [DISCUSS] Change the default IO threads and listener threads of Java Client
+1 Thanks Yubiao On Thu, Dec 22, 2022 at 9:04 AM PengHui Li wrote: > > I notice that if changing the default value of conf `ioThreads` of pulsar > > client, it does not just affect the num of io threads, and it also > affects > > these thread pools: > > - internal executor of the client > > - scheduled executor of the client > > - HTTP client io thread pool of pulsar admin client > > I think it's ok. Users can change the IO threads, it will also change the > above thread pools. > It could be different issues. We can support changing the scheduled > executor threads > and > HTTP client IO threads independently once we need it. > > From the performance test experience before. I don't see any obvious > negative impact from > the scheduled executor and HTTP client IO threads after changing the IO > threads configuration. > One salient point is if you don't change the IO threads, you will not be > able to get an expected > message producing and consuming throughput. > > Thanks, > Penghui > > On Thu, Dec 22, 2022 at 12:35 AM Yubiao Feng > wrote: > > > Hi PengHui > > > > I notice that if changing the default value of conf `ioThreads` of pulsar > > client, it does not just affect the num of io threads, and it also > affects > > these thread pools: > > - internal executor of the client > > - scheduled executor of the client > > - HTTP client io thread pool of pulsar admin client > > > > see: https://github.com/apache/pulsar/pull/19020 > > > > Should we provide other APIs to configure these three thread pools? > > > > Thanks > > Yubiao > > > > On Tue, Dec 20, 2022 at 11:17 AM PengHui Li wrote: > > > > > Hi all, > > > > > > I noticed the Java Client (I haven't checked other clients) uses 1 IO > > > thread and 1 listener > > > thread by default. It will require users to update the thread > > configuration > > > if they have > > > multiple cores and desired high throughput. > > > > > > Here is the example that we change to 16 IO threads in > > > openmessaging benchmark > > > > > > > > > https://github.com/openmessaging/benchmark/blob/master/driver-pulsar/pulsar.yaml#L22 > > > > > > We can apply the configuration of the threads based on the CPU cores. > So > > > that for the > > > most common cases, users don't need to touch the thread configuration. > > > > > > ``` > > > private int numIoThreads = Runtime.getRuntime().availableProcessors(); > > > private int numListenerThreads = > > > Runtime.getRuntime().availableProcessors(); > > > ``` > > > > > > WDYT? > > > > > > Thanks, > > > Penghui > > > > > >
Re: [DISCUSS] Change the default IO threads and listener threads of Java Client
> My concern is whether this change will affect some users who are creating > many clients. This is a good point. There's an internal API to share the thread pools across clients. There's a code example in the Pulsar code base, https://github.com/apache/pulsar/blob/f029757ecb9653a97710f2bac563d247d04feb63/pulsar-broker/src/main/java/org/apache/pulsar/broker/PulsarService.java#L1463-L1473 . This change was made by https://github.com/apache/pulsar/pull/12037 and https://github.com/apache/pulsar/pull/13839 . Perhaps it would be useful to expose the solution to share thread pools across clients. A better abstraction and end user API for doing that would be useful so that the details of individual thread pools would be hidden. The current code for sharing the thread pools is very verbose as you can see from the referenced code example. -Lari On 2022/12/20 04:25:06 mattisonc...@gmail.com wrote: > +1 > > My concern is whether this change will affect some users who are creating > many clients. I think we can wait for other users to confirm it. (If this > will be affected, maybe we can give it a max_io_thread_num and then expand > the size from 1 to max_io_thread_num when adding a new consumer or producer) > > > Best, > Mattison > On Dec 20, 2022, 11:17 +0800, PengHui Li , wrote: > > Hi all, > > > > I noticed the Java Client (I haven't checked other clients) uses 1 IO > > thread and 1 listener > > thread by default. It will require users to update the thread configuration > > if they have > > multiple cores and desired high throughput. > > > > Here is the example that we change to 16 IO threads in > > openmessaging benchmark > > https://github.com/openmessaging/benchmark/blob/master/driver-pulsar/pulsar.yaml#L22 > > > > We can apply the configuration of the threads based on the CPU cores. So > > that for the > > most common cases, users don't need to touch the thread configuration. > > > > ``` > > private int numIoThreads = Runtime.getRuntime().availableProcessors(); > > private int numListenerThreads = Runtime.getRuntime().availableProcessors(); > > ``` > > > > WDYT? > > > > Thanks, > > Penghui >
[DISCUSS] Move GitHub discussion notifications to commits@
Hello Pulsar Community, We've had GitHub discussions enabled for a while now. I think they're a helpful way for users to ask questions. I also think they are creating too many notifications to the dev@ list, which can make it hard to keep up with PIPs, VOTEs, and other dev discussions. I propose we move these notifications to the commits@ list. This change will make all GitHub notifications go to commits@. Any user/contributor that would like to receive discussion notifications can subscribe via GitHub or via the commits mailing list. Here is the relevant PR: https://github.com/apache/pulsar/pull/19033 What are your thoughts? If there are no objections in the next week, I propose we merge the PR. Thanks, Michael
Re: [VOTE] Pulsar Node.js Client Release 1.8.0 Candidate 1
Hi, Nozomi Sure. I will add them to rc2. Thanks, Zike Yang On Thu, Dec 22, 2022 at 6:45 PM Nozomi Kurihara wrote: > > Hi Zike, > > Thank you for driving this release. > > I have found 2 issues, vulnerable dependency and missing license headers, > so could you include them to 1.8.0-rc2? > * https://github.com/apache/pulsar-client-node/pull/261 > * https://github.com/apache/pulsar-client-node/pull/262 > > Best Regards, > Nozomi > > 2022年12月22日(木) 17:30 Zike Yang : > > > There is an issue when publishing the pulsar node client 1.8.0-rc1 to npm. > > Close this vote, and I will start releasing candidate 2 soon. > > > > Thanks, > > Zike Yang > > > > On Wed, Dec 21, 2022 at 5:28 PM Zike Yang wrote: > > > > > > Hi everyone, > > > > > > This is the first release candidate for the Apache Pulsar Node.js > > > client, version 1.8.0. > > > > > > It fixes the following issues: > > > https://github.com/apache/pulsar-client-node/milestone/13?closed=1 > > > > > > Please download the source files and review this release candidate: > > > - Download the source package, verify shasum and asc > > > - Follow the README.md to build and run the Pulsar Node.js client. > > > > > > I have created a repo here to help you verify it more easily: > > > https://github.com/RobertIndie/pulsar-client-node-validation. Please > > > read the README file for more information. > > > The automatic release validation has been passed: > > > > > https://github.com/RobertIndie/pulsar-client-node-validation/actions/runs/3747965037 > > > > > > The vote will be open for at least 72 hours. It is adopted by majority > > > approval, with at least 3 PMC affirmative votes. > > > > > > Source files: > > > > > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-node/pulsar-client-node-1.8.0-candidate-1/ > > > > > > Pulsar's KEYS file containing PGP keys we use to sign the release: > > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > > > > > SHA-512 checksum: > > > > > 98326718eb7de20b3ebb12a4908ae195ec56e506b8c465b14eaa2e4191a2778bda6dbdbd1e2ceb654a1fdc7bb6d908a3bd8018e9f49e40215d3534a568105aff > > > pulsar-client-node-1.8.0.tar.gz > > > > > > The tag to be voted upon: > > > v1.8.0-rc.1 > > > https://github.com/apache/pulsar-client-node/releases/tag/v1.8.0-rc.1 > > > > > > Please review and vote on the release candidate #1 for the version > > > 1.8.0, as follows: > > > [ ] +1, Approve the release > > > [ ] -1, Do not approve the release (please provide specific comments) > > > > > > Thanks, > > > Zike Yang > >
Re: [DISCUSS] Move GitHub discussion notifications to commits@
+1 Thanks, Yunze On Fri, Dec 23, 2022 at 6:04 AM Michael Marshall wrote: > > Hello Pulsar Community, > > We've had GitHub discussions enabled for a while now. I think they're > a helpful way for users to ask questions. I also think they are > creating too many notifications to the dev@ list, which can make it > hard to keep up with PIPs, VOTEs, and other dev discussions. > > I propose we move these notifications to the commits@ list. This > change will make all GitHub notifications go to commits@. > > Any user/contributor that would like to receive discussion > notifications can subscribe via GitHub or via the commits mailing > list. > > Here is the relevant PR: https://github.com/apache/pulsar/pull/19033 > > What are your thoughts? If there are no objections in the next week, I > propose we merge the PR. > > Thanks, > Michael
Re: [VOTE] PIP-229: Add a common interface to get fields of MessageIdData
+1 (non-binding) Thanks, Bo Yunze Xu 于2022年12月22日周四 20:34写道： > > Hi all, > > I'm starting the VOTE for PIP-229: Add a common interface to get > fields of MessageIdData: https://github.com/apache/pulsar/issues/18950 > > Discussion thread: > https://lists.apache.org/thread/25rzflmkfmvxhf3my0ombnbpv7bvgy32 > > The vote will be open for at least 3 days. > > Thanks, > Yunze
Re: [DISCUSS] Move GitHub discussion notifications to commits@
Is it better to point to user@ list? I noticed that most discussions are user-facing issues(Requirements, Questions) Thanks, Penghui On Fri, Dec 23, 2022 at 10:18 AM Yunze Xu wrote: > +1 > > Thanks, > Yunze > > On Fri, Dec 23, 2022 at 6:04 AM Michael Marshall > wrote: > > > > Hello Pulsar Community, > > > > We've had GitHub discussions enabled for a while now. I think they're > > a helpful way for users to ask questions. I also think they are > > creating too many notifications to the dev@ list, which can make it > > hard to keep up with PIPs, VOTEs, and other dev discussions. > > > > I propose we move these notifications to the commits@ list. This > > change will make all GitHub notifications go to commits@. > > > > Any user/contributor that would like to receive discussion > > notifications can subscribe via GitHub or via the commits mailing > > list. > > > > Here is the relevant PR: https://github.com/apache/pulsar/pull/19033 > > > > What are your thoughts? If there are no objections in the next week, I > > propose we merge the PR. > > > > Thanks, > > Michael >
Re: [VOTE] PIP-229: Add a common interface to get fields of MessageIdData
+1(binding) Thanks, Penghui On Fri, Dec 23, 2022 at 10:31 AM 丛搏 wrote: > +1 (non-binding) > > Thanks, > Bo > > Yunze Xu 于2022年12月22日周四 20:34写道： > > > > Hi all, > > > > I'm starting the VOTE for PIP-229: Add a common interface to get > > fields of MessageIdData: https://github.com/apache/pulsar/issues/18950 > > > > Discussion thread: > > https://lists.apache.org/thread/25rzflmkfmvxhf3my0ombnbpv7bvgy32 > > > > The vote will be open for at least 3 days. > > > > Thanks, > > Yunze >
Re: [DISCUSS] The use of consumer redeliverUnacknowledgedMessages method
Hi, Asaf, Baodi:
I'm very sorry for my late reply. Thanks for your discussion.
> - receive() - get the following message
> - cumulativeAck(msgId) - acknowledge all messages up to msgId.
> - Maybe we can try to come up with a self-explanatory name like
> ackAllUpTo(msgId).
If the user wants the messages in order, the `receive ()` and
`cumulativeAck ()` must be in a single thread. Otherwise, the
`cumulativeAck` will lose its meaning.
If users use cumulative ack code like:
```
while (true) {
Message message = consumer.receive();
process(message);
consumer.acknowledgeCumulative(message.getMessageId());
}
```
I think it is not a good way for users to use `acknowledgeCumulative
`. because one message doesn't need `cumulativeAck`, it's meaningless.
They use `acknowledgeCumulative ` should like code:
```
while (true) {
Messages messages = consumer.batchReceive();
process(messages);
consumer.acknowledgeCumulative(messages);
}
```
then we should think about when `process(messages);` throw any
exception, the user how to reprocess this message.
1. one case is the user reprocess these messages, the
`process(messages)` code like:
```
private void process(Messages messages) {
try {
// so something
} catch (Exception e) {
process(messages);
}
};
```
in this way, the consumer doesn't need to do anything
2. pulsar rewind the cursor, and redeliver these messages
```
while (true) {
Messages messages = consumer.batchReceive();
try {
process(messages);
} catch (Exception e) {
consumer.rewind(); // this method can redeliver the
messages, whatever the name of this method. before this method
succeeds, the consumer can't invoke consumer.batchReceive() again.
continue;
}
consumer.acknowledgeCumulative(messages);
}
```
int this way, the consumer needs a method that can redeliver these
messages, `redeliverUnacknowledgedMessages` is an async method that
can't guarantee the messages are in order. so we need a new method,
and it is a sync method.
<
In the above two solutions, it can keep messages in order. but in the
first solution, we don't know how many messages the user process and
then cumulative once. If the message numbers are 1000, maybe the
user can't store the message in the memory for reprocessing. so users
need a method to redeliver these messages.
< I think we should disable nack under Exclusive/Failover subscription.
Failover also can be individual ack, so we can't disable
`reconumserLate`r and `negativeAcknowledge`.
Thanks,
Bo
Asaf Mesika 于2022年12月18日周日 18:36写道：
>
> Hi Baodi,
>
> Yes, in effect, I suggest that we have new Consumer interfaces, one per
> subscription type perhaps then we can “correct” the current interface
> without breaking backward compatibility.
>
> For Exclusive/Failover, since the idea in those subscription types was to
> maintain order, it makes sense we would offer the following:
>
>
>- receive() - get the following message
>- cumulativeAck(msgId) - acknowledge all messages up to msgId.
> - Maybe we can try to come up with a self-explanatory name like
> ackAllUpTo(msgId).
>
>
>
> Like you I’m interested in knowing what the experienced folks in the
> community think about this.
>
>
> On 30 Nov 2022 at 4:43:22, Baodi Shi wrote:
>
> > Hi, Asaf:
> >
> > Thank you for the comprehensive summary.
> >
> > So in effect, what you would have expected here is that nack(4) in
> >
> > exclusive/shared will happen immediately - clear queue, write redeliver
> >
> > command to broker async and return immediately, hence next receive() will
> >
> > block until messages have been received.
> >
> >
> > In this way, the nack interface in Exclusive/Failover subscrptionn is also
> > doesn’t make sense.
> >
> > For 1, 2, 3, 4, 5.
> > If message 3 processing fails, the application can choose to wait for a
> > period of time to process or directly ack this message (skip this message).
> >
> > I think we should disable nack under Exclusive/Failover subscription.
> >
> > 4. reconsumeLater(msg): ack existing message and write it to the same topic
> >
> > or a different one. This is an explicit out-of-order consumption, but it
> >
> > can be clearly stated in docs.
> >
> >
> > Same as above, we should also disable it in Exclusive/Failover
> > subscription.
> >
> > I think we should have a different consumer interface holding those
> >
> > commands above.
> >
> >
> > It's a transformative idea. I'd like +1. See what other contributors think.
> >
> >
> > 2022年11月30日 00:19，Asaf Mesika 写道：
> >
> >
> > Ok, I'll try to summarize what I read here to make sure we're all on the
> >
> > same page :)
> >
> >
> > Exclusive and Failover subscription types are subscriptions that guarantee
> >
> > two things:
> >
> > 1. Single active consumer per topic (partition).
> >
> > 2. Message processing in the order they
Re: [DISCUSS] Move GitHub discussion notifications to commits@
+1 for pointing to user list. Thanks, Zike Yang On Fri, Dec 23, 2022 at 11:00 AM PengHui Li wrote: > > Is it better to point to user@ list? > I noticed that most discussions are user-facing issues(Requirements, > Questions) > > Thanks, > Penghui > > On Fri, Dec 23, 2022 at 10:18 AM Yunze Xu > wrote: > > > +1 > > > > Thanks, > > Yunze > > > > On Fri, Dec 23, 2022 at 6:04 AM Michael Marshall > > wrote: > > > > > > Hello Pulsar Community, > > > > > > We've had GitHub discussions enabled for a while now. I think they're > > > a helpful way for users to ask questions. I also think they are > > > creating too many notifications to the dev@ list, which can make it > > > hard to keep up with PIPs, VOTEs, and other dev discussions. > > > > > > I propose we move these notifications to the commits@ list. This > > > change will make all GitHub notifications go to commits@. > > > > > > Any user/contributor that would like to receive discussion > > > notifications can subscribe via GitHub or via the commits mailing > > > list. > > > > > > Here is the relevant PR: https://github.com/apache/pulsar/pull/19033 > > > > > > What are your thoughts? If there are no objections in the next week, I > > > propose we merge the PR. > > > > > > Thanks, > > > Michael > >
Re: [VOTE] PIP-224: Introduce TopicMessageId for consumer's MessageId related APIs
It needs the 3rd binding +1 yet. Could anyone else take a look? Thanks, Yunze On Wed, Dec 21, 2022 at 3:21 PM 丛搏 wrote: > > Hi Yunze, > > add `TopicMessageId ` will couple messageID and `topic name` together, > which is very unclear for non-partition-topic. > > ``` > void seek(String topicName, MessageId messageId) throws PulsarClientException; > List> getLastTopicMessageId() throws > PulsarClientException; > ``` > If the interface is designed in this way, it may be simpler, easier to > understand, and more intuitive for users, and MessageID will not be > coupled with TopicName. > > Thanks, > Bo > > Yunze Xu 于2022年12月16日周五 15:31写道： > > > > Yeah, it's an implementation detail and I will keep the same semantics > > with the latest master when I push my PR. > > > > Thanks, > > Yunze > > > > On Fri, Dec 16, 2022 at 3:03 PM 丛搏 wrote: > > > > > > if you don't change this in PIP-229 or PIP-224, I will create a new > > > PIP to handle the `BatchMessageIdImpl` and `MessageIdImpl` > > > `compareTo()` method, now I have no problem with this PIP > > > +1 (non-binding) > > > Sorry to bother this PIP vote. > > > > > > Thanks, > > > Bo > > > > > > Yunze Xu 于2022年12月16日周五 11:58写道： > > > > > > > > If this breaking change can pass the PMC votes, I will keep the new > > > > semantics in PIP-229. Otherwise, it would not make sense to adopt the > > > > new semantics in PIP-229. > > > > > > > > Thanks, > > > > Yunze > > > > > > > > On Fri, Dec 16, 2022 at 11:46 AM Yunze Xu wrote: > > > > > > > > > > I cannot find any confusing code from the proposal itself. Could you > > > > > point it out? If you are mentioning the `legacyCompare` and `compare` > > > > > methods in #18890 [1], it's not related to this proposal. And I have > > > > > opened PIP-229 [2] for discussion. > > > > > > > > > > BTW, the PIP-229 itself doesn't mention the compare logic. But I'm not > > > > > going to adopt the new semantics because it's actually a breaking > > > > > change, just as I've replied. You might think it's a bug, but it's a > > > > > public API. Any change of the semantics in the public API is a > > > > > breaking change. > > > > > > > > > > [1] https://github.com/apache/pulsar/pull/18890/files > > > > > [2] https://lists.apache.org/thread/x52zpwlo8pxzp81oxllh5vw82kyrzgpk > > > > > > > > > > On Fri, Dec 16, 2022 at 11:34 AM 丛搏 wrote: > > > > > > > > > > > > Although unrelated, it adds a lot of confusing code. > > > > > > > > > > > > Thanks, > > > > > > Bo > > > > > > > > > > > > Yunze Xu 于2022年12月16日周五 08:05写道： > > > > > > > > > > > > > > > > > > > > This proposal is not related to the comparison logic between > > > > > > > BatchMessageIdImpl and MessageIdImpl. > > > > > > > > > > > > > > Thanks, > > > > > > > Yunze > > > > > > > > > > > > > > On Thu, Dec 15, 2022 at 12:58 PM 丛搏 wrote: > > > > > > > > > > > > > > > > -1 (non-binding) > > > > > > > > sorry, I have one question about the BatchMessageId compareTo() > > > > > > > > method. the discussion mail : > > > > > > > > https://lists.apache.org/thread/8n3oyk2hdsskkotnj4lnlvfnndctpqbg. > > > > > > > > I hope it can be this issue can be discussed clearly. > > > > > > > > > > > > > > > > I hope it can be this issue can be discussed clearly. I will > > > > > > > > retry to > > > > > > > > vote until this issue clearly : > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Bo > > > > > > > > > > > > > > > > 丛搏 于2022年12月14日周三 22:56写道： > > > > > > > > > > > > > > > > > > +1 (non-binding) > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Bo > > > > > > > > > > > > > > > > > > PengHui Li 于2022年12月14日周三 19:12写道： > > > > > > > > > > > > > > > > > > > > +1 (binding) > > > > > > > > > > > > > > > > > > > > - Penghui > > > > > > > > > > > > > > > > > > > > On Sun, Dec 11, 2022 at 6:36 AM Enrico Olivelli > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > +1 (binding) > > > > > > > > > > > > > > > > > > > > > > Enrico > > > > > > > > > > > > > > > > > > > > > > Il Ven 9 Dic 2022, 10:41 Jiaqi Shen > > > > > > > > > > > ha scritto: > > > > > > > > > > > > > > > > > > > > > > > +1(non-binding) > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Jiaqi Shen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 于2022年12月5日周一 15:23写道： > > > > > > > > > > > > > > > > > > > > > > > > > +1(non-binding) > > > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > Mattison > > > > > > > > > > > > > On Dec 5, 2022, 15:09 +0800, Zike Yang > > > > > > > > > > > > > , wrote: > > > > > > > > > > > > > > +1(non-binding) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > Zike Yang > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Dec 5, 2022 at 2:41 PM Baodi Shi > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > +1(non-binding) > > > > > > > > > > > >
Re: [DISCUSS] Move GitHub discussion notifications to commits@
Sent from my iPhone > On Dec 22, 2022, at 7:00 PM, PengHui Li wrote: > > Is it better to point to user@ list? > I noticed that most discussions are user-facing issues(Requirements, > Questions) I agree. In addition, we should discuss in another thread how to guide user and dev discussions. Guide where each occurs. Regards, Dave > > Thanks, > Penghui > >> On Fri, Dec 23, 2022 at 10:18 AM Yunze Xu >> wrote: >> >> +1 >> >> Thanks, >> Yunze >> >>> On Fri, Dec 23, 2022 at 6:04 AM Michael Marshall >>> wrote: >>> >>> Hello Pulsar Community, >>> >>> We've had GitHub discussions enabled for a while now. I think they're >>> a helpful way for users to ask questions. I also think they are >>> creating too many notifications to the dev@ list, which can make it >>> hard to keep up with PIPs, VOTEs, and other dev discussions. >>> >>> I propose we move these notifications to the commits@ list. This >>> change will make all GitHub notifications go to commits@. >>> >>> Any user/contributor that would like to receive discussion >>> notifications can subscribe via GitHub or via the commits mailing >>> list. >>> >>> Here is the relevant PR: https://github.com/apache/pulsar/pull/19033 >>> >>> What are your thoughts? If there are no objections in the next week, I >>> propose we merge the PR. >>> >>> Thanks, >>> Michael >>
Re: [VOTE] Pulsar Client Python Release 3.0.0 Candidate 3
+1 (binding) - Checked the signature - Install the python .whl file (pip3 install pulsar_client-3.0.0-cp38-cp38-macosx_10_15_universal2.whl) on macOS 12.6(21G115) - Start the standalone (build from the master branch) - Start consumer (python3 ./examples/consumer.py) - Start producer (python3 ./examples/producer.py) Regards Jiwei Guo (Tboy) On Wed, Dec 21, 2022 at 9:55 PM 丛搏 wrote: > +1 (non-binding) > > python version: 3.7.6 > - Checked the signature > - Install the python .whl file (pip3 install > pulsar_client-3.0.0-cp37-cp37m-macosx_10_15_universal2.whl) on macOS > 12.3.1 > - Start the standalone (2.10.2) > - Start consumer (python3 ./examples/consumer.py) > - Start producer (python3 ./examples/producer.py ) > > Thanks, > Bo > > PengHui Li 于2022年12月21日周三 18:01写道： > > > > +1 > > > > - Checked the signature > > - Install the python .whl file (pip3 install > > pulsar_client-3.0.0-cp38-cp38-macosx_10_15_universal2.whl) on macOS > 13.0.1 > > (22A400) > > - Start the standalone (build from the master branch) > > - Start consumer (python3 ./examples/consumer.py) > > - Start producer (python3 ./examples/producer.py) > > > > -- > > Penghui > > > > On Sat, Dec 17, 2022 at 10:35 AM Matteo Merli > > wrote: > > > > > +1 > > > > > > * From candidate-2 I checked the source tarball for licenses, notice > > > and no binaries included. > > > -- > > > Matteo Merli > > > > > > > > > On Thu, Dec 15, 2022 at 11:30 PM Yunze Xu > > > > wrote: > > > > > > > > This is the third release candidate for Apache Pulsar Client Python, > > > > version 3.0.0. > > > > > > > > It fixes the following issues: > > > > https://github.com/apache/pulsar-client-python/milestone/1?closed=1 > > > > > > > > *** Please download, test and vote on this release. This vote will > > > > stay open for at least 72 hours *** > > > > > > > > Python wheels: > > > > > > > > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-python-3.0.0-candidate-3/ > > > > > > > > The supported python versions are 3.7, 3.8, 3.9 and 3.10. The > > > > supported platforms and architectures are: > > > > - Windows x86_64 (windows/) > > > > - glibc-based Linux x86_64 (linux-glibc-x86_64/) > > > > - glibc-based Linux arm64 (linux-glibc-arm64/) > > > > - musl-based Linux x86_64 (linux-musl-x86_64/) > > > > - musl-based Linux arm64 (linux-musl-arm64/) > > > > - macOS universal 2 (macos/) > > > > > > > > The tag to be voted upon: v3.0.0-candidate-3 > > > > (46acc487ad16fdc0aeea9dae64484030e62c1b96) > > > > > > > > https://github.com/apache/pulsar-client-python/releases/tag/v3.0.0-candidate-3 > > > > > > > > Pulsar's KEYS file containing PGP keys you use to sign the release: > > > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > > > > > > > Please download the Python wheels and follow the README to test. > > > > > > > > Thanks, > > > > Yunze > > > >
Re: [VOTE] Pulsar Client Python Release 3.0.0 Candidate 3
I haven’t had a chance to review this RC yet, but I did notice the reorganization of the directories and wanted to compliment this change as very helpful! Also, adding a source release is responsive. Best, Dave Sent from my iPhone > On Dec 22, 2022, at 9:32 PM, guo jiwei wrote: > > +1 (binding) > > - Checked the signature > - Install the python .whl file (pip3 install > pulsar_client-3.0.0-cp38-cp38-macosx_10_15_universal2.whl) on macOS > 12.6(21G115) > - Start the standalone (build from the master branch) > - Start consumer (python3 ./examples/consumer.py) > - Start producer (python3 ./examples/producer.py) > > > Regards > Jiwei Guo (Tboy) > > >> On Wed, Dec 21, 2022 at 9:55 PM 丛搏 wrote: >> >> +1 (non-binding) >> >> python version: 3.7.6 >> - Checked the signature >> - Install the python .whl file (pip3 install >> pulsar_client-3.0.0-cp37-cp37m-macosx_10_15_universal2.whl) on macOS >> 12.3.1 >> - Start the standalone (2.10.2) >> - Start consumer (python3 ./examples/consumer.py) >> - Start producer (python3 ./examples/producer.py ) >> >> Thanks, >> Bo >> >> PengHui Li 于2022年12月21日周三 18:01写道： >>> >>> +1 >>> >>> - Checked the signature >>> - Install the python .whl file (pip3 install >>> pulsar_client-3.0.0-cp38-cp38-macosx_10_15_universal2.whl) on macOS >> 13.0.1 >>> (22A400) >>> - Start the standalone (build from the master branch) >>> - Start consumer (python3 ./examples/consumer.py) >>> - Start producer (python3 ./examples/producer.py) >>> >>> -- >>> Penghui >>> >>> On Sat, Dec 17, 2022 at 10:35 AM Matteo Merli >>> wrote: >>> +1 * From candidate-2 I checked the source tarball for licenses, notice and no binaries included. -- Matteo Merli On Thu, Dec 15, 2022 at 11:30 PM Yunze Xu >> wrote: > > This is the third release candidate for Apache Pulsar Client Python, > version 3.0.0. > > It fixes the following issues: > https://github.com/apache/pulsar-client-python/milestone/1?closed=1 > > *** Please download, test and vote on this release. This vote will > stay open for at least 72 hours *** > > Python wheels: > >> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-python-3.0.0-candidate-3/ > > The supported python versions are 3.7, 3.8, 3.9 and 3.10. The > supported platforms and architectures are: > - Windows x86_64 (windows/) > - glibc-based Linux x86_64 (linux-glibc-x86_64/) > - glibc-based Linux arm64 (linux-glibc-arm64/) > - musl-based Linux x86_64 (linux-musl-x86_64/) > - musl-based Linux arm64 (linux-musl-arm64/) > - macOS universal 2 (macos/) > > The tag to be voted upon: v3.0.0-candidate-3 > (46acc487ad16fdc0aeea9dae64484030e62c1b96) > >> https://github.com/apache/pulsar-client-python/releases/tag/v3.0.0-candidate-3 > > Pulsar's KEYS file containing PGP keys you use to sign the release: > https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > Please download the Python wheels and follow the README to test. > > Thanks, > Yunze >>
Re: [DISCUSS] Move GitHub discussion notifications to commits@
+1 for pointing to the user list. Thanks, Bo Dave Fisher 于2022年12月23日周五 12:48写道： > > > > Sent from my iPhone > > > On Dec 22, 2022, at 7:00 PM, PengHui Li wrote: > > > > Is it better to point to user@ list? > > I noticed that most discussions are user-facing issues(Requirements, > > Questions) > > I agree. > > In addition, we should discuss in another thread how to guide user and dev > discussions. Guide where each occurs. > > Regards, > Dave > > > > Thanks, > > Penghui > > > >> On Fri, Dec 23, 2022 at 10:18 AM Yunze Xu > >> wrote: > >> > >> +1 > >> > >> Thanks, > >> Yunze > >> > >>> On Fri, Dec 23, 2022 at 6:04 AM Michael Marshall > >>> wrote: > >>> > >>> Hello Pulsar Community, > >>> > >>> We've had GitHub discussions enabled for a while now. I think they're > >>> a helpful way for users to ask questions. I also think they are > >>> creating too many notifications to the dev@ list, which can make it > >>> hard to keep up with PIPs, VOTEs, and other dev discussions. > >>> > >>> I propose we move these notifications to the commits@ list. This > >>> change will make all GitHub notifications go to commits@. > >>> > >>> Any user/contributor that would like to receive discussion > >>> notifications can subscribe via GitHub or via the commits mailing > >>> list. > >>> > >>> Here is the relevant PR: https://github.com/apache/pulsar/pull/19033 > >>> > >>> What are your thoughts? If there are no objections in the next week, I > >>> propose we merge the PR. > >>> > >>> Thanks, > >>> Michael > >> >
