fix #1910 protect initPool from being called in parallel

[gkorland]

No description provided.

[sazzad16]

@gkorland

1. Did you run your patch against the Reproducer provided in Race condition in JedisSentinelPool.initPool() causes JedisConnectionException on getResource() #1910?
2. Does your test without the patch reproduce Race condition in JedisSentinelPool.initPool() causes JedisConnectionException on getResource() #1910's issue?

[mp911de]

I think there are two issues:

1. Order of invocation
2. Synchronization/visibility issues

• initPool(…) in JedisSentinelPool should be called before starting any threads
• The pool should not be set by any thread but only-re-initialized to avoid visibility issues.

[gkorland]

• Did you run your patch against the Reproducer provided in Race condition in JedisSentinelPool.initPool() causes JedisConnectionException on getResource() #1910?
  @sazzad16 yes, and I even added similar test

• Does your test without the patch reproduce Race condition in JedisSentinelPool.initPool() causes JedisConnectionException on getResource() #1910's issue?
  Yes

[sazzad16]

LGTM!

[gkorland]

@mp911de

1. Order of invocation
   You are right, I guess a cleaner solution should be released later on, I think we should release a quick fix for 3.0.1 and then work on a cleaner solution for 3.1.0

2. Synchronization/visibility issues
   See commit ed2ed51

[sazzad16]

@gkorland Isn't before and after of ed2ed51 equivalent?

[gkorland]

@sazzad16 no, the former used this as the object to lock on which means it "exposed" the lock object while the later is using a private internal object

[gkorland]

@marcosnils @sazzad16 it seems like this bug is too critical and a fix should be released as soon as possible

[sazzad16]

@gkorland okay. go ahead