What's the current clientId generation rule in ClientConfig class? And how to reproduce it?

@huanwei

clientId:

 public String buildMQClientId() {
    StringBuilder sb = new StringBuilder();
    sb.append(this.getClientIP());
    sb.append("@");
    sb.append(this.getInstanceName());
    if (!UtilAll.isBlank(this.unitName)) {
        sb.append("@");
        sb.append(this.unitName);
    }
    return sb.toString();
}

instanceName:

private String instanceName = System.getProperty("rocketmq.client.name", "DEFAULT");

public void changeInstanceNameToPID() {
    if (this.instanceName.equals("DEFAULT")) {
        this.instanceName = String.valueOf(UtilAll.getPid());
    }
}

在docker环境下（使用host模式），获取到的clientIp和pid都是一样的。当然clientIp一样的确切原因还没完全确认，可能和引入Rancher有关。

#668

I encountered the same problem. Under HOST networking mode, all dockers managed by Rancher are with the same docker0 IP, which is 172.17.0.1. Thus, RemotingUtil.getLocalAddress() always returns "172.17.0.1" for those dockers, which leads to collision between consumers with the same pid, if using default "IP@pid" clientId.

• RocketMQ client Version: 4.3.2
• Rancher Version: 1.16.10
• Docker Version: 18.09.5

@huanwei This is a known problem in the docker container if we deploy mutl-docker containers in the one machine.

@caigy @huanwei if used Rancher to manage container, all docker will always return "172.17.0.1" when getLocalAddress, not only in bridge model, but also in host model, so I think it may be an issue caused by Rancher, so you can temporarily solve this problem by setting the instanceName.

That's known issue caused by Rancher container network. Setting different instanceName should solve this problem, just as @duhenglucky suggested.

Which version have been solved, I also meeting the same problem.

Has this be fixed?

除了通过手动自定义instanceName外，RocketMQ会做什么来兼容吗？还是不考虑兼容了？

I would like a more general way to completely solve the problem of instance conflicts. #3680