Soft retries when awaiting runtime responses (#10272)

A quick and dirty workaround for slow processing in a similar spirit to PR #9858.
Long compilation of stdlib holds a write compilation lock, while opening the file needs to set module sources and requires read compilation lock and file lock. The expectation was that setting module sources is instantaneous except not, because of locks.

This PR adds soft retries.

Partially closes #10231. There are still problems related to https://github.com/enso-org/enso/issues/9993 once this PR is merged.

# Important Notes
We need to figure out a more fine-grained lock system or, ideally, make it lock free to avoid such hacks.
This commit is contained in:
Hubert Plociniczak 2024-06-14 11:05:48 +02:00 committed by GitHub
parent 904ffe1dd6
commit dc6e3a7031
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

View File

@ -152,12 +152,36 @@ class CollaborativeBuffer(
buffer: Buffer,
rpcSession: JsonSession,
replyTo: ActorRef,
timeout: Cancellable
timeout: Cancellable,
retries: Int
): Receive = {
case ServerConfirmationTimeout =>
logger.warn("Timeout reached when awaiting response from the server")
replyTo ! OpenFileResponse(Left(OperationTimeout))
stop(Map.empty)
if (retries > 0) {
logger.warn(
"Timeout reached when awaiting response from the server. Retries left {}",
retries
)
val timeoutCancellable = context.system.scheduler
.scheduleOnce(
timingsConfig.runtimeRequestTimeout,
self,
ServerConfirmationTimeout
)
context.become(
waitingOnServerConfirmation(
requestId,
buffer,
rpcSession,
replyTo,
timeoutCancellable,
retries - 1
)
)
} else {
logger.warn("Timeout reached when awaiting response from the server")
replyTo ! OpenFileResponse(Left(OperationTimeout))
stop(Map.empty)
}
case Api.Response(Some(id), Api.OpenFileResponse) if id == requestId =>
timeout.cancel()
val cap = CapabilityRegistration(CanEdit(bufferPath))
@ -865,7 +889,8 @@ class CollaborativeBuffer(
buffer,
rpcSession,
replyTo,
timeoutCancellable
timeoutCancellable,
5
)
)
}