query promise chaining #345
Conversation
(2) additional handling of future cancellation
…ot at JasyncClientConnection
There was a problem hiding this comment.
generally lgtm.
Initially I thought to do that only for cancellation, but the proposed cl is doing it for all queries.
This looks like a more gracefull way to go, and the commit is cleaner. On the other hand in some edge cases this might hide issues because now it allows trying to send queries in parallel (it will just chain them).
Since it doesn't break any test I think we can go with that. the info log message might assist in case someone see something unexpected and I hope this is enough.
| ): CompletableFuture<QueryResult> { | ||
| return try { | ||
| if (isQuerying()) { | ||
| queryPromise().get().flatMap { func(param) } |
There was a problem hiding this comment.
can you please add a info log here, that we are doing a chaining?
There was a problem hiding this comment.
Thank you for your review and inspiring comments. I've tested this fix and it has some side effects as you said.
I think #347 is a better option.
Like you said, I also think that this fix is prone to side effects. Since what I expected was that once the first query is cancelled, the For that reason, I've implemented and tested your another suggestion, which is close connection on query conflict. |
As @oshai suggested at #343 (comment), I implemented query chaining. This can solve the problem mentioned in #343 (comment) without introducing scheduler and query execution queue.