# CommandClient.submitAndWait non-blocking results **URL:** \ **Category:** App Development\ **Tags:** java, features and bugs\ **Created:** [December 17, 2021, 3:42pm UTC](https://forum.canton.network/t/commandclient-submitandwait-non-blocking-results/3598 "2021-12-17T15:42:55Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![alekseilarionovepam](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/alekseilarionovepam/32/2857_2.png) [@alekseilarionovepam](https://forum.canton.network/u/alekseilarionovepam)\ **Post date:** [December 17, 2021, 3:42pm UTC](https://forum.canton.network/t/commandclient-submitandwait-non-blocking-results/3598/1 "2021-12-17T15:42:56Z")
Hello. We are still working on application which should react to ledger changes and updated ledger depending on current ledger state and application settings. We got rid of all blocking calls since previous question - [DamlLedgerClient deadlock](https://discuss.daml.com/t/damlledgerclient-deadlock/3508) But now when we tried to subscribe to results of **CommandClient.submitAndWait** methods, we found out that resulting **Single** instances are blocking. So, when we try to use subscribe on that **Singles** we have current thread blocked and callback called synchronously. This happens because these Singles are created using **Single.fromFuture** method, which uses **FlowableFromFuture** class, which **subscribeActual** method has blocking implementation. We created simple tesing code to show this behavior here - [GitHub - digital-asset/ex-java-bindings: Three examples demonstrating three different approaches to using the Java ledger API bindings](https://github.com/digital-asset/ex-java-bindings) . You can see logs with stack traces there in PingPongReactiveMain class on lines 105 and 117. We are unable to find workarounds for this issue cause issue is introduced by Reactive Layer of Daml Java Bindings. What can you suggest us to do? BTW, you can see discussion of similar issue on Stackoverflow - [rx java2 - RxJava How to create a non blocking Single from CompletableFuture\ - Stack Overflow](https://stackoverflow.com/questions/59139204/rxjava-how-to-create-a-non-blocking-single-from-completablefuturelong) Regards, Alexey. ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [December 17, 2021, 4:15pm UTC](https://forum.canton.network/t/commandclient-submitandwait-non-blocking-results/3598/2 "2021-12-17T16:15:12Z")
Thanks for the feedback, Aleksei. This is very valuable and I’ll make sure to create a ticket to track this. If the blocking behavior is a deal breaker for you and you need a short term solution, you can use the gRPC generated code directly. It’s a bit unwieldy but it should allow you to move past this obstacle. We are starting to have discussions about how we want to evolve our Java bindings and we’ll certainly fix existing bugs, but we have pressing priorities that could make this particular item slip a bit. ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [December 17, 2021, 4:21pm UTC](https://forum.canton.network/t/commandclient-submitandwait-non-blocking-results/3598/3 "2021-12-17T16:21:59Z")
I’m wondering if another possible short term solution could be to wrap the `Single` coming back from the bindings into a separate implementation of `Single` that does the wrapping suggested in the StackOverflow answer you shared, calling the `toFuture` method of `Single` on the original one. It’s a bit convoluted but could serve the purpose. ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [December 17, 2021, 4:36pm UTC](https://forum.canton.network/t/commandclient-submitandwait-non-blocking-results/3598/4 "2021-12-17T16:36:40Z")
Tracked by [[BUG] `Single` results in the Java bindings are blocking · Issue #12193 · digital-asset/daml · GitHub](https://github.com/digital-asset/daml/issues/12193) For reference, this is the commit that @alekseilarionovepam originally referred to: [Added submitAndWait results blocking logging. · alekseilarionovepam/ex-java-bindings@7628dad · GitHub](https://github.com/alekseilarionovepam/ex-java-bindings/commit/7628dadd90eec4ea98fbffa8096e9345b359ac7d) ---
**Author:** ![alekseilarionovepam](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/alekseilarionovepam/32/2857_2.png) [@alekseilarionovepam](https://forum.canton.network/u/alekseilarionovepam)\ **Post date:** [December 20, 2021, 5:49pm UTC](https://forum.canton.network/t/commandclient-submitandwait-non-blocking-results/3598/5 "2021-12-20T17:49:10Z")
I created the workaround using Reflection. You can find it within this commit: [Added TemporaryFixes.fixSingleFromListenableFuture initial implementa… · alekseilarionovepam/ex-java-bindings@99c39a1 · GitHub](https://github.com/alekseilarionovepam/ex-java-bindings/commit/99c39a1a656f86f5a751ee6e430886abba4900f8) Hope it is temporary solution and you will use: ```haskell Single.create(subscriber -> Futures.addCallback(listenableFuture, new FutureCallback() { @Override public void onSuccess(@Nullable Object t) { subscriber.onSuccess(t); } @Override public void onFailure(Throwable throwable) { subscriber.onError(throwable); } }, Runnable::run)) ``` instead of: ```haskell Single.fromFuture(listenableFuture) ``` in next version of Daml SDK. ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [January 4, 2022, 12:18pm UTC](https://forum.canton.network/t/commandclient-submitandwait-non-blocking-results/3598/6 "2022-01-04T12:18:03Z")
Thanks for letting us know. I cannot guarantee that this will be fixed by the next SDK release as we have high priority work that has already been scheduled, but it’s definitely going to come in a future release.