The controller actor is the one executing the blocking calls. So the controller actor MUST run on the blocking dispatcher. As far as I can read, the controller actor forwards the request to the router. Unless the actors behind the router make blocking calls, they do not need to be on the blocking dispatcher. The router itself should never be on the blocking dispatcher.
Assuming the blocking call is done only in the controller actor, you need to 1) make sure the controller actor uses the blocking dispatcher and 2) you have multiple instances of it for running parallel blocking request. This can be achieved by adding a router in front of it or by spawning a new controller actor for every request.
Or behind it? That's what I could not figure.
@akara
Also, httpservice -> Dispatcher is an ask, right?
What directive are you using to respond upon ask completion?
Assuming you're using the route API, of course.
Squbs routee
dispatcher -> controller is a forward call. This controller actor is a router
Each routee
@akara
I think there is a demand.
CompletableFuture<Object> futureb = ask(workerActorRef, request, 20000).toCompletableFuture();
String output = (String) futureb.get(20000, TimeUnit.MILLISECONDS);
String output = (String) futureb.get(20000, TimeUnit.MILLISECONDS);
We shouldn't use get method for the "ask" future object
instead
CompletionStage<Object> futureb = ask(workerActorRef, request, 20000);
pipe(futureb, getContext().dispatcher()).to(sender());
Use "pipe" instead of "get". It's a great point
The solve is to implement dual build in sbt and make sure all compiles well. We may have to go backwards for something we used Scala 2.12 features. But these are small, relatively easy changes.
@akara I have analysed the code. Can start working on it from this week.
Scala 2.11 support for java 8 is limited, based on my analysis we would have to write conversion methods between java to scala and vice-versa to completely support all the existing APIs.
Would like to confirm few things before working on it:
1) Should we use implicit or explicit conversions for scala to java conversions. Using scala implicit conversions would limit code change required in exiting squbs module, and can be confusing some times to understand the code.
2) Which module should contain all the conversion methods ?
Scala 2.11 support for java 8 is limited, based on my analysis we would have to write conversion methods between java to scala and vice-versa to completely support all the existing APIs.
Would like to confirm few things before working on it:
1) Should we use implicit or explicit conversions for scala to java conversions. Using scala implicit conversions would limit code change required in exiting squbs module, and can be confusing some times to understand the code.
2) Which module should contain all the conversion methods ?
For Scala-Java compat you can use: https://github.com/scala/scala-java8-compat
Note that the persistent buffer part already cross-compiles here: https://github.com/codacy/chronicle-queue-stream
Note that the persistent buffer part already cross-compiles here: https://github.com/codacy/chronicle-queue-stream
Thanks @andreaTP ! Yes, we're using the scala-java8-compat module for all Java APIs already. So that work should be minimal. We may have to downgrade the collection conversions to 2.11 (which will leave the code showing deprecated APIs in 2.12). Also in some cases we may have to resort to anonymous inner classes instead of using a Java8 function directly. But I see these as rather minimal. I'd say try to change sbt to add 2.11 compilation first. Then see what breaks. Address issues one-by-one. Thanks!
New PR passes all build
Hi Can you please merge the PR paypal/squbs#709 and create a release ? I need it to use in my application
Thanks @akara
But the snapshot version is available only for scala 2.12 and not for scala 2.11.
The sbt build in travis is not publishing for all versions in crossScalaVersion, the command should be as below in travis config
sbt ++$TRAVIS_SCALA_VERSION clean publishSignedGave a PR, can you please merge it to release the snapshot again ? Sorry about multiple commits and PR, sbt cross compile and travis is completely new for me.
I think we are ready for release of squbs 0.12.0. There is one PR though with Java Time duration #706 still open. Do we want to release w/o this PR or should we wait to resolve the remaining comments on the PR?