The getSessionToken() call that binds 8181 and waits for a response from the browser does so without timeout. It also does so on a different thread than the call to open the connection it is authenticating. We have a watchdog running on the connection thread (i.e. the caller of DataSource.getConnection()) that will eventually interrupt it after a timeout to avoid having hung/non-responsive connection attempts. When this occurs, the driver code does not seem to signal the auth thread to die and the auth thread runs on a future.get() with no timeout. Once in this state, we have no real way to recover interactive auth functionality without an app restart since the thread blocked on future.get() is effectively holding open 8181 until it finishes (and calls server.stop()).
This is especially bad for a user who has attempted to use OCI_INTERACTIVE and either doesn't notice the browser launch or (worse) closes the tab before logging in perhaps having been surprised by a browser launch in the middle of their IDE session.
This is an issue regardless of whether there are multiple threads contending on getSessionToken(). i.e. simply mutex'ing getSessionToken will not solve the problem and in fact could make it worse because future threads will pile up forever on the mutex lock (unless it has a timeout, which I believe it should).
Adding a timeout on the future.get() call in InteractiveAuthentication.awaitLogin appears to solve the issue as long as we ensure that future.cancel is called subsequently, which will trigger the whenComplete call back on it and close the server on 8181.
The getSessionToken() call that binds 8181 and waits for a response from the browser does so without timeout. It also does so on a different thread than the call to open the connection it is authenticating. We have a watchdog running on the connection thread (i.e. the caller of DataSource.getConnection()) that will eventually interrupt it after a timeout to avoid having hung/non-responsive connection attempts. When this occurs, the driver code does not seem to signal the auth thread to die and the auth thread runs on a future.get() with no timeout. Once in this state, we have no real way to recover interactive auth functionality without an app restart since the thread blocked on future.get() is effectively holding open 8181 until it finishes (and calls server.stop()).
This is especially bad for a user who has attempted to use OCI_INTERACTIVE and either doesn't notice the browser launch or (worse) closes the tab before logging in perhaps having been surprised by a browser launch in the middle of their IDE session.
This is an issue regardless of whether there are multiple threads contending on getSessionToken(). i.e. simply mutex'ing getSessionToken will not solve the problem and in fact could make it worse because future threads will pile up forever on the mutex lock (unless it has a timeout, which I believe it should).
Adding a timeout on the future.get() call in InteractiveAuthentication.awaitLogin appears to solve the issue as long as we ensure that future.cancel is called subsequently, which will trigger the whenComplete call back on it and close the server on 8181.