Jedis usage results in: parsed unsupported command MULTI (& Lettuce fails with SELECT)

[mcouillard]

I've been using Dynomite successfully in other ways but have run into a roadblock trying to make it work with Jedis for Spring Data Caching (spring-data-redis 1.8.10). I'm using the same Jedis version as Dyno, 2.9.0, with Redis 3.2.11 and Dynomite 0.6.6 (also tried dev).

I'm not using java transactions and it all works fine when directly using the underlying Redis backend port. Jedis on the dynomite port, 8102, comes back with a JedisConnectionException and the Dynomite logs say just this: parsed unsupported command 'MULTI'

I've turned up log verbosity to 11 and copied a bit around the error below. Any help is appreciated!

...
[2018-04-05 16:35:12.989] mbuf_dump:156 mbuf 0x8c2260 with 4 bytes of data
00000000  3a 30 0d 0a                                        |:0..|
[2018-04-05 16:35:12.989] msg_dump:685 =================================================
[2018-04-05 16:35:12.992] msg_send_chain:1089 About to dump out the content of msg
[2018-04-05 16:35:12.992] msg_dump:680 msg dump id 65 request 1 len 33 type 27 done 0 error 0 (err 0)
[2018-04-05 16:35:12.992] mbuf_dump:156 mbuf 0x8ce2c0 with 33 bytes of data
00000000  2a 32 0d 0a 24 36 0d 0a  45 58 49 53 54 53 0d 0a   |*2..$6..EXISTS..|
00000010  24 31 30 0d 0a 31 35 6d  69 6e 7e 6c 6f 63 6b 0d   |$10..15min~lock.|
00000020  0a                                                 |.|
[2018-04-05 16:35:12.992] msg_dump:685 =================================================
[2018-04-05 16:35:12.992] msg_send_chain:1089 About to dump out the content of msg
[2018-04-05 16:35:12.992] msg_dump:680 msg dump id 66 request 0 len 4 type 135 done 0 error 0 (err 0)
[2018-04-05 16:35:12.992] mbuf_dump:156 mbuf 0x8c2260 with 4 bytes of data
00000000  3a 30 0d 0a                                        |:0..|
[2018-04-05 16:35:12.992] msg_dump:685 =================================================

[2018-04-05 16:35:13.029] redis_parse_req:1273 parsed unsupported command 'MULTI'

[2018-04-05 16:35:13.029] client_unref_internal_try_put:94 <CONN_CLIENT 0x8ab4c0 -1 from '1.18.18.140:63310'> unref owner <POOL 0x89b0f0 'dyn_o_mite'>
[2018-04-05 16:35:13.104] client_unref_internal_try_put:94 <CONN_CLIENT 0x8ab4c0 -1 from '1.18.18.140:63311'> unref owner <POOL 0x89b0f0 'dyn_o_mite'>
[2018-04-05 16:35:13.345] msg_send_chain:1089 About to dump out the content of msg
[2018-04-05 16:35:13.345] msg_dump:680 msg dump id 69 request 1 len 14 type 87 done 0 error 0 (err 0)
[2018-04-05 16:35:13.345] mbuf_dump:156 mbuf 0x8ce2c0 with 14 bytes of data
00000000  2a 31 0d 0a 24 34 0d 0a  50 49 4e 47 0d 0a         |*1..$4..PING..|
[2018-04-05 16:35:13.345] msg_dump:685 =================================================
[2018-04-05 16:35:13.345] msg_send_chain:1089 About to dump out the content of msg
[2018-04-05 16:35:13.345] msg_dump:680 msg dump id 70 request 0 len 7 type 134 done 0 error 0 (err 0)
[2018-04-05 16:35:13.345] mbuf_dump:156 mbuf 0x8c2260 with 7 bytes of data
00000000  2b 50 4f 4e 47 0d 0a                               |+PONG..|
[2018-04-05 16:35:13.345] msg_dump:685 =================================================
...

[mcouillard]

I've also tried spring-data-redis 1.7.11 and 1.6.6 in case newer versions of that were doing something odd with transactions. No luck.

Also, the only way I'm using Jedis is for simple gets and puts of single keys against a single backend (no sentinel/cluster stuff involved, just a basic redis+dynomite - with 2 replicated peers, no sharding - setup).

Lastly, I just tried lettuce 3.5.0 (last to support java 7) along with spring-data-redis 1.7.11 (the supported version) and it fails even faster: redis_parse_req:1273 parsed unsupported command 'SELECT'. I guess lettuce does a SELECT even when no database is defined, because I'm using the default of 0 per Dynomite requirements. I tried both setting the database to 0 and skipping a call to setDatabase().

[shailesh33]

Dynomite does not support Multi/exec commands. It also doesnt support multiple DBs apparently, that is why SELECT is also failing for you.

Is there a way you can avoid those commands?

On Fri, Apr 6, 2018 at 7:20 AM, Michael [email protected] wrote:

I've also tried spring-data-redis 1.7.11 and 1.6.6 in case newer versions of that were doing something odd with transactions. No luck.

Also, the only way I'm using Jedis is for simple gets and puts of single keys against a single backend (no sentinel/cluster stuff involved, just a basic redis+dynomite - with 2 replicated peers, no sharding - setup).

Lastly, I just tried lettuce 3.5.0 (last to support java 7) along with spring-data-redis 1.7.11 (the supported version) and it fails even faster: redis_parse_req:1273 parsed unsupported command 'SELECT'. I guess lettuce does a SELECT even when no database is defined, because I'm using the default of 0 per Dynomite requirements. I tried both setting the database to 0 and skipping a call to setDatabase().

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Netflix/dynomite/issues/551#issuecomment-379268085, or mute the thread https://github.com/notifications/unsubscribe-auth/ALle58cXttGH28HqpscJ6XHI7tnUypWPks5tl3mvgaJpZM4TJKOg .

[mcouillard]

Yeah, it matches the list of commands Dynomite doesn't support. I was just hoping I was somehow using Jedis wrong because it's what Dyno is based on and that apparently works fine for other Java scenarios.

I'll also try the Jedis community to see why MULTI is being used at all; seems unnecessary. Same with Lettuce and SELECT.

Though perhaps it's a good idea for Dynomite to simply ignore SELECT requests and maybe leave a log about it, and just carry on with the default 0 database. That'd at least make it more compatible with some clients like Lettuce - a top 3 Java client.

[mcouillard]

I'd like to revise this post to be focused on 1 end goal: to ignore SELECT requests. This will increase the availability of using Dynomite with systems that - either on purpose or mistake - issue a SELECT.

The specific scenario for me is a common one: Java Spring Framework (or Boot) + Lettuce (top 3 client; the default in Boot 2) + Spring Data Redis (1.7 or 1.8). It issues a SELECT when getting a connection even when the database is 0; aka unchanged.

It would be huge for Dynomite to simply ignore SELECT and carry on like the user intended to use the default 0 database.

[ipapapa]

There are two related questions in the past: https://github.com/Netflix/dynomite/issues/324 https://github.com/Netflix/dynomite/issues/520

[ipapapa]

In regards to your request to ignore a SELECT request, we might end up with the issue that somebody uses and expects an action but we swallow it. On the other hand, I see your point that Dynomite will then be able to be used under Spring Framework. Wouldn't it be more correct if the Spring Data Redis does not use that command at all?

[shailesh33]

I think spring is out of control for most developers. And May be spring just do "select 0" in which case we can swallow but not otherwise.

On Tue, Apr 24, 2018 at 1:21 PM, Ioannis Papapanagiotou < [email protected]> wrote:

In regards to your request to ignore a SELECT request, we might end up with the issue that somebody uses and expects an action but we swallow it. On the other hand, I see your point that Dynomite will then be able to be used under Spring Framework. Wouldn't it be more correct if the Spring Data Redis does not use that command at all?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Netflix/dynomite/issues/551#issuecomment-384066630, or mute the thread https://github.com/notifications/unsubscribe-auth/ALle5_ppqaBXVAbsiYwMqHvWyv_wVG4qks5tr4kugaJpZM4TJKOg .

[mcouillard]

It would, but it's true that corrections to Spring Data are harder to achieve. Plus any fix is unlikely to be backported earlier than Spring Data 1.8 because 2.0 was released.

I think a nice compromise to ignore it when SELECT 0 is issued would help.

[mcouillard]

While I still would love to see Dynomite ignore SELECT 0, I want to give an update on my own usage:

Raw Jedis + Java works fine. It just requires more manual effort because it keeps away from Spring Data / Framework / Cache helpers. Jedis itself is also a bit raw and basic on it's own, at least compared to Lettuce and Redisson. But for my basic use-case of data caching in a multi-node cluster of Java servers where P2P, async replication is just fine, Dynomite seems to be fitting the bill.

[ipapapa]

Fantastic, thanks for letting us know! Are you using Dynomite in production?

[mcouillard]

We'll be starting our slow rollout of it this week - I'm very excited!