Road to Jedis 3.0

[Marcos NiLs]

Today we had our first team meeting with the intentions to settle strong bases about the future of Jedis and we'd like to share with our community the items we came up with for our next major Jedis release. 

We talked about working in two aspects mainly:

Important features and things that must be improved:

1. Code improvements (making command implementation simpler. naming conventions, code duplication, etc)
2. Add support for Async API (needs to be as performant as current Jedis version) 
3. Add tests to jedis features (Sharded, Pipeline, JedisCluster, etc) to avoid silly bugs
4. Improve versioning and PRs handling so we can deliver faster and review easier
5. Work thoroughly in JedisCluster

Another important topic that was also debated what the necessity to stop supporting some features in pursuit of cleaner code and simplicity. For this objective we decided to investigate two possible solutions and take our decisions based on the results.

1 Stop supporting ShardedJedis from 3.0 onwards in behalf of focusing our efforts to JedisCluster. 

2 Replace Jedis Pipeline with an async core.

We wanted to share our conclusions with and hear your opinions. Take into account that Jedis is maintained by a very few people and it get's really difficult for us to move forward unless we take some actions to boost contributions and focus on core functionality and code simplicity. 

Of course thoughts and suggestions are always welcome. 

Marcos.

[sachin walia]

Hi Marcos,

it's nice to see the roadmap of the features. However few things which I think are absolutely needed at this point of time are:

- Website with tutorials and how-tos

- Javadoc for SVN latest as well as last stable release.

I think these two things most people will agree with.

I am ready to contribute for both of these areas if you want.

thanks,

Sachin Walia 

[Marcos Lilljedahl]

Sachin, 

I agree that documentation is as important as code. In my opinion we should focus in javadoc first as I believe it's the first source of documentation that any programmer checks when using a library. A website is a good idea as well but I believe that it infers more work and some planning about how do we want the site to be structured. 

We're always looking for people who want to contribute, so if you think you can write some documentation (javadoc or wiki articles) that would be useful for new comers and current Jedis users we will be glad to include it. 

Marcos.

--
You received this message because you are subscribed to a topic in the Google Groups "Jedis" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jedis_redis/7ZJPFp_qTY0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jedis_redis...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[임정택]

Hello all.

I was thinking about 1, Stop supporting ShardedJedis from 3.0 onwards in behalf of focusing our efforts to JedisCluster.

I spent some hours on removing ShardedJedis and how much is Jedis cleaner by change.

At first, many classes are related to ShardedJedis including utilities, so we can get rid of it.

And we can simplify Pipeline and relevant interfaces because there's no need to split operations which one is single key and other one is multi keys.

In addition, I've modified some interfaces name cause to have consistent naming convention. 

 

Details are on link,

https://github.com/HeartSaVioR/jedis/compare/HeartSaVioR:master...experimental-remove-shardedjedis

Please let me know if you have a question, or a opinion / suggestion, or anything else you want to talk about this discussion.

Thanks.

Regards.

Jungtaek Lim (HeartSaVioR)

2015년 1월 7일 수요일 오전 2시 5분 20초 UTC+9, Marcos NiLs 님의 말:

[David Weir]

I have created a version of the Async Jedis using the current 3.0.0 snapshot. (removing calls to client.getIntegerReply() and client.getStatusReply() where necessary) and placing a call to flush() in Protocol.sendCommand(final RedisOutputStream os, final byte[] command, final byte[]... args).

This works pretty well and has increased our throughput tremendously.

If you were thinking of using Java NIO instead of the current outputStream version, I'd be interested too.

This email is intended solely for the recipients named above and may contain information that is confidential, privileged or legally protected.  If you receive this communication in error, please immediately notify the sender by return e-mail and delete all copies of the original email and attachments.

[Jonathan Leibiusky]

Are you interested in sharing your version?
Also, can you tell us your benchmark results?

--
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.

[Marcos Lilljedahl]

Hi David, 

Heart has been doing some work in his side as well and he has submitted two PR's to bring both Async and NIO to Jedis. 

We haven't yet merged them into master as they need thoroughly reviewing and testing which we haven't had time to do so far. It'd be great if you could take a look and provide some feedback as it seems you've done an amazing work already. 

We'd like to heart your thoughts about it and to work together in the next version of Jedis. 

Here are the PR's I was taking about:

https://github.com/xetorthio/jedis/pull/647

https://github.com/xetorthio/jedis/pull/713

Thanks in advance, 

Marcos.

--
You received this message because you are subscribed to a topic in the Google Groups "Jedis" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jedis_redis/7ZJPFp_qTY0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jedis_redis...@googlegroups.com.

[임정택]

Hi.

That is cool!

Could you share your modified Jedis, and benchmark result? You can use current Benchmark, or make your own based on GetSetBenchmark.

Thanks in advance.

Regards.

Jungtaek Lim (HeartSaVioR)

2015년 1월 23일 금요일 오전 3시 11분 50초 UTC+9, David Weir 님의 말:

[David Weir]

I’ll have a look at those branches and give it a whirl, but I’m still fighting with thread safeness 

-- 

David Weir

[David Weir]

If i get time, I’ll send you benchmark results… probably won’t happen today.

-- 

David Weir

--

You received this message because you are subscribed to a topic in the Google Groups "Jedis" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jedis_redis/7ZJPFp_qTY0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jedis_redis...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[임정택]

About benchmark, maybe we forgot to think latency.

Pipeline has a great throughput by nature (all things are batched by controlling flush) but we cannot get any responses before sync() called.

So its latency could be high, maybe should high due to increasing throughput.

  

It could be better to change benchmarks to show total throughput (maybe ops, same to current) and average latency.

It could be also better to have 95, 99.9 percentile, too.

2015년 1월 7일 수요일 오전 2시 5분 20초 UTC+9, Marcos NiLs 님의 말:

Today we had our first team meeting with the intentions to settle strong bases about the future of Jedis and we'd like to share with our community the items we came up with for our next major Jedis release. 

[임정택]

I was also thinking about 2, replace Pipeline to Async API.

Recently I revised current benchmark with contiperf, which supplies warmup phase, test duration or invocation count, thread count (and so on), and shows summary.

You can refer https://github.com/HeartSaVioR/jedis-benchmark for details. (async feature is on benchmark-async-nio branch)

I don't change Jedis's original benchmark because adding dependency for just benchmark is something I wish to avoid.

I ran benchmark to compare Normal (NIO, OIO) vs Pipeline (NIO, OIO) vs Async (NIO only), and now I'm sharing the result.

Before seeing result, 

1. About sources I used are current master (as OIO), and upmerged support-async-nio (as NIO).

2. I ran benchmarks with my Macbook Pro (develop machine) so it would be not accurate enough. 

Please see attach file to continue. :)

1. OIO vs NIO

There seems to a small performance increasing on NIO compared to OIO.

But I'm curious it is noticeable. ;)

2. Normal, Pipeline, Async

You can see Async beats Normal completely, but Pipeline is still faster than Async.

But there's one thing we should have in mind.

With pipeline we don't get any responses before sync. 

It means that when pipeline queue size grows, we can get higher throughput, but also higher latency, but async is not.

tl;dr. Best throughput and high latency : Pipeline / Great throughput and low latency : Async / Low throughput and low latency : Normal

So, Pipeline will be meaningful whether Async will be introduced or not. And also Async is meaningful enough. 

Please show your comments or opinions about this.

Thanks for reading long note!

Regards.

Jungtaek Lim (HeartSaVioR)

2015

년 1월 7일 수요일 오전 2시 5분 20초 UTC+9, Marcos NiLs 님의 말:

Today we had our first team meeting with the intentions to settle strong bases about the future of Jedis and we'd like to share with our community the items we came up with for our next major Jedis release. 

[David Weir]

Hi Jungtaek Lim,

I tried to pull the benchmark-async-nio branch, but can’t find it.

I pulled your support-async-nio branch - is that the same thing?

I couldn’t get my async version of 3.0.0 working in a thread safe manner, so I’ve gone back to v 2.6.2.

I’m going to work with your version to see whether it still works thread safe and what I did wrong on my 3.0 version.

I’ll let you know how I get on.

David

-- 

David Weir

--
You received this message because you are subscribed to a topic in the Google Groups "Jedis" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jedis_redis/7ZJPFp_qTY0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jedis_redis...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Attachments:

[임정택]

Hi!

I made another repository https://github.com/HeartSaVioR/jedis-benchmark which has only benchmark codes.

You can find 'benchmark-async-nio' branch from this repos.

About thread-safeness in Async...

If it is based on non-blocking, single thread should be enough. 

(Actually I tried to separate read thread and write thread but it makes many troubles. One post which I've read also tells it.)

If you're trying to make Async based on blocking and multi-thread, input stream and output stream can be easily mixed with requests / responses.

https://github.com/xetorthio/jedis/pull/349 achieves Async with blocking manner, but we didn't test it, and it's restricted to Pipeline. I think it's not real Async.

I'm happy to work together into Async feature.

If you have opinions, research outputs, etc., please let me know.

Thanks!

Regards.

Jungtaek Lim (HeartSaVioR)

--

Name : 임 정택
Blog : http://www.heartsavior.net / http://dev.heartsavior.net
Twitter : http://twitter.com/heartsavior

LinkedIn : http://www.linkedin.com/in/heartsavior

[임정택]

Hi David.

Fresh news about Async feature.

Jonathan and I are agreed to try using Netty to replace current implementation, because of core NIO's complexity. 

We're not starting it yet. Jonathan will push new branch, say, async-netty-research.

You can follow up new branch after it'll be pushed.

Hope this helps.

Best.

Jungtaek Lim (HeartSaVioR)

2015년 1월 25일 일요일 오전 3시 35분 46초 UTC+9, David Weir 님의 말:

[David Weir]

That sounds like a good idea. 

Just looking at how to incorporate the nio-based AsyncJedis into JedisPool is extremely complicated

David

[임정택]

AsyncJedis doesn't need JedisPool since it is thread-safe.
You can test it with multi-threaded.

Jungtaek Lim (HeartSaVioR)

[임정택]

Today we had our second team meeting to share our investigation and discuss about removing ShardedJedis and Async feature.

Marcos wraps up our meeting as,

1) We will setup a new super small project using the latest version if netty that only makes *set* and *get* operations to redis. We'll benchmark it against Jedis (Pipeline also) and then if results are promising we'll discuss the best way to build the new Jedis version around that

2) We agreed that we're not supporting ShardedJedis as a core feature of Jedis 3.x. We will encourage the community to build it as a module/application around Jedis but we'll not maintain it officially. 

Regarding 1), we're all new to Netty, so contributors which have some experiences on Netty would be a great help to us.

We'll start from non-blocking IO, and find out we can make blocking IO with Netty, too.

Regarding 2), as I was posted, we can simplify Jedis codes by dropping ShardedJedis from Jedis 3.x.

https://github.com/xetorthio/jedis/pull/875 points out this, so you can take a look and comment.

In next meeting we would share knowledge, experience, experimental about Netty, and take a decision about using Netty / NIO.

We already have non-blocking async PR based on NIO, https://github.com/xetorthio/jedis/pull/713

Any opinions, thoughts, suggestions, and helps are always greatly appreciated!

Thanks!

Regards.

Jungtaek Lim (HeartSaVioR)

2015년 1월 7일 수요일 오전 2시 5분 20초 UTC+9, Marcos NiLs 님의 말:

[Nils Kilden-Pedersen]

On Tue, Feb 3, 2015 at 10:45 AM, 임정택 <kab...@gmail.com> wrote:

Today we had our second team meeting to share our investigation and discuss about removing ShardedJedis and Async feature.

Marcos wraps up our meeting as,

1) We will setup a new super small project using the latest version if netty that only makes *set* and *get* operations to redis. We'll benchmark it against Jedis (Pipeline also) and then if results are promising we'll discuss the best way to build the new Jedis version around that

2) We agreed that we're not supporting ShardedJedis as a core feature of Jedis 3.x. We will encourage the community to build it as a module/application around Jedis but we'll not maintain it officially. 

Regarding 1), we're all new to Netty, so contributors which have some experiences on Netty would be a great help to us.

We'll start from non-blocking IO, and find out we can make blocking IO with Netty, too.

Generally it's easy to go from non-blocking to blocking, you just block on the Future (or whatever equivalent). If the driver was implemented fully non-blocking, it would be trivial to add a blocking API in front, and have no dedicated blocking implementation. Might be premature at this point though :-)

 

Regarding 2), as I was posted, we can simplify Jedis codes by dropping ShardedJedis from Jedis 3.x.

https://github.com/xetorthio/jedis/pull/875 points out this, so you can take a look and comment.

In next meeting we would share knowledge, experience, experimental about Netty, and take a decision about using Netty / NIO.

We already have non-blocking async PR based on NIO, https://github.com/xetorthio/jedis/pull/713

Not sure what JRE version Jedis supports, but Java6 is EOL, and Java7 has AIO (NIO.2), which supposedly is a lot easier than old NIO.

 

Any opinions, thoughts, suggestions, and helps are always greatly appreciated!

Thanks!

Regards.

Jungtaek Lim (HeartSaVioR)

2015년 1월 7일 수요일 오전 2시 5분 20초 UTC+9, Marcos NiLs 님의 말:

Today we had our first team meeting with the intentions to settle strong bases about the future of Jedis and we'd like to share with our community the items we came up with for our next major Jedis release. 

We talked about working in two aspects mainly:

Important features and things that must be improved:

1. Code improvements (making command implementation simpler. naming conventions, code duplication, etc)
2. Add support for Async API (needs to be as performant as current Jedis version) 
3. Add tests to jedis features (Sharded, Pipeline, JedisCluster, etc) to avoid silly bugs
4. Improve versioning and PRs handling so we can deliver faster and review easier
5. Work thoroughly in JedisCluster

Another important topic that was also debated what the necessity to stop supporting some features in pursuit of cleaner code and simplicity. For this objective we decided to investigate two possible solutions and take our decisions based on the results.

1 Stop supporting ShardedJedis from 3.0 onwards in behalf of focusing our efforts to JedisCluster. 

2 Replace Jedis Pipeline with an async core.

We wanted to share our conclusions with and hear your opinions. Take into account that Jedis is maintained by a very few people and it get's really difficult for us to move forward unless we take some actions to boost contributions and focus on core functionality and code simplicity. 

Of course thoughts and suggestions are always welcome. 

Marcos.

--

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.

[임정택]

Current NIO version of Async feature provides only callback.
(Actually I'm wondering why Future is treated to async.)

If we will stick callback, we would have a hard time to making sync based on async, because callback is called from other thread.

Jedis have been played well with JDK6, but we can think about dropping support JDK6 from 3.x either.
We can play with JDK7+ features then!

Thanks Nils!

Best.
Jungtaek Lim (HeartSaVioR)

You received this message because you are subscribed to a topic in the Google Groups "Jedis" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jedis_redis/7ZJPFp_qTY0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jedis_redis...@googlegroups.com.

[Nils Kilden-Pedersen]

Glanced a bit at the code and noticed a few things:

• Method AsyncDispatcher.registerRequest is synchronized. Since it only calls LinkedBlockingDeque.add and Selector.wakeup that should be unnecessary, as both are safe to call concurrently, and I don’t believe those two method calls need to be atomic.
• Same class, method handleConnectionException, while loop does a peek then a poll, which is redundant, since poll returns null if empty. Probably not super important since it’s during an exceptional condition, but still…
• Java7 introduced ConcurrentLinkedDeque, which is a non-blocking deque implementation. This makes it better than LinkedBlockingDeque under load, but is supposedly slightly less performant in the non-contended case. I think for this scenario, ConcurrentLinkedDeque offers better scalability.

​

[임정택]

Thanks for reviewing and feedback!

I'll move your feedback to Github PR, and report as soon as I will try.

Maybe I can talk with other collaborators that if we can change base JDK version to 7 at 3.0.0, since we can take advantage of many points.

Thanks again!

2015년 2월 4일 수요일 오전 11시 30분 31초 UTC+9, Nils Kilden-Pedersen 님의 말:

[Nils Kilden-Pedersen]

On Tue, Feb 3, 2015 at 4:41 PM, 임정택 <kab...@gmail.com> wrote:

Current NIO version of Async feature provides only callback.
(Actually I'm wondering why Future is treated to async.)

If we will stick callback, we would have a hard time to making sync based on async, because callback is called from other thread.

The pattern for that is something like this (Scala/pseudo code):

def getSomething(key: Key): Value = {
  val q = new SomeBlockingQueue[Value](1) // Size of 1
  val callback = new AsyncCallback {
    def onResult(value: Value) {
      q.put(value) // Put result on queue
    }
  }
  asyncProcessor.call(key, callback) // Async call, returns immediately
  q.take() // Block thread until result is put on queue, then return value
}

[임정택]

Yes, it can be done.
Actually I'm considering that is it really better than OIO implementation by performance and code complexity side.

[임정택]

For studying Netty, I skimmed 'Netty In Action’ for several days, and tried to replace Async NIO feature to Netty.

(It’s my first output with Netty, so you can say it’s dirty. ;) )

Here’s a link for you to take a look.

https://github.com/HeartSaVioR/jedis/tree/wip-support-async-nio-with-netty

It's based on previous PR - Async NIO, so if you saw my previos PR, only last commit is what you want to see.

One downside is I can’t fully control threads (especially EventLoop from Netty), so I’m having difficulty with thread-safeness, and reconnection.

So for now I'm giving up automatic reconnect.

(Maybe I need to arrange state of Channel...)

Hope for Netty users to review my code.

Any suggestions are more appreciated!

Best Regards.

Jungtaek Lim (HeartSaVioR)

2015년 2월 4일 수요일 오전 1시 45분 56초 UTC+9, 임정택 님의 말: