users@grizzly.java.net

Re: best practices on mixing sync code with grizzly

From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Date: Fri, 09 Jan 2015 15:16:11 -0800

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