My goal is pretty simple, but unfortunately, Im totaly newbie in reactive programming:
having Mono <User> mono how to get User in easiest way without blocking threads?
Well, I finally subscribed on Mono method and retrieved its values through lambda. To all who just started, don't try to extract it by blocking.
Related
I'm using Retrofit with Reactor Adapter on a server. I thought that it allows me to make my calls unblocking by simple using Mono for retrofit and exposing it to Spring Boot as Mono as well (all operations in between are reactive).
However I noticed that when I try to run a few requests to an another service, that has some long operations inside (taking a few seconds), my service looks like it's blocking some thread, as when making several quick calls in proper configuration it can cause restarting my service (which is supposed to only wait for another service response, and data set it receives is small). Also some tracking tools make me think that my threads are busy when waiting for the response.
I tried to find some docs about that, and looked a bit into OkHttp and Okio code, and I couldn't find any part that could make it non blocking, and what's more it looked like it would be blocking.
Is there something I might miss in my retrofit configuration that could make my calls non blocking, or maybe someone is aware there is no way to make retrofit work this way? Or simply am I misinterpreting some data and it does should be non blocking by default?
I add to my Retrofit builder such setup method to enable Reactor:
addCallAdapterFactory(ReactorCallAdapterFactory.create())
OkHttp follows a roughly thread per connection model. So with a HTTP/2 server a single connection can support a variable number of requests with a fixed set of pooled connections and threads.
call.execute() will be blocking.
call.enqueue(...) will be non blocking but is using threads internally, and reading from the socket in blocking mode. This is hidden from clients, but OkHttp does not use Java NIO.
Does anyone know if OpenToks sendSignal() method is peer to peer? Or does it get routed through OpenTok's servers? We are looking to send image and video files P2P, but the signaling method seems a bit slower than webRTC's native data channel. I'm wondering if there is something extra happening under the hood.
From the documentation, you should be able to send to a specific end: https://tokbox.com/developer/sdks/js/reference/Session.html#signal. What you need to do is to specify a Connection object.
Previously i was using Java Future object and Await.result to fetch the response from an Akka actor. This allowed me to create a bridge between Java 6 code base and Akka.
Disadvantages: Threads blocking during long running tasks
I've moved to Java 8 and was looking at making use of non-blocking support to replace the Await.Result with a callback. In theory this will work well. However i notice in latest version of Typesafe HelloAkka tutorial with Java 8 that Akka Inbox is used to handle response rather than Future;
Is Inbox use preferred option over Future?
When would Future (or Completable Future) be a better option?
Both responses in this Stackoverflow post added context that may answer your question. Inbox (to my knowledge) is simply an alternative to using futures and calling other actors, instead you are allow other actors to interrogate your inbox (actor like object) from the outside...see this. Also, take a look at the "Cameo" patter by Jamie Allen. I posted a crude example on this Stackoverflow post.
if you want make a bridge with outside world, how are you intend to use inbox?? I guess all you have is a ref to actor.
take under consideration things like
how long can you wait for reply
replay can never come back - how you react to that
read about circuit breakers which guards your client code with possible errors with services (here akka system)
I would chose java's CompletableFuture as interface and translate akka's futures after ask or tell operation.
I'm pretty new to Spring Integration and still trying to get my head around it. Right now I'm just trying to understand if the example I've found here is actually safe across multiple threads:
https://github.com/spring-projects/spring-integration-samples/blob/master/basic/jms/src/test/java/org/springframework/integration/samples/jms/ChannelAdapterDemoTest.java
My use case is as follows:
Send request to queue with JMS Reply-to as a temporary queue
Wait for response to be received on the temporary queue
Need this to happen synchronously within a method -- I don't want to split it up and make it asynchronous across several methods
Will the above example work for this? If not, am I barking up the wrong tree?
Thanks in advance.
That sample is pretty simple; it just sends the message to stdout so, yes, it's perfectly thread safe.
For the request/reply scenario you are talking about, you need to use a <gateway/> - see the other example in that sample project. In that case, you can see that the message is handled by 'demoBean' which, again, is perfectly thread safe.
For a real application, the thread-safetyness depends on the code in the services invoked by the flow receiving the message.
If you wish, you can use Spring Integration on the client side too (with an outbound gateway).
I have this question, i am just throwing it out there. I am implementing a small logging feature for my spring based REST API server for logging all requests coming in.
I am expecting 1000s of users to use this API so with a blocking i/o logger, it's going to slow down everything. I have two approaches to solve the problem:
1. Have a async logger using an in-memory arrylist. then use the spring scheduler to flush this out to a log file periodically.
2. Use JMS and send the logs to the queue. Let the queue handle the logging asynchronously.
Has anyone done this before with spring. Though i am for option 2, are there better ways of doing this? Need some expert advice. Thanks everyone !
More info - I think synchronous logging will be a bottle neck because this REST API is consumed by a front end RoR app. So one session of the user will definitely result in 100s of API calls occuring very frequently. I am logging the actual request along with the JSON sent in the POSTs.
Has anyone done this before with spring.
Not so strangely, yes - Asynchronous Logging Using Spring
The article mentions that if you don't want any log events to be lost, JMS would be the way to go - otherwise sticking to Async makes sense for high volume logging.
If you really want to build your own logger, I suggest you to take a look at akka, it is much easier than JMS to set up.
You can use it locally (use of all CPU cores of your local machine), or even with remote agents.