编年史队列复制错误：收到主机 ID 的处理程序：1，我的主机 ID 是：2 这可能是配置错误

Question

I am currently testing and learning chronicle-queue enterprise replication using the documentation below:

https://github.com/OpenHFT/Chronicle-Queue/blob/ea/docs/replication.adoc#the-mechanics-of-chronicle-queue-replication

https://github.com/OpenHFT/Chronicle-Queue/blob/ea/docs/queue-replication-message-protocol-overview.adoc#sinkreplicationhandler

However, I am getting the error below:

java.lang.IllegalArgumentException : Received a handler for host ID: 1, my host ID is: 2 this is probably a configuration error.

My replication configuration is as below, what am I missing? Below is my replication configuration.

!ChronicleQueueReplicationCfg {
  eventId: "",
  serviceId: "",
  replicaSets: {
    global: !!set [
      host1,
      host2
    ]
  },
  allowSinkToSource: false,
  context: {
    networkContextFactory: !software.chronicle.enterprise.queue.replication.QueueClusterNetworkContext$Factory INSTANCE,
    heartbeatTimeoutMs: 500000,
    heartbeatIntervalMs: 300000,
    pauserSupplier: !PauserMode busy,
    replicationPauserSupplier: !!null "",
    affinityCPU: !!null "",
    wireType: BINARY_LIGHT,
    localIdentifier: 1,
    localName: host1,
    serverThreadingStrategy: SINGLE_THREADED,
    retryInterval: 1000,
    procPrefix: !!null "",
    baseSourcePath: source,
    baseSinkPath: replica,
    backfillTimeoutListener: !software.chronicle.enterprise.queue.replication.NoopBackfillListener INSTANCE,
    tcpBias: !!null ""
  },
  hosts: {
    host1: { hostId: 1, tcpBufferSize: 0, connectUri: "localhost:5001" },
    host2: { hostId: 2, tcpBufferSize: 0, connectUri: "localhost:5002" }
  },
  queues: {
    queue1: {
      name: queue1,
      path: queue1,
      replicaSets: [
        global
      ],
      masterId: 1,
      waitForSinks: 0
    }
  }
}

chronicle-queue-enterprise-all-2.23ea26

Answer 1

I'm posting this as an answer since I need to share some configuration.

Your configuration seems correct, however, there might be an issue with the code that is utilizing it. Within chronicle-queue-enterprise there are many tests that showcase how to use the replication features.

The simplest one you can apply your configuration to is called ReplicationTest.shouldReplicate . This test simply writes two messages to the source and verifies that it can read the same messages from the sink (which would mean that replication worked).

I applied your configuration in this test with minor changes.

!ChronicleQueueReplicationCfg {
  eventId: "",
  serviceId: "",
  replicaSets: {
    global: !!set [
      host1,
      host2
    ]
  },
  allowSinkToSource: false,
  context: {
    networkContextFactory: !software.chronicle.enterprise.queue.replication.QueueClusterNetworkContext$Factory INSTANCE,
    heartbeatTimeoutMs: 500000,
    heartbeatIntervalMs: 300000,
    pauserSupplier: !PauserMode busy,
    replicationPauserSupplier: !!null "",
    affinityCPU: !!null "",
    wireType: BINARY_LIGHT,
    localIdentifier: 1,
    localName: host1,
    serverThreadingStrategy: SINGLE_THREADED,
    retryInterval: 1000,
    procPrefix: !!null "",
    baseSourcePath: "replica/source",
    baseSinkPath: "replica/sink$hostId",
    backfillTimeoutListener: !software.chronicle.enterprise.queue.replication.NoopBackfillListener INSTANCE,
    tcpBias: !!null ""
  },
  hosts: {
    host1: { hostId: 1, tcpBufferSize: 0, connectUri: host.port1 },
    host2: { hostId: 2, tcpBufferSize: 0, connectUri: host.port2 }
  },
  queues: {
    queue1: {
      name: queue1,
      path: queue1,
      acknowledge: true,
      allowUnknownSinks: true,
      replicaSets: [
        global
      ],
      masterId: 1,
      waitForSinks: 0
    }
  }
}

I could not replicate the same IllegalArgumentException you were having, please share the code that uses your configuration and I'm sure we will find out what's wrong and update this answer.

Answer 2

I am going to answer my own question based on the feedback given. The issue was caused by me passing the same instance of the ChronicleQueueReplicationCfg to each side of the replication when I was creating the ReplicatedQueue objects. I had missed that the ChronicleQueueReplicationCfg objects were stateful when the replication starts up.