Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Akara Sucharitakul
@akara
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.
ganeshjanu
@ganeshjanu
@akara In my case, Do you want me to setup the blocking dispatcher with multiple instance for HttpService Actor? Or which actor?
Akara Sucharitakul
@akara
Controller actor, that does the blocking call.
ganeshjanu
@ganeshjanu
In my case, controller actor has the router.
Akara Sucharitakul
@akara
In front of it?
Or behind it? That's what I could not figure.
ganeshjanu
@ganeshjanu
httpservice->Dispatcher->Controller
@akara
Akara Sucharitakul
@akara
Where's the router?
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.
ganeshjanu
@ganeshjanu
HttpService -> Dispatcher is a look up call via the
Squbs routee
dispatcher -> controller is a forward call. This controller actor is a router
ganeshjanu
@ganeshjanu
controller-> worker actor is a ask call. This is a separate actor for
Each routee
@akara
Varun Kumar
@vk9
Hi all, Is it possible to support multiple version of scala, currently only scala 2.12 is being supported ? Currently I am working on some application which restricts upgrade from 2.11 to 2.12
Akara Sucharitakul
@akara
We can do so. There is even an issue for this. It may need some minor work on the API. The issue is the bandwidth to implement dual publish. But if you'd be happy to file a PR for this, we're more than open.
I think there is a demand.
Varun Kumar
@vk9
Can you please share the issue id, couldn't find it in open issues.
Will try to contribute and create a PR
ganeshjanu
@ganeshjanu
@akara It was a great session with you. Thank you for all your valuable inputs and suggestions with my use case.
My original Code is
CompletableFuture<Object> futureb = ask(workerActorRef, request, 20000).toCompletableFuture();
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
Akara Sucharitakul
@akara
That's right on. And you need to do CompletionStage composition if you need to do multiple asks.
Akara Sucharitakul
@akara
@vk9 sorry for the delay. Yes I though there is one but could not find an open one. Please do open.
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.
Varun Kumar
@vk9
@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 ?
Andrea Peruffo
@andreaTP
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
Akara Sucharitakul
@akara
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!
Andrea Peruffo
@andreaTP
yep, I found it easy to go back into the git history and get a version of the code that was compiling with 2.11
Akara Sucharitakul
@akara
@vk9 just saw you closed the PR due to build issues. I did not get to look into what they are just yet. Should be able to sort it out, though.
Varun Kumar
@vk9
@akara Sent a new PR, had some issues with build
New PR passes all build
Akara Sucharitakul
@akara
That's great! Let me take a look.
Varun Kumar
@vk9
Hi Can you please merge the PR paypal/squbs#709 and create a release ? I need it to use in my application
Akara Sucharitakul
@akara
We're close to releasing. But once merged, the snapshot should be immediately available upon build.
Varun Kumar
@vk9

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 publishSigned

Gave 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.

Akara Sucharitakul
@akara
Thanks! Yes, we need to make sure snapshot is released for both Scala versions.
Akara Sucharitakul
@akara
squbs 0.12.0 snapshot for Scala 2.11 has been successfully published. Thanks @vk9!
Sherif Ebady
@sebady
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?
Akara Sucharitakul
@akara
That great @sebady, thank you very much! I think we can make it happen with that PR as it is really close to closing. @jiminhsieh would you be able to update the PR as requested? The other way is to take the PR as is and I'll follow up with another small PR.
Akara Sucharitakul
@akara
@sebady, since @jiminhsieh may be busy, I suggest merging this PR and I'll follow up with a PR doing the requested adjustments to keep the FiniteDuration as coarse grained as possible.