Best way for void async calls?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Best way for void async calls?

Danny Hyun
I was reading the documentation about blocking calls

blocking {
  // some io stuff
} then { result ->
  // do something with this result
}

and saw that the blocking code won't run unless you call "then". This is presumably because you care to do something with the result but what about async calls where you don't care what happens?

Is it not advised to simply through this in a new thread?

Thread.start {
  // do work
}

render "noop"

It seems like this is more meaningful than "blocking { // do stuff } then { // empty block }"

I'm also wondering if it's a bad idea to hold onto the context in this async worker.
I have a "pixel service" that just tracks calls to the pixel: https://github.com/danhyun/ratpack-pixel-service
and in this project I pass a Request object into the service. Would this lead to a memory bloat?
Reply | Threaded
Open this post in threaded view
|

Re: Best way for void async calls?

uris77
I would do this with an EventBus. I do this a lot in javascript, but not sure if that is the recommended way of doing it with Ratpack.
rus
Reply | Threaded
Open this post in threaded view
|

Re: Best way for void async calls?

rus
In reply to this post by Danny Hyun

Looking at your code, you're not doing any blocking I/O are you? I don't think you need to use the blocking dsl at all. Especially if you swap the println and use an async logger.

On 21 Jul 2014 18:59, "Danny Hyun [via Ratpack Forum]" <[hidden email]> wrote:
I was reading the documentation about blocking calls

blocking {
  // some io stuff
} then { result ->
  // do something with this result
}

and saw that the blocking code won't run unless you call "then". This is presumably because you care to do something with the result but what about async calls where you don't care what happens?

Is it not advised to simply through this in a new thread?

Thread.start {
  // do work
}

render "noop"

It seems like this is more meaningful than "blocking { // do stuff } then { // empty block }"

I'm also wondering if it's a bad idea to hold onto the context in this async worker.
I have a "pixel service" that just tracks calls to the pixel: https://github.com/danhyun/ratpack-pixel-service
and in this project I pass a Request object into the service. Would this lead to a memory bloat?


If you reply to this email, your message will be added to the discussion below:
http://forum.ratpack.io/Best-way-for-void-async-calls-tp532.html
To start a new topic under Ratpack Forum, email [hidden email]
To unsubscribe from Ratpack Forum, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Best way for void async calls?

Danny Hyun
Thanks rus. The println was meant to be a dummy implementation of what one may want to do. You could replace it with a scribe call or kafka client call or write to a local file or make a db call.

I believe that the java kafka client makes blocking network calls and so I would want to have that run in a background thread and I don't care if the call was successful or not.
rus
Reply | Threaded
Open this post in threaded view
|

Re: Best way for void async calls?

rus
Ahh right I see.

Ideally you want to run on the blockingExecutor rather than use Thread.start but blockingExecutor is not exposed other than using the blocking dsl.  I think to do what you want requires a change unless Luke knows of anything.
Reply | Threaded
Open this post in threaded view
|

Re: Best way for void async calls?

Luke Daley
Administrator
You definitely should not use Thread.start {}. This is going to kill performance because thread creation is not cheap.

You should use ExecControl.fork() (Context implements ExecControl). 

In this particular case though, you’d be better off using Context.onClose() as I updated your pull request to use: https://github.com/alkemist/ratpack-pixel-service/commit/06c594eacec6335766965f68a69d5cfaab36fe05
Reply | Threaded
Open this post in threaded view
|

Re: Best way for void async calls?

Danny Hyun
Awesome, thanks all!

So I see there is also ExecControl.start which the javadocs states is functionally equivalent to fork. When would I use one over the other?

Also is the point of using onClose to return the response as soon as possible so as not to use the main request processing thread? And is it still a bad idea to pass instances of "context" and "request" around?
Reply | Threaded
Open this post in threaded view
|

Re: Best way for void async calls?

Luke Daley
Administrator
There is ExecControl.fork() and ExecController.start().


They are equivalent. You typically have hold of a control though, not a controller.

Also is the point of using onClose to return the response as soon as possible so as not to use the main request processing thread? 

It’s still on a request processing thread, but happens after the response goes into the IO queue. In this case that’s ideal because you get the response out as soon as possible, then perform the rest of the work without having to move threads.

> And is it still a bad idea to pass instances of "context" and "request" around?

The request object is fine because it’s immutable, you shouldn’t be passing context around though unless it’s strictly about request _handling_ (which in this case it’s not).


Reply | Threaded
Open this post in threaded view
|

Re: Best way for void async calls?

Danny Hyun
Cool. Thanks so much for the improvements!