; `broker.conf` they don't really know what it is.
> How can they know what they expect?
>
> Regards,
> Penghui
>
>
> On Mon, Jan 15, 2024 at 11:09 PM Lin Lin wrote:
>
> > User disabling `AppendBrokerTimestampMetadataInterceptor` does not mean
> > that the
User disabling `AppendBrokerTimestampMetadataInterceptor` does not mean that
they allow this bug.
This is a configuration, not an API. It is difficult to use documentation to
regulate user behavior.
Maybe we can add a new field (BrokerTimestamp) to save the timestamp on the
Broker side.
The ti
+1 binding
- Verified shasum, and asc of released files.
- Build and run from source with JDK 8
- Test basic CRUD
Thanks,
Lin Lin
On 2023/05/05 11:04:19 tison wrote:
> Hi everyone,
>
> Please review and vote on the release candidate #1 for the version 0.4.0,
> as follows:
>
&g
it is more adoptable to try this feature in
> production environment. : - )
>
> At 2023-04-12 11:24:11, "Lin Lin" wrote:
> >As I mentioned in the implementation of PIP, we will plug-in the partition
> >assignment strategy.
> >
> >However, in the same
This is a good idea.
Thanks,
Lin Lin
On 2023/04/18 02:07:55 mattisonc...@gmail.com wrote:
>
> Hello, folks.
>
> I would like to start discussing the pulsar internal thread pool sorting out.
>
> How did I get this idea?
>
> Recently, we met some problems with the BK
need
> > to set 128 partitions for a topic. If the partitions < the bundle's count,
> > will the new solution basically be equivalent to
> > the current way?
> >
> > If this is not a general solution for common scenarios. I support making
> > the topic-bundle
hout
> introducing the implementation to the Pulsar repo. Users can implement
> their own assigner based on the business
> requirement. Pulsar's general solution may not be good for all scenarios,
> but it is better for scalability (bundle split)
> and enough for most common sce
+1
Thanks,
Lin Lin
On 2023/03/15 07:54:20 Yunze Xu wrote:
> Hi all,
>
> This thread is to start the vote for PIP-254.
>
> Discussion thread:
> https://lists.apache.org/thread/65cf7w76tt23sbsjnr8rpfxqf1nt9s9l
>
> PIP link: https://github.com/apache/pulsar/issues/19705
>
> Thanks,
> Yunze
>
> This appears to be the "round-robin topic-to-bundle mapping" option in
> the `fundBundle` function. Is this the only place that needs an update? Can
> you list what change is required?
In this PIP, we only discuss topic-to-bundle mapping
Change is required:
1)
When lookup, partitions is assign
The namespace level bundle-unload can be performed in
NamespaceService#splitAndOwnBundleOnceAndRetry
A new judgment will be added here.
After splitting the bundle, it should determine whether to unload at the
namespace level.
On 2023/03/19 09:53:07 lifepuzzlefun wrote:
> I'm interest on the imp
Thanks for joining this discussion
> 1. where is the partition to bundle mapping stored？
We don't need to store the mapping relationship, it can be calculated
dynamically. The first is the starting bundle, partition-0 is calculated
directly through consistent hashing. Subsequent partitions a
Thanks for your review.
> Could you clarify the limitation of the current logic?
The current logic cannot guarantee that the traffic of each bundle is the same,
and must be balanced through split.
However, the load of the topic is not always the same, and the traffic of the
business changes wi
I have the following suggestions:
1. This configuration item should be dynamically updated in the Pulsar process,
only as a means of troubleshooting when problems occur
2. This configuration item should be turned off by default to avoid impact on
performance
+1 (binding)
+1 binding
Thanks,
Lin Lin
try to use pulsar connector.
Item 2: Prepare a design for this feature.
Item 3: Start coding.
Item 4: Add unit and integration tests.
Item 5: Add doc for this feature.
Project Mentor:
Your Name: Lin Lin
Your Email: lin...@apache.org
Your Apache ID: linlin
The addition of this feature looks like a matter of consumer selection.
Should the consumer selection of each Dispatcher be abstracted into an
extensible interface?
Thanks
Lin Lin
+1
Lin Lin
+1
Lin Lin
+1
Lin Lin
On 2022/04/19 03:27:39 Haiting Jiang wrote:
> Hi Pulsar community,
>
> This is the voting thread for PIP-152. It will stay open for at least 48
> hours.
>
> The proposal can be found: https://github.com/apache/pulsar/issues/15094
>
> Discuss thread:
&g
- Checked the signature
- Checked the SHA-512 checksums
- Start standalone
- Create tenant and namespace
- Publish messages and consume messages
- Check Function
Thanks,
Lin Lin
+1
Thanks,
Lin Lin
+1(binding)
1. Checked the signature
2. Start standalone
3. Publish and consume successfully
4. Checked function
My personal opinion:
If this is a blocking issue, we should tag the issue and raise it in the
discussion stage, not in the final release stage, which will waste a lot of
time of the release manager. But I see this issue is already closed.
https://github.com/apache/pulsar/pull/14097
We can eva
+1
+1
On 2021/12/29 02:29:21 Haiting Jiang wrote:
> This is the voting thread for PIP-131. It will stay open for at least 48h.
>
> https://github.com/apache/pulsar/issues/13544
>
> The discussion thread is
> https://lists.apache.org/thread/c63d9s73j9x1m3dkqr3r38gyp8s7cwzf
>
> ## Motivation
>
> C
+1
On 2022/01/12 01:57:59 Haiting Jiang wrote:
> This is the voting thread for PIP-132. It will stay open for at least 48
> hours.
>
> https://github.com/apache/pulsar/issues/13591
>
> Pasted below for quoting convenience.
>
>
>
> ## Motivation
>
> Currently, Pulsar client (Java) only c
On 2021/12/21 10:48:41 Shivji Kumar Jha wrote:
> Hi LinLin,
>
> Log4j version 2.16.0 has DDoS possibilities in some cases [1] . Can we move
> to Log4j 2.17.0 in 2.8.2?
>
> Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3) did not
> > protect from uncontrolled recursion from s
On 2021/12/14 18:03:20 Matteo Merli wrote:
> https://github.com/apache/pulsar/issues/13304
>
>
> Pasted below for quoting convenience.
>
> ---
>
>
> ## Motivation
>
> After all the work done for PIP-45 that was already included in 2.8 and 2.9
> releases, it enabled the concept of re-ac
eleases/tag/v2.8.2-candidate-1
>
> Pulsar's KEYS file containing PGP keys we use to sign the release:
> https://dist.apache.org/repos/dist/dev/pulsar/KEYS
>
> Please download the source package, and follow the README to build
> and run the Pulsar standalone service.
>
> Lin Lin
>
Sorry, I will check it again and start a new vote
lot of
components now
2) cherry-picked/branch-2.8 and release/2.8.2, `release/2.8.2` is used to
identify whether the current release, `cherry-picked/branch-2.8` is used to
identify whether I need to generate documentation for this PR
Lin Lin
On 2021/12/02 11:11:43 Enrico Olivelli wrote:
> He
On 2021/09/27 09:00:52, Enrico Olivelli wrote:
> Hello everyone,
>
> I would like to start a VOTE for PIP-99 Pulsar Proxy Extensions
>
> This is the PIP-99
> https://github.com/apache/pulsar/issues/12157
>
> This is the PR for the implementation (still draft, I will complete it
> after the
ered on the Broker
side, there will be problems in the subsequent consumer ack.
Therefore, if we want to use this filter, we must set enableBatching=false,
which is the same as delayed messages.
I will explain this point in the comments of the interface
Thanks,
Lin Lin
On 2021/09/10 06:22:09, PengHui Li wrote:
> Looks good overall,
>
> Do we need to consider the batch filter since the API is defined as
> `Message`, not `Entry`, so parts of the batch need to filter out, does it
> should be handled by Filter, or the consumer side, or the producer side?
>
> T
> What about:
>
> public interface MessageFilter {
>enum FilterOutcome {
>ACCEPT, -> deliver to the Consumer
>REJECT, -> skip the message
>SYSTEM -> use standard system processing
> }
>
> public FilterOutcome filterMessages(List message
> I also share this problem, because if you want to efficiently implement
> message filtering you need to do it in the broker side.
>
> I am not sure that making the full Dispatcher pluggable is a good idea,
> because the code is too complex and also
> it really depends on the internals of the B
On 2021/08/03 11:12:34, Ivan Kelly wrote:
> > Creating a topic will first check whether the topic already exists.
> > The verification will read all topics under the namespace, and then
> > traverse these topics to see if the topic already exists.
> > When there are a large number of topics un
I look forward to it and hope to coordinate the time so that developers from
China can also participate.
Hi Rajan,
Thank you for your PR.
The main difference lies in whether 10MB is enough and memory doubling problem,
which is caused by different business scenarios.
In some business scenario, the QPS of 20k/s is considered to be very low, and
requests exceeding this order of magnitude are common.
I
39 matches
Mail list logo
