Dmitry Kropachev

> > As @mykaul suggested it is indeed resolved by [apache@1134c70](https://github.com/apache/cassandra-java-driver/commit/1134c709f64a0d15664713f375e5d0d3850c4522), which have ended up in `4.18.1`. Let's sync with upstream to get it in. > > I see it...

After https://github.com/scylladb/java-driver/pull/332 we finally have infrastructure to test DNS cases. @Bouncheck , could you please make a test for scenario when cluster of three nodes that is targeted by driver...

@avelanarius, let us know if you be able to finish PR, otherwise someone else should pick it up

it looks like this one is stuck, let's move it to https://github.com/scylladb/gocql/pull/211

original issue is solved. shard api issue - https://github.com/scylladb/gocql/issues/200

@moguchev , thanks for contribution, I see you put lots of effort into it. @sylwiaszunejko, I think we should not merge it as it is, functionally it is correct, except...

> Thanks! I hope you'll add this in API Thanks for you contribution, it give us very good clue, I have created an [issue](https://github.com/scylladb/gocql/issues/200) based on this PR, we would...

I would recommend to use `atomic.Pointer` instead, please take a look [this paper](https://github.com/go-auxiliaries/perf-geek/blob/main/state-consistency/README.md#3-use-atomic-pointer-to-a-state-with-mutex-to-negate-state-submitting-collisions) Since `HostInfo` experiance mostly read access, referred solution is going to be up to `90 times` faster...

@moguchev , I have given a try to `atomic update`, it is too intrusive and is going to create lot's of conflict with `upstream`, so it is better not to...

True, but we need to consider many cases, like tablets, busy shard(connection) handling, lwt handling, other type of partitioners. Other part of the issue that could be handled at the...