Field | Description/Action |
Package | The package in which to create the connection. You must create the package using Designer before you can specify the package using this parameter. For general information about creating packages, see the webMethods Service Development Help for your release. Note: Configure the connection in a user-defined package rather than in the adapter's package. For other important considerations when creating packages for Adapter for Apache Kafka, see Overview of Package Management |
Folder Name | Specifies the folder in which you create the connection. |
Connection Name | Specifies the name you want to give to the connection. Connection names cannot have spaces or use special characters reserved by Integration Server and Designer. For more information about the use of special characters in package, folder, and element names, see the webMethods Service Development Help for your release. |
Field | Description/Action |
Bootstrap Servers | The list of servers with the combination of host and port used for establishing the initial connection to the Apache Kafka cluster. This list should be in the form, host1:port1,host2:port2 and so on. |
Acknowledgments | The number of acknowledgments the producer requires the leader to have received before considering a request as complete. This controls the durability of messages that are sent. The values allowed and their descriptions are as follows: If set to 0, the producer will not wait for any acknowledgment from the server. The message will be immediately added to the socket buffer and considered as sent. No guarantee can be made that the server has received the message. The configuration will not take effect if you retry. The offset given back for each message will always be set to -1. If set to 1, the leader will write the message to its local log, but will respond without awaiting for the full acknowledgement from all followers. In this case should the leader fail immediately after acknowledging the record but before the followers have replicated it, then the message is lost. If set to all, the leader will wait for the full set of in-sync replicas to acknowledge the message. This guarantees that the message will not be lost as long as at least one in-sync replica remains alive. This is the strongest available guarantee. |
Request Timeout(ms) | The configuration controls the maximum amount of time the client will wait for the response of a request. If the response is not received before the timeout elapses, the client will resend the request if necessary or fail the request if retries are exhausted |
Value Serializer Class | Defines the serializer class for value that implements the org.apache.kafka.common.serialization.Serializer interface. By default, com.wm.adapter.wmkafka.idata.IDataSerializer is used. |
Key Serializer Class | Defines the serializer class for key that implements the org.apache.kafka.common.serialization.Serializer interface. |
Partitioner Class | Defines the partitioner class that implements the Partitioner interface. |
Compression Type | Defines the compression type for all data generated by the producer. |
Message Send Retries | Causes the client to resend any message whose send fails with a potentially transient error, if the value greater than zero. |
Batch Size | The producer will attempt to batch messages together into fewer requests whenever multiple messages are being sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. |
Send Buffer Bytes | The size of the TCP send buffer SO_SNDBUF to use when sending data. If the value is set to -1, then the default OS will be used. |
Client ID | Defines the ID string to pass to the Kafka server when you make requests. |
Other Properties | Specifies the Kafka related properties for additional configuration. Use the following format: propertyName1=value;propertName2=value |
Field | Description/Action |
Enable Connection Pooling | Enables the connection to use connection pooling. For more information about connection pooling, see
Adapter Connections . Note: If you plan to enable connection pooling in a clustered environment, consider the connection pool size. |
Minimum Pool Size | If connection pooling is enabled, this field specifies the number of connections to create when the connection is enabled. The adapter will keep open the number of connections you configure here regardless of whether these connections become idle. |
Maximum Pool Size | If connection pooling is enabled, this field specifies the maximum number of connections that can exist at one time in the connection pool. |
Pool Increment Size | If connection pooling is enabled, this field specifies the number of connections by which the pool will be incremented if connections are needed, up to the maximum pool size. |
Block Timeout | If connection pooling is enabled, this field specifies the number of milliseconds that Integration Server will wait to obtain a connection with the database before it times out and returns an error. For example, you have a pool with Maximum Pool Size of 20. If you receive 30 simultaneous requests for a connection, 10 requests will be waiting for a connection from the pool. If you set the Block Timeout to 5000, the 10 requests will wait for a connection for 5 seconds before they time out and return an error. If the services using the connections require 10 seconds to complete and return connections to the pool, the pending requests will fail and return an error message stating that no connections are available. If you set the Block Timeout value too high, you may encounter problems during error conditions. If a request contains errors that delay the response, other requests will not be sent. This setting should be tuned in conjunction with the Maximum Pool Size to accommodate such bursts in processing. |
Expire Timeout | If connection pooling is enabled, this field specifies the number of milliseconds that an inactive connection can remain in the pool before it is closed and removed from the pool. The connection pool will remove inactive connections until the number of connections in the pool is equal to the Minimum Pool Size. The inactivity timer for a connection is reset when the connection is used by the adapter. If you set the Expire Timeout value too high, you may have a number of unused inactive connections in the pool. This consumes local memory and a connection on your backend resource. This could have an adverse effect if your resource has a limited number of connections. If you set the Expire Timeout value too low, performance could degrade because of the increased activity of creating and closing connections. This setting should be tuned in conjunction with the Minimum Pool Size to avoid excessive opening/closing of connections during normal processing. |
Startup Retry Count | The number of times that the system should attempt to initialize the connection pool at startup if the initial attempt fails. The default value is 0. |
Startup Backoff Timeout | The number of seconds that the system should wait between attempts to initialize the connection pool. |