Two bugs; one commit #32
Conversation
common/main/java/com/couchbase/lite/FullTextIndexConfiguration.java
Outdated
Show resolved
Hide resolved
|
Please note: A complete fix for the root problem would, as noted in the related CBSE, require a timeout on silent connections. Since that scenario is quite unlikely, and introducing a timer into sensitive code is a significant change, I am not going to do it. The fix simply addresses the case in which the Core closes a connection that is not yet open. |
|
Also note that it is quite difficult to write a dev test to confirm that this fix works: I have not added one. I will have to set up a test network to try this out, probably using Jim's net-breaking proxy. Will confirm results as soon as I have them. It should be relatively easy for QE to test this scenario. I hope that they will add such a test. |
|
I think OKHTTP might already have connection timeout. |
| @@ -175,7 +184,10 @@ public void onMessage(@NonNull WebSocket webSocket, @NonNull ByteString bytes) { | |||
| public void onClosing(@NonNull WebSocket webSocket, int code, @NonNull String reason) { | |||
| Log.d(TAG, "%s#OkHTTP closing: %s", AbstractCBLWebSocket.this, reason); | |||
| synchronized (getPeerLock()) { | |||
| if (!state.setState(State.CLOSE_REQUESTED)) { return; } | |||
| if (!state.setState(State.CLOSE_REQUESTED)) { | |||
| if (state.assertState(State.CLOSED)) { webSocket.cancel(); } | |||
There was a problem hiding this comment.
I couldn't think about the case that the state is already CLOSED while OKHTTP is closing. However it doesn't hurt to put the logic here for precaution.
bmeike
force-pushed
the
fix/cbl-2389
branch
from
96858f1
to
00a4707
Compare
This is fixes for:
CBL-2389 | Confirm LiteCore request for close, before connection is opened.
CBL-2395 | Kotlin FullTextIndexConfiguration?.create extension function does not support multiple expressions