Details
-
Improvement
-
Resolution: Fixed
-
Major
-
3.1.6
-
Security Level: Public
-
None
-
JAK 130
-
2
Description
While looking into CBL-5642, I have found the followings.
In Java / Android 3.1, Java will ignore the close request from LiteCore while waiting for the server to respond after connecting. This would mean that the close timeout in LiteCore will happen in this specific case and increase a chance of the issue described in #1 above to happen. Here is the code that ignores the OPENING state. I have noticed that we have fixed this in 3.2 branch per this code.
Java could also prevent the call to report gotHTTPResponse if the close request was called. If not entirely sure but changing the state to CLOSING inside AbstractCBLWebSocket's coreRequestsClose(status) could just simply prevent that as the state will not be able to change to OPEN if the current state is CLOSING in the remoteOpened(code, headers) code.
Another thing that I'm not quite sure how this currently works, is there a chance that C4Socket is used after it releases its peer? For example, core requests the socket to close at the same time that the AbstractCBLWebSocket is about to report gotHTTPResponse (in remoteOpened() via ackOpenToCore) back to core. AbstractCBLWebSocket closes the socket and lets C4Socket release its peer. As a result the reset C4Socket is used to report gotHTTPResponse.