the version nacos-client

[pengbiaobeyond]

the latest version of nacos-client 2.x ,but the version of shardingsphere dependence is 1.4.2

[pengbiaobeyond]

the version of nacos-server is 2.2.0, What is the impact？

[zhaojinchao95]

the version of nacos-server is 2.2.0, What is the impact？

ShardingSphere use 1.x version reason is use nacos NamingServer feature. And We don't know any impact, you can try it.

[pengbiaobeyond]

nacos of 2.x version have NamingServer feature, why we not used 2.x nacos

[pengbiaobeyond]

What you said above is the reason for using nacos, not the reason for using 1. x

[zhaojinchao95]

nacos of 2.x version have NamingServer feature, why we not used 2.x nacos

Are you interested in adapter 2.x?

[pengbiaobeyond]

yes,I want to adapter the latest version of nacos.

[linghengqian]

• Add license declare for Nacos and its dependencies #21343 (comment) has historical background.

• At the same time, I tried to increase the version of Nacos Client to 2.x locally, which resulted in ./mvnw clean -Prelease test timeout, which is the same as Bump up nacos to 2.1.2 skywalking#9799 (comment) . Consistent, I'm not sure if this is a bug of Nacos Client.

• Anyway, welcome to investigate? 🤣

[caqhy]

nacos of 2.x version have NamingServer feature, why we not used 2.x nacos

nacos-client1.x supports the same client to register multiple instances, but nacos-client2.x only allows one client to register one instance. nacos-server2.0 can be compatible with nacos-client1.x, so we use nacos-client1.x to achieve the purpose of registering multiple instances for the same client.
registerInstance 注册覆盖前面的实例，不能注册多实例 #5863

[pengbiaobeyond]

thanks

[caqhy]

thanks

I heard that Nacos plans to completely delete 1. x. If so, from the ShardingSphere scenario, there is no way to continue using Nacos.

[pengbiaobeyond]

thanks

[pengbiaobeyond]

I think the same client to register one instance

[pengbiaobeyond]

I understand instance is ip:port, the idea is correct？

[caqhy]

I understand instance is ip:port, the idea is correct？

ShardingSphere needs to push multiple ephemeral metadata and listen for metadata changes based on prefix key, but ConfigServer does not support these features right now. So NamingServer was chosen to solve these problems. In fact, this is not a good solution.

[caqhy]

I understand instance is ip:port, the idea is correct？

We only care about the instance's field metadata.

[pengbiaobeyond]

I understand, thank you

[caqhy]

I understand instance is ip:port, the idea is correct？

In addition, Nacos' caching mechanism also causes ShardingSphere to be unable to get the latest metadata just pushed.

[kezhenxu94]

Just FYI, seems the issue of mvn timeout doesn't exist any more, see apache/skywalking#12362

[linghengqian]

Just FYI, seems the issue of mvn timeout doesn't exist any more, see apache/skywalking#12362

• Actually the relevant code is now at https://github.com/apache/shardingsphere-plugin/tree/main/mode/cluster/repository/nacos . I don't think there is anything that can be done in the master branch of shardingsphere.

[linghengqian]

• I noticed at Unsupport using Etcd as the registry in shardingsphere proxy #33565 that due to multiple cross-community issues on the shardingsphere-elasticjob side, the shardingsphere metadata center other than zookeeper and jdbc can actually only be used on shardingsphere jdbc. For shardingsphere proxy, only zookeeper and jdbc can be used as shardingsphere metadata center.
• I think the current issue should be shelved for now.