Closed yuseok-kim-edushare closed 3 days ago
Can you perform the following steps?
--logger-level Trace
01::48::45 dbug: GarnetServer[0] Accepted TCP connection from 127.0.0.1:51061 01::48::45 dbug: Session[0] [127.0.0.1:51061] [03FB24F0] Starting RespServerSession Id=1 01::48::45 trce: Session[0] [127.0.0.1:51061] [03FB24F0] RECV: [2|$5|HELLO|$1|3|] RECV: [2|$5|HELLO|$1|3|] 01::48::45 SEND: [%8|$6|server|$5|redis|$7|version|$5|7.2.5|$14|garnet_version|$6|1.0.39|$5|proto|$1|3|$2|id|$2|63|$4|mode|$10|standalone|$4|role|$6|master|$7|modules|0|] trce: Session[0] [127.0.0.1:51061] [03FB24F0] SEND: [%8|$6|server|$5|redis|$7|version|$5|7.2.5|$14|garnet_version|$6|1.0.39|$5|proto|$1|3|$2|id|$2|63|$4|mode|$10|standalone|$4|role|$6|master|$7|modules|0|] 01::48::50 dbug: Session[0] [127.0.0.1:51061] [03FB24F0] Disposing RespServerSession Id=1
@badrishc I add on Garnet Server Log
and if you need, you can see Spring Data's Log
Just Look to me, Garnet's Log is clear to resolve doubt to garnet.
Very works well with when client mode in RESP v2
01::59::34 dbug: GarnetServer[0] Accepted TCP connection from 127.0.0.1:59418 01::59::34 RECV: [1|$4|PING|] SEND: [+PONG|] dbug: Session[0] [127.0.0.1:59418] [00A45263] Starting RespServerSession Id=3 01::59::34 trce: Session[0] [127.0.0.1:59418] [00A45263] RECV: [1|$4|PING|] 01::59::34 trce: Session[0] [127.0.0.1:59418] [00A45263] SEND: [+PONG|] 01::59::34 RECV: [2|$9|SUBSCRIBE|$24|settlement-first-created|] trce: Session[0] [127.0.0.1:59418] [00A45263] RECV: [2|$9|SUBSCRIBE|$24|settlement-first-created|] 01::59::34 SEND: [3|$9|subscribe|$24|settlement-first-created|:1|] trce: Session[0] [127.0.0.1:59418] [00A45263] SEND: [3|$9|subscribe|$24|settlement-first-created|:1|] 01::59::34 RECV: [1|$4|INFO|] trce: Session[0] [127.0.0.1:59412] [003942B8] RECV: [1|$4|INFO|]
I found that Lattuce (Java Client for Redis) has problem.
https://github.com/Prompt-oven/auth-service/issues/16#issuecomment-2490101447
I don't see any issues on server side Garnet logs for both resp2 and resp3. Lmk if you see anything amiss
I don't see any issues on server side Garnet logs for both resp2 and resp3. Lmk if you see anything amiss
Yes, You right. Garnet Is Clear,
I will find anwer from Spring and if some garnet need add docs for Java Spring Developer(like me) Maybe I will open PR to update Docs
Thank you for your kindness Answer and support @badrishc
The issue is created by the id
field in the HELLO
response. Redis represents the id
(connection id) as number. Once that's fixed, a number of Redis clients will be able to connect the server.
Then Fix Hello's Type
after new err occur on... Umm I will find some more what is problem
05::48::43 trce: Session[0] [127.0.0.1:63882] [023C0C5D] RECV: [4|$6|CLIENT|$7|SETINFO|$8|lib-name|$7|Lettuce|4|$6|CLIENT|$7|SETINFO|$7|lib-ver|$21|6.3.2.RELEASE/8941aea|] 05::48::43 trce: Session[0] [127.0.0.1:63882] [023C0C5D] SEND: [-ERR unknown command|-ERR unknown command|] 05::48::43 dbug: Session[0] [127.0.0.1:63882] [023C0C5D] Disposing RespServerSession Id=1
Lettuce 6.4 (or 6.5.) switches to fire-and-forget mode for these commands (IIRC).
@mp911de Still problem agian I think in Present garent didn't support Client_SETINFO command Ref thus, need to make Client_SETINFO could be possible in Garnet to be more compatible with other RESP3 based Redis Clients
Ah, this way works Dispite Client Setinfo didn't works,
Describe the bug
When I use Garnet to replace Redis My app written in Java with Spring Boot 3.3 and Spring Data Redis
I tried to test on container side and Redis CLI works well in PING command also Application's Execution of Ping works well
but Spring Application Try to connect Garnet, Fail to connect
and I checked logs, and finally found, when using Hello, fault on
Steps to reproduce the bug
Expected behavior
working well
Screenshots
no prepared
Release version
v1.0.36
IDE
No response
OS version
Ubuntu 24.04 LTS Host running on docker compose (garnet latest, eclipse-temurin:21-jre
Additional context
we operate garnet with out username and password, cause in docker network will ensure prevent to connect from external's
failed codes
successed code