Fix Pulsar Producer Already Closed Error (2026)

A Pulsar producer is failing with an "Already Closed" error because the underlying connection to the broker has been shut down unexpectedly, and the producer is attempting to send data on a defunct channel.

Common Causes and Fixes

1. Broker Restart or Unavailability:

• Diagnosis: Check broker logs for restart events or network connectivity issues. Use pulsar-admin brokers list to see if brokers are responsive. If you’re using a managed Pulsar service, check their status page.
• Fix: If a broker restarted, the producer client library usually has automatic reconnection logic. If it persists, you might need to manually re-initialize the producer. In your application code, wrap producer creation and send operations in a try-catch block that catches PulsarClientException and attempts to recreate the producer.

  try {
      producer.send(message);
  } catch (PulsarClientException e) {
      log.error("Producer error, attempting to recreate: {}", e.getMessage());
      // Recreate producer here
      producer.close(); // Close the old one if possible
      producer = createNewProducer(); // Your function to create a new producer
  }
  

• Why it works: This forces the producer to establish a new connection to a healthy broker, bypassing the old, closed connection.

2. Network Interruption (Firewall, Load Balancer, Network Glitch):

• Diagnosis: Examine network device logs (firewalls, load balancers) between the producer and brokers. Use tcpdump on the producer host to observe if TCP connections to brokers are being reset (RST flag). Check for consistent packet loss or high latency.
• Fix: Ensure your network infrastructure is stable. If a firewall is timing out idle connections, configure it to allow longer idle times for Pulsar’s port (usually 6650 or 8080). For load balancers, check their idle timeout settings and ensure they are not aggressively terminating connections.

  # Example: If using iptables, to allow connections for 1 hour (3600 seconds)
  sudo iptables -I INPUT -p tcp --dport 6650 -m state --state ESTABLISHED,RELATED -j ACCEPT
  sudo iptables -I OUTPUT -p tcp --dport 6650 -m state --state ESTABLISHED,RELATED -j ACCEPT
  # Note: This is a simplified example; actual firewall rules depend on your setup.
  

• Why it works: By preventing intermediate network devices from tearing down the connection due to inactivity or misconfiguration, the producer’s session with the broker remains intact.

3. Producer Client Timeout Configuration:

• Diagnosis: Pulsar clients have various timeouts. The operationTimeout in PulsarClientConfig or ProducerConfig can cause the client to abandon operations if they take too long, which can sometimes lead to a state where the underlying connection is considered broken by the client. Check the client configuration for operationTimeoutMs.
• Fix: Increase the operationTimeoutMs value. The default is often 30 seconds. For high-latency networks or busy brokers, you might need 60 seconds or more.

  PulsarClient client = PulsarClient.builder()
      .serviceUrl("pulsar://localhost:6650")
      .operationTimeout(60, TimeUnit.SECONDS) // Increased timeout
      .build();
  

• Why it works: A longer timeout allows the client to wait for acknowledgments from the broker for longer periods, preventing premature closure of the connection due to perceived slowness.

4. Broker Resource Exhaustion:

• Diagnosis: Monitor broker CPU, memory, and network I/O. High resource utilization on brokers can lead to slow responses, connection drops, or brokers actively closing connections they can’t service. Check broker logs for OutOfMemoryError, excessive garbage collection, or warnings about high load.
• Fix: Scale up broker resources (CPU, RAM) or scale out the number of brokers in your cluster. Optimize broker configurations if possible (e.g., adjust JVM heap size).

  # Example: Adjusting JVM heap for BookKeeper and Broker (in pulsar-env.sh)
  export BOOKKEEPER_EXTRA_OPTS="-Xms2g -Xmx4g"
  export BROKER_EXTRA_OPTS="-Xms2g -Xmx4g"
  

• Why it works: Ensuring brokers have adequate resources prevents them from becoming unresponsive or actively closing client connections due to overload.

5. Large Message Batching and Broker Limits:

• Diagnosis: If your producer is sending very large messages or a high volume of messages in rapid succession, it might hit internal broker limits for message size or connection throughput. The broker might close the connection to protect itself. Check broker logs for messages related to exceeding limits.
• Fix:
  • Reduce Message Size: If possible, break down large messages into smaller ones.
  • Adjust Batching: Configure the producer’s batchingMaxPublishDelay and batchingMaxMessages to send smaller batches or individual messages more frequently.
  • Broker Configuration: For extremely high throughput, review broker-side configurations like maxMessageSize and maxConnectionsPerBroker (though these are less common causes of "Already Closed" than client-side issues).

  Producer<byte[]> producer = client.newProducer()
      .topic("my-topic")
      .batchingMaxPublishDelay(100, TimeUnit.MILLISECONDS) // Send smaller batches more often
      .batchingMaxMessages(100) // Limit messages per batch
      .create();
  

• Why it works: By sending data in smaller, more manageable chunks or at a more controlled rate, you avoid overwhelming the broker’s processing capabilities or hitting specific message-handling limits, thus keeping the connection alive.

6. Producer Client Library Bug or State Corruption:

• Diagnosis: This is less common but can happen. If the issue is intermittent and doesn’t correlate with external factors, it might be a bug in the Pulsar client library version you are using. Check the client library’s GitHub issues for similar reports.
• Fix: Upgrade to the latest stable version of the Pulsar client library. If the problem persists, consider downgrading to a previous known stable version or filing a bug report with the Pulsar community.

  # Example: Maven dependency update
  <dependency>
      <groupId>org.apache.pulsar</groupId>
      <artifactId>pulsar-client-all</artifactId>
      <version>2.10.0</version> <!-- Update to latest stable -->
  </dependency>
  

• Why it works: A bug fix in a newer version might resolve an edge case that leads to the producer’s internal state becoming corrupted, causing it to incorrectly believe the connection is closed.

The next error you’ll likely encounter if the underlying connection issues are resolved but the producer object itself is still in a bad state is a NullPointerException or a similar error when trying to access methods on a producer variable that wasn’t properly re-initialized after a previous failure.