Allow to close the socket while connecting to the remote server
Description
While looking into , 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.
Activity
Show:
CB robot April 24, 2024 at 8:21 PM
Build couchbase-lite-android-3.1.7-3 contains couchbase-lite-java-common commit a5ab529 with commit message: : Allow socket to close while OPENING (#284)
CB robot April 24, 2024 at 8:20 PM
Build couchbase-lite-java-3.1.7-3 contains couchbase-lite-java-common commit a5ab529 with commit message: : Allow socket to close while OPENING (#284)
Blake Meike April 24, 2024 at 4:55 PM
With regard to point #3: all calls to the native peer of the C4Socket are protected by the `withPeer` method. That method will ignore and log any attempt to use the native peer after it has been released.
I think that should be ok.
Fixed
Pinned fields
Click on the next to a field label to start pinning.
While looking into , 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.