Hi, all

Currently, the Pulsar broker uses the field `client_version` to get
the version of the client. The client will send the client_version to
the broker through `CommandConnect` [0] during the connect or
`CommandAuthResponse ` [1] during the auth challenge. We could get the
client_version from the admin using `pulsar-admin topics stats xxx`
[2].

But the `client_version ` only shows the version information. And
clients in different languages use their own separate version numbers.
This can lead to conflict. For example, the java client 2.10.2 uses
the same value `2.10.2` as the C++ client 2.10.2. And C++ client 3.0.0
may conflict with the future java client 3.0.0. The information of
`client_version` is incomplete. We could not determine what
language(or specific library) the client uses. This raises
inconvenience for debugging.

I would like to propose adding the client language information to the
`client_version`. Like:
* `java-2.11.1` for Java client 2.11
* `cpp-3.1.2` for C++ client 3.1.2
* `go-0.9.0` for go client 0.9.0
We can easily do that because the `client_version` is a string type.

In addition, the Nodejs client and Python client all use the
client_version of C++ client they depend on. So it will use `3.1.2` as
the client_verion in Nodejs client 1.8.0. This is incorrect, and I
think we need to fix them. We don't need to print the C++ client
version because we can get that information if we know the Nodejs or
Python client version.

What do you think? Please share your thoughts if you have any ideas.

[0] 
https://github.com/apache/pulsar/blob/e0b50c9ec5f12d0fb8275f235d8ac00e87a9099e/pulsar-common/src/main/proto/PulsarApi.proto#L269
[1] 
https://github.com/apache/pulsar/blob/e0b50c9ec5f12d0fb8275f235d8ac00e87a9099e/pulsar-common/src/main/proto/PulsarApi.proto#L309
[2] https://pulsar.apache.org/docs/next/admin-api-topics/#get-stats

Thanks,
Zike Yang

Reply via email to