Thanks
Enrico
Il giorno lun 5 apr 2021 alle ore 23:32 Ali Ahmed
ha scritto:
>
> I have uploaded the macosx big sur builds for the python client to pypi. It's
> early work . Feel free to test any report on any issues.
>
> https://files.pythonhosted.org/packages/b8/20/e4e717a358570adbdaf43db4327f
I think I was able to resolve that issue. Fortunately, only
FunctionResultRouter had the singleton behavior, so resolving that was
straightforward. The current PR for part 1 is here (in my personal CI):
https://github.com/devinbost/pulsar/pull/5/files
Once the tests look good, I'll submit a PR to A
Hi All,
Recently in the pulsar slack channel, someone asked about the scalability
(and limits) of the number of topics in a pulsar cluster. Addison Higham
responded with the following:
> For numbers of topics, there is a few notes:
> - you will want to spread these topics over a sufficient number
It appears that the reason the router classes are singletons is to ensure
the clock behavior is consistent across producers.
I wonder if we might be able to avoid creating a breaking change by
refactoring out the clock into a singleton that could be shared across the
routers, which we could then ma
k2la opened a new pull request #149:
URL: https://github.com/apache/pulsar-client-node/pull/149
Support disable replication.
Because `disableReplication` is not working in pulsar-client-cpp 2.7.0 or
previous version, needs 2.7.1 or later version.
This bug fixed in https://github.
Jerry,
Thanks for the information and for the links!
Thanks also for the suggestion to split the PR into two parts. That will
make it easier to get some of this work completed in time for the 2.8.0
release.
While working on the first part, I discovered something that needs
community attention. I
I have uploaded the macosx big sur builds for the python client to pypi.
It's early work . Feel free to test any report on any issues.
https://files.pythonhosted.org/packages/b8/20/e4e717a358570adbdaf43db4327f19603764d5b137885bb38fad52700768/pulsar_client-2.7.0-cp37-cp37m-macosx_11_0_x86_64.whl
h
>
> The interceptor would be loaded at function registration.
The interceptor classes should be loaded at broker/worker startup time.
In order for an
> interceptor to be picked up, a jar would need to be compiled with the class
> that implements the interface, and the jar would need to be deplo
Here's my understanding of what I'd need to do to implement the interceptor
approach.
The interceptor would be loaded at function registration. In order for an
interceptor to be picked up, a jar would need to be compiled with the class
that implements the interface, and the jar would need to be dep
If we use the interceptor approach, does that mean a cluster-admin would
need to write custom code in order to override the function producer
settings? I worry about adding additional burden to cluster administration.
--
Devin G. Bost
On Sat, Apr 3, 2021, 8:26 AM Devin Bost wrote:
> Hi Rui,
>
>
Thanks for the instruction, I’ll take a look later.
Regards
Yunze Xu
> 2021年4月6日 上午1:38，Devin Bost 写道：
>
> Check out the instructions by Lari Hotari here about how to setup your
> personal Github CI:
> https://markmail.org/message/xapp7aguh44osqhm
>
> I've been working through similar issues a
Check out the instructions by Lari Hotari here about how to setup your
personal Github CI:
https://markmail.org/message/xapp7aguh44osqhm
I've been working through similar issues as I've been facing a
NullPointerException (in a PR of mine) that consistently occurs in Github
but never occurs locally
This flaky test have existed for a long time, even before I contributed my
first PR to Pulsar. I’ve been looking into the problem for several times but
all blocked for that I cannot reproduce it in my local environment.
From the code and logs, it looks like the cleanup phase encountered a
segme
13 matches
Mail list logo
