Redis Client SET NX return values

[TheBroach]

Hi,
I'm implementing a simple lock system in a PoC. When performing the .set() call with SetArgs().nx(), the response is null both if the lock was set successfully or if it already existed and therefore was not set. This differs from the Redis CLI behavior, where an OK is returned in the first scenario or null in the second.
My code needs to check whether the lock was set successfully or not, can this be done without making separate GET and SET calls?

[quarkus-bot[bot]]

/cc @cescoffier (redis), @gsmet (redis), @machi1990 (redis)

[machi1990]

Can you try the ValueCommands#msetnx() or its reactive equivalent command? This one returns a boolean indicating if the set was successfully or not.

[TheBroach]

Thanks for the quick reply machi!
Sorry, I forgot that part of the context: unfortunately I need to set an expire time on the lock as well. So that would result in two calls as well. In fact that was how I first did it, with a setnx() and then a setex(), but I came across scenarios where the second call failed, leading to locks living indefinitely. I also saw (unsure how much it matters for this) that Redis themselves has marked their SETNX CLI command as deprecated.

[machi1990]

Sorry, I forgot that part of the context: unfortunately I need to set an expire time on the lock as well. So that would result in two calls as well. In fact that was how I first did it, with a setnx() and then a setex(), but I came across scenarios where the second call failed, leading to locks living indefinitely.

Ah right. What about keeping what you have but replace set with ValueCommands#setGet(key,value,setArgs)?

[TheBroach]

Aha, I hadn't thought of that! Tried it now, sadly it doesn't seem to work. I have a minimal vanilla project where I test things out, there I wrote:

public Uni<Long> setGetStuff(Long id) {
        var deviceId = "321654987-987654321";
        var redisSetArgs = new SetArgs().nx().ex(Duration.ofSeconds(300L));
        logger.info("Sett-getting for id {}", id);
        return reactiveValueCommands.setGet(deviceId, id, redisSetArgs);
    }

@Test
    void test_setGetStuff() throws InterruptedException {
        var assertSubscriber1 = sut.setGetStuff(1L).subscribe().withSubscriber(UniAssertSubscriber.create());
        assertSubscriber1.awaitItem().assertItem(null);
    }

But getting:

2023-04-27 16:48:55,324 INFO  [io.quarkus] (Test worker) Installed features: [cdi, quartz, redis-client, resteasy-reactive, scheduler, smallrye-context-propagation, vertx]
2023-04-27 16:48:55,719 INFO  [org.acm.ClassA] (Test worker) Sett-getting for id 1

Expected an item event but got a failure: ERR syntax error
java.lang.AssertionError: Expected an item event but got a failure: ERR syntax error
	at io.smallrye.mutiny.helpers.test.UniAssertSubscriber.awaitItem(UniAssertSubscriber.java:165)
	at io.smallrye.mutiny.helpers.test.UniAssertSubscriber.awaitItem(UniAssertSubscriber.java:143)
	at org.acme.ClassATest.test_setGetStuff(ClassATest.java:34)
        ......

ClassATest > test_setGetStuff() FAILED

This is the same error message I get when testing directly with the Redis CLI, and using both of the flags NX and GET with the SET command (I'm guessing since SETGET is not a Redis CLI command, that this is a Quarkus implementation of a SET with the GET flag, which would explain the similar error message).

[machi1990]

This is the same error message I get when testing directly with the Redis CLI, and using both of the flags NX and GET with the SET command (I'm guessing since SETGET is not a Redis CLI command, that this is a Quarkus implementation of a SET with the GET flag, which would explain the similar error message).

What version of Redis are you using? Is it 7.x or a previous one? I suspect an old one. And if it is the case then, I am out of suggestions for possible workaround. Maybe @cescoffier might have some?

I see two ways here:

1. Open a feature request (an issue) to modify the returned value of the #set() , potentially returning true/false depending on whether the value was set or not. PRs are welcomed as well.
2. The first one involves what I had suggested earlier on regarding using #setnx(). And to work around this issue

In fact that was how I first did it, with a setnx() and then a setex(), but I came across scenarios where the second call failed, leading to locks living indefinitely.

You either perform a retry when the setex() fails or do everything within a transaction. But this still means calling two methods while one can be enough.

[cescoffier]

Which version of redis are you using? The GET flag has been added in 6.2 but combination with other arguments in 7 (and I'm not sure it's complete).

The reason why we have this method and not just an parameter is the java language: you cannot have the same signature return two different types.

[TheBroach]

You were correct, my redis-stack-container was running Redis 6.2.12. We are running Redis 7 in Elasticache for this, so should have checked! Updated to a redis-stack-container with Redis 7, and now the suggestion with setGet() mentioned above worked! Thank you both for you time and energy!

I might put in a feature request for returning true/false when using set() with nx though! :)

[JevanWu]

I found there's an execute method that can be leveraged to run not-provided commands. So, we can use execute to define the set command with nx and ex on our own. Here's the example:

    return reactiveDatasource.execute(
        "SET",
        cacheName,
        cacheValue,
        "NX",
        "EX",
        String.valueOf(expiration.toSeconds())
    ).map(Objects::nonNull);