Remove ShardedJedisPipeline class

[sazzad16]

ShardedJedisPipeline class should be removed. There are several fundamental flaws regarding the idea and implementation of this class.

• It captures the Client objects:
  • never to release those
  • never to clean those properly
  • never to flag those as broken when appropriate
• There is a getResults() method without any tests.
• That getResults() method is based on a private class FutureResult. There is a List<FutureResult> results in ShardedJedisPipeline. Remember that it is a sub-class of Queable which contains Queue<Response<?>> pipelinedResponses. These two data structures are contradictory and breaks each other.

[sazzad16]

An example is #2479. One of the possible resolution could be flagging the Clients as broken. When I tried to work on it, figured out it as deep hole to fill.

[sazzad16]

@gkorland @dengliming @mina-asham @yangbodong22011

PING!

[sazzad16]

Another example: #1783, a PR trying to solve an issue related to concerned class.

[gkorland]

@sazzad16 don't you think we need to provide an alternative for this API?

[sazzad16]

@gkorland No.

[yangbodong22011]

An example is #2479. One of the possible resolution could be flagging the Clients as broken. When I tried to work on it, figured out it as deep hole to fill.

@sazzad16 I read the code of ShardedJedisPipeline.java to confirm the reason for java.lang.ClassCastException at #2479 . Is it due to a messy response? (may be a timeout or a legacy from the previous request).

any way, as you said, the current code has bugs, but if we support to clean clients and results (If it times out or the link is broken, set broken is the responsibility of BinaryShardedJedis).

besides, if we just move this class, we completely ignore users who already use this class? （Perhaps they will new Pipeline every time they request, so that even if a single pipeline times out, it will not affect the next request.）

[sazzad16]

@yangbodong22011 You are welcome to give a try in this.

I have put my fair share of time in this. I have found that resolving one issue is leading to other (hidden) issues. It is only after putting some time and giving some thoughts, I've decided that it doesn't worth it and we'd be better off removing it.

if we just move this class, we completely ignore users who already use this class?

Firstly, I understand, this is tough. In almost all the cases, I'm against such scenarios. But at times we'd have to make harsh decisions in order to improve and go forward. To me, this is one of such rare case.

Secondly, are we really sure whether even a good number of users are using this feature? (Even if so, 3.x is readily available.)

[YNedderhoff]

For what it's worth, we rely on this heavily in our business. I don't know if it changes anything at this point, but I wanted to mention it as you asked in your last comment.