Client configuration is missing the listenerName parameter

[lluiscab]

Hi,

Would it be possible to expose the listenerName configuration param from the C++ client?

https://pulsar.apache.org/api/cpp/2.10.0-SNAPSHOT/classpulsar_1_1_client_configuration.html#a2b77a5eb371640f243524a0eed71bc08

[Matt-Esch]

It doesn't appear to be exposed in the c api which is used by this module https://github.com/apache/pulsar/blob/master/pulsar-client-cpp/lib/c/c_ClientConfiguration.cc - I would expect something like pulsar_client_configuration_set_listener_name

I think we would do a lot better to not use the c api but that's a huge refactor.

[lluiscab]

Yeah :/

I did make a try to implement it myself but I could not find anything exposed by the C api, is there a reason why this module is using the c api when it says in the documentation that it uses the C++ one? The README says: because it uses the [node-addon-api](https://github.com/nodejs/node-addon-api) module to wrap the C++ library. so I'd expect this library to be using the C++ library, not the C one, is that a documentation error then?

I'm trying to connect to a pulsar broker hosted on a k8s cluster from an outside network (Using a public ip address) and not being able to specify the listenerName makes it impossible to connect as the library is picking up the internal (svc.cluster.local) advertised address instead of using the one advertised as external

[Matt-Esch]

I'm not sure what your full use case is but you might want to look at https://github.com/ayeo-flex-org/pulsar-flex - I haven't looked at it properly yet because it doesn't seem complete but it might be easier to extend or complete enough for your use case.

I'm generally very dissatisfied with the c++ library let alone the node binding. I'm currently chasing down an issue with a race condition on close that causes a segfault. That should stir some level of caution around using this library and it clearly needs a lot of work. I think the reason for using the c api is that it's more stable between versions, so that also means not having the latest features. I did briefly look at using the C++ api because there are features missing for the async interface (that and the memory management is exceptionally painful).

[roryschadler]

Started a PR to expose this in the C API here: apache/pulsar-client-cpp#370

Once that's merged/released, I'd be happy to do the same here.

[roryschadler]

@Matt-Esch unrelated to this issue, but I'm now also dealing with a segfault, and it seems like it's around the .close methods, in my case combined with a listener callback: #374. Is this similar to the issue you faced, do you remember? Did you ever find a solution?

[lluiscab]

Hey @roryschadler, given that v3.5.0 of the cpp client has been published containing apache/pulsar-client-cpp#370, is there any ETA on resolving this issue?

I've never developed any node project that used bindings so I'm not sure I could open a PR myself, specially given that there are new methods that need to be "bound" and exposed by the node client.

[roryschadler]

@lluiscab I missed the release, thanks for the heads up! I have a draft PR here (been using this change locally for a while), need to add tests and then it'll be ready for review. #375