We should make sure that the long waiting thread get the lock. Otherwise, client’s later insertRow request with later offset token may come and get the lock first -- it will get the earlier internal continuation token and insert first. This could cause issues when incident happens and customer trying to replay the data. This may also cause the data ingested not in sequence.
We should make sure that the long waiting thread get the lock. Otherwise, client’s later insertRow request with later offset token may come and get the lock first -- it will get the earlier internal continuation token and insert first. This could cause issues when incident happens and customer trying to replay the data. This may also cause the data ingested not in sequence.
We should use the fair synch lock to make sure that the thread with the longest waiting time (come earlier) wins and get the lock. Doc for the ReentrantLock: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReentrantLock.html