Background Question

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

Background Question

Jeremy Odell
I was going over the following code from the books-example ratpack project:

handler("create") {
            byMethod {
                get {
                    render groovyTemplate("create.html", title: "Create Book")
                }
                post {
                    def form = parse form()
                    background {
                        bookService.insert(form.title, form.content)
                    } then {
                    println "in the then"
                        redirect "/?msg=Book+$it+created"

                    }
                    println "outside of background"
                }
            }

I understand that the purpose of the background method is to create an asynchronous call to the database (in this case).  After that returns it will render the page.

But the underlying HTTP request from the client is synchronous.  So if that call is synchronous, what do we gain by pushing this database call off on another thread?

Thanks for any insight to this.

Jeremy
Reply | Threaded
Open this post in threaded view
|

Re: Background Question

Luke Daley
Administrator


> On 10 Dec 2013, at 19:04, "Jeremy Odell [via Ratpack Forum]" <[hidden email]> wrote:
>
> I was going over the following code from the books-example ratpack project:
>
> handler("create") {
>             byMethod {
>                 get {
>                     render groovyTemplate("create.html", title: "Create Book")
>                 }
>                 post {
>                     def form = parse form()
>                     background {
>                         bookService.insert(form.title, form.content)
>                     } then {
>                     println "in the then"
>                         redirect "/?msg=Book+$it+created"
>
>                     }
>                     println "outside of background"
>                 }
>             }
>
> I understand that the purpose of the background method is to create an asynchronous call to the database (in this case).  After that returns it will render the page.
>
> But the underlying HTTP request from the client is synchronous.  So if that call is synchronous, what do we gain by pushing this database call off on another thread?
>
> Thanks for any insight to this.

The code above is actually dealing with a blocking IO call, not a synchronous one.

Did you read http://www.ratpack.io/manual/current/backgrounding.html ?

This is not an RTFM response. I just want to know if the above page is unclear and needs to be improved.
Reply | Threaded
Open this post in threaded view
|

Re: Background Question

Jeremy Odell
Luke Daley wrote
Did you read http://www.ratpack.io/manual/current/backgrounding.html ?

This is not an RTFM response. I just want to know if the above page is unclear and needs to be improved.
Yes and I think the lack of understanding might be on my side rather than the documentation.  

from the document
...However, this is not always possible. For example, many database access libraries only support blocking on IO. In such cases, you can use Ratpackā€™s backgrounding support to perform the blocking operation off the request handling threads.
So in the book example you are using the background.  What does this gain us as opposed to not using it?  


Reply | Threaded
Open this post in threaded view
|

Re: Background Question

Luke Daley
Administrator
Jeremy Odell wrote
So in the book example you are using the background.  What does this gain us as opposed to not using it?
Better throughput. If you block on a request thread you significantly reduce throughput. Your options are:

1. Use async IO (you need a lib that supports this, and jdbc does not)
2. Perform blocking IO on the background, freeing the request thread to perform other work while you're blocking
3. Increase the request handling thread pool (via LaunchConfig) and accept the generally reduced throughput

#1 is best case, #2 makes sense if you perform some blocking, #3 makes sense if your app is mostly blocking ops.


That said, for the sample app this is moot because the DB is in memory so there is no blocking. But, the app is an example of how to do blocking IO.
Reply | Threaded
Open this post in threaded view
|

Re: Background Question

Luke Daley
Administrator
On #3 above, this would only degrade performance to the level of a blocking HTTP server (like a Java app server) in general.
Reply | Threaded
Open this post in threaded view
|

Re: Background Question

Jeremy Odell
Thank you Luke, that was what I was needing to help in understanding.
rus
Reply | Threaded
Open this post in threaded view
|

Re: Background Question

rus
I did a blog post about this http://blog.anacoders.com/blocking-code-in-ratpack/

Blogging is not my strong point but might help.