Standard implementation of the PulsarClientService. Provides the ability to create Pulsar Producer / Consumer instances on demand, based on the configuration properties defined.
Pulsar, client, pool
In the list below, the names of required properties appear in bold. Any other properties (not in bold) are considered optional. The table also indicates any default values, and whether a property supports the NiFi Expression Language.
| Display Name | API Name | Default Value | Allowable Values | Description |
|---|---|---|---|---|
| Pulsar Service URL | PULSAR_SERVICE_URL | URL for the Pulsar cluster, e.g. pulsar://localhost:6650 Supports Expression Language: true (will be evaluated using variable registry only) | ||
| Pulsar Client Authentication Service | AUTHENTICATION_SERVICE | Controller Service API: PulsarClientAuthenticationService Implementations: PulsarClientJwtAuthenticationService PulsarClientTlsAuthenticationService PulsarClientOauthAuthenticationService PulsarClientAthenzAuthenticationService | Specifies the Service to use for authenticating with Pulsar. | |
| Maximum concurrent lookup-requests | CONCURRENT_LOOKUP_REQUESTS | 5000 | Number of concurrent lookup-requests allowed on each broker-connection. Supports Expression Language: true (will be evaluated using variable registry only) | |
| Maximum connects per Pulsar broker | CONNECTIONS_PER_BROKER | 1 | Sets the max number of connection that the client library will open to a single broker.
By default, the connection pool will use a single connection for all the producers and consumers. Increasing this parameter may improve throughput when using many producers over a high latency connection. Supports Expression Language: true (will be evaluated using variable registry only) | |
| I/O Threads | IO_THREADS | 1 | The number of threads to be used for handling connections to brokers. Supports Expression Language: true (will be evaluated using variable registry only) | |
| Keep Alive interval | KEEP_ALIVE_INTERVAL | 30 sec | The keep alive interval in seconds for each client-broker-connection. Supports Expression Language: true (will be evaluated using variable registry only) | |
| Listener Threads | LISTENER_THREADS | 1 | The number of threads to be used for message listeners Supports Expression Language: true (will be evaluated using variable registry only) | |
| Maximum lookup requests | MAXIMUM_LOOKUP_REQUESTS | 50000 | Number of max lookup-requests allowed on each broker-connection. To prevent overload on broker, it should be greater than the 'Maximum concurrent lookup-requests' property value. Supports Expression Language: true (will be evaluated using variable registry only) | |
| Maximum rejected requests per connection | MAXIMUM_REJECTED_REQUESTS | 50 | Max number of broker-rejected requests in a certain time-frame after which current connection will be closed and client creates a new connection that gives chance to connect a different broker. Supports Expression Language: true (will be evaluated using variable registry only) | |
| Operation Timeout | OPERATION_TIMEOUT | 30 sec | Producer-create, subscribe and unsubscribe operations will be retried until this interval, after which the operation will be marked as failed. Supports Expression Language: true (will be evaluated using variable registry only) | |
| Stats interval | STATS_INTERVAL | 60 sec | The interval between each stat infomation update. It should be set to at least 1 second. Supports Expression Language: true (will be evaluated using variable registry only) | |
| Allow TLS Insecure Connection | ALLOW_TLS_INSECURE_CONNECTION | false |
| No Description Provided. |
| Enable TLS Hostname Verification | ENABLE_TLS_HOSTNAME_VERIFICATION | false |
| It allows to validate hostname verification when client connects to broker over tls. It validates incoming x509 certificate and matches provided hostname(CN/SAN) with expected broker's host name. It follows RFC 2818, 3.1. Server Identity hostname verification. |
| Use TCP no-delay flag | USE_TCP_NO_DELAY | false |
| Configure whether to use TCP no-delay flag on the connection, to disable Nagle algorithm. No-delay features make sure packets are sent out on the network as soon as possible, and it's critical to achieve low latency publishes. On the other hand, sending out a huge number of small packets might limit the overall throughput, so if latency is not a concern, it's advisable to set the useTcpNoDelay flag to false. |