Hi,
>> >> And for the Admin API, we have several supported params
> getStats(Map)/getInternalStats(Map)
> I will update the PIP with this API change and please let me know if
there is any other suggestion.
I have updated PIP with API change to address concerns of supported params.
Thanks,
Rajan
Hi Penghui,
>> And for the Admin API, we have several supported params
Good point regarding the stats/internal-stats params. I think we can pass
option-map into below GET API for stats so, we can easily enhance if more
options would be added in future and each option data-type can be
documented i
I have no strong objection. Just a few questions.
How do we handle the stats/internal-stats of a partitioned topic?
As I understand, the client side will combine the stats/internal-stats
of the partitions? It's better to clarify in the proposal.
Do we need a compatibility section to clarify the b
Well useful fields really depend on the applications and different usecases
require different fields and it can eventually end up covering all.
Therefore, we should try to create a protocol which can transport
stats/internal and client should be able to represent that data to
applications in a stan
I understand the need for this PIP and I support it, but I have some
questions/open points.
I wonder if we should define a smaller subset of the stats/internal
stats to serve to the clients using this new Request/Response.
Maybe it is better to serve only the minimal amount of data that is useful.
There are multiple factors tcp would be better than http when you are
considering performance and scale due to lower overhead, faster parsing,
more control over connection, congestion control, etc and that could be
reasons why we have tcp binary protocol for producers/consumers
communication with s
If I dive into the exact details of the cause of the
performance implications in current Admin HTTP API:
Do you think the root cause of the performance is the Jersey implementation
of `AsyncResponse.resume(stats)` which takes a thread from a thread pool,
serialize the object and then performs a bl
Communicating over binary protocol is more scalable and performant than
HTTP. Admin API over http has a long history of bottleneck and performance
issues which could also sometimes be a bottleneck for lookup requests and
that was the reason we introduced lookup over binary protocol as well. We
have
Before I dive into the PIP, I have several questions on the background
provided below:
On Tue, May 9, 2023 at 9:08 AM Rajan Dhabalia wrote:
> Hi,
>
> Right now, Pulsar provides the topic's stats and stats-internal over HTTP
> admin API, and this stats data is used by user applications and also
