best practices on mixing sync code with grizzly

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

best practices on mixing sync code with grizzly

Paulo Lopes
Hello,

I am very new to grizzly, I am still reading the documentation and I am not sure
if I understand it correctly. I understand that I can mix synchronous code
within a http handler but is that a good practice?

For example, I've a simple http server where at a given path should make a jdbc
call to a database and return some data.

HTTP GET /logs -> jdbc call "select * from logs" -> return csv to client

Now in the http handler i can do this as:

req, res -> {
  // get db conn
  // prepare statement
  // execute sql
  // return data
}

Now my question is what should be the "best approach"?

* just do it like that?
* or have say a threadpool which would do that work and for each request,
suspend the response, delegate to a threadpool worker, resume the response and
write the result?

My idea is to keep this server as simple as possible, so I would like to just
use the http handler and avoid the servlet addon.

Again I've no experience with grizzly so any feedback would be appreciated :)

Thanks!
Paulo
Reply | Threaded
Open this post in threaded view
|

Re: best practices on mixing sync code with grizzly

oleksiys
Administrator
Hi Paulo,


On 09.01.15 12:45, Paulo Lopes wrote:
> I am very new to grizzly, I am still reading the documentation and I am not sure
> if I understand it correctly. I understand that I can mix synchronous code
> within a http handler but is that a good practice?
Yes, it's ok, the question is which thread pool to use.
If you use SameThreadStrategy and by default HttpHandler is getting
invoked in I/O thread - you don't want to block this thread.
You can override HttpHandler's getRequestExecutorProvider(), to return a
provider, which will be responsible for picking up a thread-pool based
on the Request.
This way you can return null if you know the request is not blocking, so
it can be run in the I/O thread, or return Executor to run the blocking
request.

And you don't have to use servlet addon if you don't want.

WBR,
Alexey.

> For example, I've a simple http server where at a given path should make a jdbc
> call to a database and return some data.
>
> HTTP GET /logs -> jdbc call "select * from logs" -> return csv to client
>
> Now in the http handler i can do this as:
>
> req, res -> {
>    // get db conn
>    // prepare statement
>    // execute sql
>    // return data
> }
>
> Now my question is what should be the "best approach"?
>
> * just do it like that?
> * or have say a threadpool which would do that work and for each request,
> suspend the response, delegate to a threadpool worker, resume the response and
> write the result?
>
> My idea is to keep this server as simple as possible, so I would like to just
> use the http handler and avoid the servlet addon.
>
> Again I've no experience with grizzly so any feedback would be appreciated :)
>
> Thanks!
> Paulo