Jedis concurrency on one connection, possible?

[mmm]

Jedis vs Redisson in terms of performance, required number of connections. 

Seems jedis is not ideal here, is this true? How come? 

[Matt Freake]

I'm not exactly what you're asking here. If you require more than one Jedis connection, wouldn't you just create more using JedisPool, for example?

Matt

[mmm]

I am just saying, over one and only one connection, is concurrency technically possible towards redis ( i know jedis can't handle it) but are there any technical reasons? when a request is sent on a connection, jedis will treat all incoming data as part of that last request, so it is not able to differentiate between data belonging to a request from another. But would it be possible to track request with response data? 

I am asking, because I am trying to figure out if redisson is able to do just this, or not, if it truly has an edge. I am not sure why jedis choose to treat inputstream globally per connection, but I imagine there are good reasons, but unsure. If multiple requests over one connection is possible i don't see why the choice was made to max 1 per connection. 

I can create multiple connections, yes, but limiting a connection to a request might not be ideal. Not sure. 

[Sagar Sitap]

Redis processes all the requests synchronously. 

Not sure what do you mean by track request response.

If I get your question right, I think for every request you make you get response and that synchronised. So you know the returned response is for the request you have made.

--
You received this message because you are subscribed to the Google Groups "Jedis" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jedis_redis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jedis_redis/2700b983-773a-4a0c-a62e-6146c53d74e7n%40googlegroups.com.

[Marcos Lilljedahl]

Redis is a single thread synchronous system and can only handle one command at the time. That's why Jedis uses the same approach. Redisson and lettuce use a different approach which is async io from the client side.

Redis itself doesn't allow multiple commands to be processed concurrently through the same connection because redis it not a concurrent system

--

[mmm]

First for those that are not clear on what I mean. 

If you have one connection, in theory you could send a request to a server, and send with the header an id, and when the server replies with data, it will include the same kind of header id in the response, allowing the client to identify and connection the response data to the relevant request it is related to. That means in theory it would be possible to send multiple concurrent requests to the server, and be able to handle various response data concurrently. 

For instance, if you use the same jedis connection currently from several threads we know Jedis will fail completely in handling the reponse because it does not connect request out and response data in, but likely intermingles them. 

"Redis is a single thread synchronous system and can only handle one command at the time. That's why Jedis uses the same approach."

"Redisson and lettuce use a different approach which is async io from the client side."

This is what I am to get down to. Those two statements seems contradictory. If Redis is incapable and that is the reason Jedis communicates this way, then how / are / if redisson / lettuce able to circumvent this limitation? 

They use a different approach how? I am not sure async is really happening on the client side for redisson. I mean the sync part of Jedis could easily be wrapped up in a future and be made "async". While in reality it would mean requests are queued. 

If in truth Redisson is capable of firing off multiple requests on one connection, how are they doing it, and is that potentially much better for throughput than creating multiple connections, by instead creating multiple requests per connection, which ought to be cheaper. 

[Matt Freake]

So I'm not a Redisson expert (oh Jedis for that matter :-) but my understanding is as follows. Redis is fundamentally single-threaded, with a few special cases. Almost all of the time your Redis commands will run and return sequentially. Jedis takes a fairly low level approach, exposing the queries and connections to the developer and if you run a Redis command it blocks until it completes.

Redisson takes a higher level approach, abstracting away the connections and even sometimes the actual commands being run. Because of this, it can offer asynchronous and reactive apis, so your Java/Kotlin code can instigate the Redis command and proceed without having to wait for it to return. This is useful if your code can usefully do other stuff in the meantime, without blocking, while the Redis command executes. What it doesn't do though, is allow Redis to run multiple commands on the server at once? So it all depends on what you mean by concurrency

Happy to be corrected on any of this.

Matt

To view this discussion on the web visit https://groups.google.com/d/msgid/jedis_redis/81000bcb-1a1d-4d31-9d8a-23108e1ff6a4n%40googlegroups.com.

[mmm]

I think some are confused by what reactive async is. It is sync commands, wrapped in a future making them 'async'. There is no free lunch and there is nothing magic about it. You are just waiting to act on a command later.  It will return immediately, and act only when it completes nothing concurrent about it. 

Here is a sync Jedis command turned async: (pasting code in google "mailing list" is a nightmare)

https://i.imgur.com/fDRoO5c.png

It means nothing. Jedis can easily be made async by doing this. There is zero benefits. 

What I am asking is if the connections are able to send more than one request at a time, technically possible and if indeed Jedisson or Lettuce are doing something that Jedis is not. Async jedis can do. 

The problem is that Jedis is handling the response inputstream on a connection level rather than request level. But is that a general redis limitation that we can not get around anyway? 

Because if not, in theory Jedis should be able to perform just as well as Redisson and Lettuce since they can not go beyond a request response conurrently.