I have noticed that there is a difference in the time it takes a call to the rxjava method CommandSubmissionService::Submit to complete – in library version 2.0.1 it appears to be completely non-blocking (returns almost immediately - I have tried timing it). In version 2.2.1 it takes much longer by comparison, something like 100-200ms in my tests. What is it actually doing under the hood here? I thought it should be non-blocking and we should subscribe to the returned Single to get the result?
1 Like
Hi Huw,
Could say a bit more about the platform configuration that you are using? Are you on canton, on vmbc, on hub? Which database and which domain integration are you using?
Hi @Marcin_Ziolek , I’m using vmbc. I don’t believe database or domain integration are applicable to vmbc. I was thinking this was more of a library implementation issue, rather than platform - do you think platform configuration could make a difference?
The fact that you are on vmbc actually already explains the perceived behavior. There has been a change recently to the concord request submission protocol. Previously it was fire and forget, now the ledger api server holds on to the request until after it has been confirmed to have been committed or rejected by the concord replicas. It simplifies the error handling for the ledger api clients at the expense of submission latency. Please note that the overall latency remains unchanged as the definitive answer about status of a transaction arrives in the completion stream that has the same characteristic as before.
Very interesting - is that change documented somewhere? Couldn’t find it in the VMBC release notes. That being said, if I stick to the newer VMBC version (1.7) and use the older java bindings (2.0.1), then I notice the call returns very quickly. To produce the increased in latency, all I need to do is bump the version of the java bindings to 2.2.1. That would have to be due to a change in library or am I missing something? Perhaps it is the same issue as this CommandClient.submitAndWait non-blocking results - #3 by stefanobaghino-da ?
1 Like
Hi Hew
As it turns out you were spot on with your observation. There was more to the story than I had known. Indeed there is a difference in the blocking behavior of the java bindings library.
The blocking behavior is what the original implementation was doing. A fix was attempted in Dec 2021 to change it to a non blocking:
Issue: [BUG] `Single` results in the Java bindings are blocking · Issue #12193 · digital-asset/daml · GitHub
Fix: Remove usages of `Flowable.fromFuture` and `Single.fromFuture` by stefanobaghino-da · Pull Request #12425 · digital-asset/daml · GitHub
This resulted in the version 2.0 returning fast to the caller. However, later on it was discovered that this fix was leading to a deadlock and the solution was reverted
Issue: Java bindings seem to be affected by a deadlock · Issue #13645 · digital-asset/daml · GitHub
Fix: https://github.com/digital-asset/daml/pull/13717
As of now we are back to square one in terms of the blocking behavior.
I see. That’s unfortunate the original bug fix caused the deadlock issue. In that case, I assume in the recent library version that the call to CommandSubmissionService::Submit will not return until the request-response cycle has completed.