What causes "Trying to re-connect to graphite server" in apache/druid?

Confirm Graphite/carbon is reachable and not restarting; check server-side idle timeouts.

Trying to re-connect to graphite server

Error message

Trying to re-connect to graphite server

What it means

The Graphite emitter's send thread keeps a long-lived socket to the Graphite server. When a SocketException occurs (typically the socket being closed by the server or NAT after long inactivity), the emitter closes the stale connection, logs this warning, and immediately reconnects so subsequent events are not lost.

Solutions

Confirm Graphite/carbon is reachable and not restarting; check server-side idle timeouts.
Enable the emitter's flush period/waitForTime settings so connections see periodic traffic, or enable TCP keepalive on the host to keep NAT/firewall state alive.
Verify network appliances (LBs, NAT gateways) between Druid and Graphite are not silently dropping idle flows; if they are, this warning is expected benign self-healing.
If reconnection itself fails repeatedly, check DNS resolution and graphite host/port configuration (graphite.hostname, graphite.port).

Defensive patterns

Strategy: retry

Validate before calling

try (Socket s = new Socket()) {
  s.connect(new InetSocketAddress(graphiteHost, graphitePort), 3000);
} // pre-check connectivity before emitting

Try / catch

catch (InterruptedIOException e) {
  Thread.currentThread().interrupt();
  break;
} catch (SocketException e) {
  graphite.close();
  graphite.connect(); // emitter reconnects automatically
}

Prevention

Enable TCP keepalive or send periodic heartbeats to keep idle sessions alive.
Align emitter flush period with firewall/NAT idle timeouts so the socket carries traffic.
Monitor this warning rate; a persistent stream means Graphite or the network is flapping.
Verify graphite host/port config after any Graphite/carbon topology change.

When it happens

Trigger: The graphite socket raises SocketException during event flush: Graphite server closed an idle connection, network interruption, firewall dropping the long-lived TCP session, or Graphite restart.

Common situations: Production setups with idle periods longer than the server's or an intermediary's TCP idle timeout; Graphite/carbon relay restarts; containerized environments where idle connections are reaped.

Related errors

AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07). Data as JSON: /api/errors/ced16c89f698467a. Report an issue: GitHub.

Appendix: source

Thrown at extensions-contrib/graphite-emitter/src/main/java/org/apache/druid/emitter/graphite/GraphiteEmitter.java:208

                  graphiteEvent.getTimestamp()
              );
              graphite.send(
                  graphiteEvent.getEventPath(),
                  graphiteEvent.getValue(),
                  graphiteEvent.getTimestamp()
              );
            }
          }
          catch (InterruptedException | IOException e) {
            log.error(e, e.getMessage());
            if (e instanceof InterruptedException) {
              Thread.currentThread().interrupt();
              break;
            } else if (e instanceof SocketException) {
              // This is antagonistic to general Closeable contract in Java,
              // it is needed to allow re-connection in case of the socket is closed due long period of inactivity
              graphite.close();
              log.warn("Trying to re-connect to graphite server");
              graphite.connect();
            }
          }
        }
      }
      catch (Exception e) {
        log.error(e, e.getMessage());
        if (e instanceof InterruptedException) {
          Thread.currentThread().interrupt();
        }
      }
    }
  }

  @Override
  public void flush()
  {
    if (started.get()) {

View on GitHub (pinned to 9b90983fd2)