Troubleshooting VAST Event Broker

Applies to VAST Cluster 5.5.

Find what you're seeing in the tables below. Each row gives the likely cause and the fix, and links to the page with the details. Kafka error names are shown as the broker or client reports them, for example INVALID_PARTITIONS. Your client library may print them in another form. For errors from the VAST DataBase SDK that aren't about topics, see the VAST DataBase troubleshooting page.

Connecting

Connection closed with no error

When a request uses an API key the broker doesn't support, or a version outside the range it advertises, VAST Event Broker closes the TCP connection without sending an error code. Apache Kafka brokers do the same. The client sees a disconnect, reconnects and may send the same request again.

Most clients check the broker's supported versions first and fail on the client side instead: confluent-kafka raises _UNSUPPORTED_FEATURE. You'll see the disconnects when a client, a tool or a framework sends one of these anyway:

• InitProducerId, from an idempotent or transactional producer. See idempotence.
• CreatePartitions, IncrementalAlterConfigs, DeleteRecords, DescribeCluster, or the ACL calls, from an admin client or a command-line tool.
• ConsumerGroupHeartbeat, from a consumer set to group.protocol=consumer.

Find which call the client was making when it was disconnected, and turn off or replace that call. Kafka compatibility lists the supported APIs and versions.

Authentication and authorization

Authorization isn't enforced until it's turned on

Identity-policy statements for Kafka actions (KafkaRead, KafkaWrite, KafkaCreate, KafkaDelete and the others in security) take effect only when the platform team turns on authorization for the Kafka view. Until then, the broker allows every operation, for every client, authenticated or not.

When authorization is on, the broker allows an operation only if a statement in the user's identity policy allows it. A request that matches no statement is denied, and so is a request from a connection that hasn't authenticated. That's why the view must also require SASL/PLAIN or mTLS on at least one connection type before authorization can be turned on.

Producing

The producer fails to initialize with idempotence

An idempotent producer starts by asking the broker for a producer ID with InitProducerId. VAST Event Broker doesn't support that API, so the producer can't start. Depending on the client, you get an error at start-up, an error on the first send, or the broker closes the connection. The Java producer turns idempotence on by default from Apache Kafka 3.0, and so does kafka-python 3.x. confluent-kafka leaves it off by default. Whatever your client's default, set it off explicitly.

With kafka-python 3.x, pass enable_idempotence=False to KafkaProducer. With confluent-kafka:

import os

producer_config = {
    "bootstrap.servers": os.environ["KAFKA_BOOTSTRAP"],
    "enable.idempotence": False,
    "compression.type": "none",
}

Without idempotence, a producer that retries after a timeout can write the same record twice. Make consumers tolerate duplicates. See producing.

Topics and configs

Consuming

Querying topic tables

See querying topics.

Before you ask for help

Collect these for the platform team:

• The client library and its version, for example confluent-kafka 2.8.
• The client configuration, without passwords: bootstrap.servers, security.protocol, sasl.mechanism, enable.idempotence, compression.type, group.protocol.
• The Kafka view's bucket, the topic and the consumer group.
• The full error, and the time it happened.

See also

• Kafka compatibility
• Topic configuration
• Limits
• Security
• Producing and consuming
• VAST DataBase troubleshooting and error reference