A number of errors occurring in the java driver

Hello, I just want to say thank you very much for your work, scylla is a really cool tool, but here I have a few questions, if you know the answer to them, please let me know.

Let me tell you right away that I work on Windows 11, but on our project we have docker, which runs the container with ScyllaDB
Driver version

  1. This WARN is not critical, but anyway, is there any way to solve this warning?
    Found Netty's native epoll transport, but not running on linux-based operating system. Using NIO instead.
  2. When sending a request to the database, a list of WARNs (about 10 pieces) pops up and reports Advanced shard awareness: requested connection to shard 1, but connected to 0. Is there a NAT between client and server?, I tried for a long time, but it didn’t work I couldn’t solve this problem, I hope you can help me, the request is being executed, but seeing it constantly in the log is quite confusing
  3. Well, probably the strangest thing is request hashing, I hash the request so that the database is not loaded with prepared requests, but the error that the request needs to be hashed also appears, I have rewritten the code, maybe this is a problem on my part, please let me know Please
    Re-preparing already prepared query is generally an anti-pattern and will likely affect performance. Consider preparing the statement only once. Query='INSERT INTO message (id, author, context, content, timestamp) VALUES (?, ?, ?, ?, ?)'
public class Cache {
    private PreparedStatement request;

    public Cache() {
        this.request = null;

    public PreparedStatement request(@NotNull PreparedStatement statement) {
        if (this.request == null || this.request.hashCode() != statement.hashCode()) {
            this.request = statement;

        return this.request;
private BoundStatement cache(@NotNull Session session) {
        return channel.getServer()

    public MessageCreateAction applyData(JsonObject data) {
        this.getProvider().insert("channel", session -> {
            return cache(session)
                    .setLong("id", Snowflake.generate())
                    .setLong("author", data.getJsonNumber("author").longValue())
                    .setLong("context", data.getJsonNumber("context").longValue())
                    .setString("content", data.getString("content"))
                    .setLong("timestamp", data.getJsonNumber("timestamp").longValue());

        return this;
public class ClusterConnectionFactoryProvider {
    private final ClusterConnectionFactorySource source;

    public ClusterConnectionFactoryProvider(Config config) {
        this.source = new ClusterConnectionFactorySource(config);

    public void insert(String database, @NotNull Function<Session, BoundStatement> function) {
                .doOnNext(session -> session.execute(function.apply(session)))
public class ClusterConnectionFactorySource {
    private final Cluster channel;

    public ClusterConnectionFactorySource(Config config) {
        this.channel = init("", 19042, "datacenter1");

    private static Cluster init(String hostname, int port, String cluster) {
        return Cluster.builder()
                .withAuthProvider(new PlainTextAuthProvider("username", "password"))
                .withAddressTranslator(new EC2MultiRegionAddressTranslator())

    private static DCAwareRoundRobinPolicy getPolicy(String cluster) {
        return DCAwareRoundRobinPolicy.builder()

    public Cluster getChannel() {
        return channel;

See my answer here: Questions about scylla java driver 4.x ShardAware feature and NAT issue - #2 by Lorak for a description of shard awareness and advanced shard awareness. Generally this error shouldn’t very be harmful. It affects only session creation, but after it is fully created (which may take a bit more time because of this problem) it will work exactly the same.
As to why it may occur - probably Docker on Windows uses some kind of NAT between Scylla and the driver. You may try to run the driver inside Docker too, but I can’t promise it will help. Maybe some Docker support channel would be a better fit for this question?

I’m not sure I get what you are aiming to do.
This code fragment:


will always call session.prepare which will send a PREPARE request. Which is a bad idea because now you have 2 round trips for each statement you perform - first to prepare unnecessarily and then to execute.

1 Like