New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

java.lang.ClassCastException: [B cannot be cast to java.lang.Long after calling Transaction.sync() #1688

Closed
offbynull opened this Issue Dec 3, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@offbynull

offbynull commented Dec 3, 2017

Expected behavior

I'm expecting the Jedis client not to throwan exception. I'm calling sync() so I can read from the Response<> objects from the Transaction operations.

Actual behavior

java.lang.ClassCastException: [B cannot be cast to java.lang.Long

Steps to reproduce:

    public static void main(String[] args) throws Throwable {
        JedisPool jp = new JedisPool("192.168.56.101", 6379);
        try (Jedis j = jp.getResource()) {
            j.flushDB();
        }

        while (true) {
            try (Jedis ij = jp.getResource()) {
                ij.get("test1");
                ij.get("test1");
                ij.get("test1");
                ij.watch("test1");
                ij.watch("test2");
                ij.watch("test3");
                ij.watch("test4");
                ij.get("test1");
                ij.get("test1");
                ij.get("test1");
                Transaction t = ij.multi();
                t.zadd("timestampqueue:0".getBytes(UTF_8), 1.0, "test".getBytes(UTF_8));
                t.zadd("timestampqueue:0".getBytes(UTF_8), 2.0, "test1".getBytes(UTF_8));
                t.zadd("timestampqueue:0".getBytes(UTF_8), 3.0, "test2".getBytes(UTF_8));
                t.exec();
                ij.sync();

                ij.zadd("timestampqueue:0".getBytes(UTF_8), 4.0, "test2".getBytes(UTF_8));
                ij.zadd("timestampqueue:0".getBytes(UTF_8), 5.0, "test2".getBytes(UTF_8));
                ij.zadd("timestampqueue:0".getBytes(UTF_8), 6.0, "test1".getBytes(UTF_8));
                ij.zadd("timestampqueue:0".getBytes(UTF_8), 7.0, "test1".getBytes(UTF_8));
                ij.zadd("timestampqueue:0".getBytes(UTF_8), 8.0, "test".getBytes(UTF_8));
                ij.zadd("timestampqueue:0".getBytes(UTF_8), 9.0, "test".getBytes(UTF_8));
                ij.zadd("timestampqueue:0".getBytes(UTF_8), 10.0, "test".getBytes(UTF_8));
                ij.zadd("timestampqueue:0".getBytes(UTF_8), 11.0, "test".getBytes(UTF_8));
                ij.zadd("timestampqueue:0".getBytes(UTF_8), 12.0, "test".getBytes(UTF_8));
            }
        }
    }

Should result in...

Exception in thread "main" java.lang.ClassCastException: [B cannot be cast to java.lang.Long
	at redis.clients.jedis.Connection.getIntegerReply(Connection.java:265)
	at redis.clients.jedis.BinaryJedis.zadd(BinaryJedis.java:1558)
	at com.offbynull.test2.jedis.JedisTest.main(JedisTest.java:44)

Redis / Jedis Configuration

Jedis version: 2.9.0

Redis version: 3.0.6 (standard mint Redis install gotten via apt-get install redis-server)

Java version: Java 8

@offbynull

This comment has been minimized.

Show comment
Hide comment
@offbynull

offbynull Dec 3, 2017

I've tried to work around the problem by not using .sync() -- I take the result of the .exec() directly, but even that doesn't work sometimes. For example, I have a GET and a EXISTS in a transaction, but the List that .exec returns is empty.

I found the issue for this here: #1592 and tried to work around it.

It starting to seem like, in addition to being poorly document, this library isn't reliable enough for production use :(

offbynull commented Dec 3, 2017

I've tried to work around the problem by not using .sync() -- I take the result of the .exec() directly, but even that doesn't work sometimes. For example, I have a GET and a EXISTS in a transaction, but the List that .exec returns is empty.

I found the issue for this here: #1592 and tried to work around it.

It starting to seem like, in addition to being poorly document, this library isn't reliable enough for production use :(

@sazzad16

This comment has been minimized.

Show comment
Hide comment
@sazzad16

sazzad16 Jan 6, 2018

Collaborator

It's because you're calling SYNC. Removing ij.sync(); solves the issue.

Collaborator

sazzad16 commented Jan 6, 2018

It's because you're calling SYNC. Removing ij.sync(); solves the issue.

@sazzad16 sazzad16 closed this Jan 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment