Salut,
Survivant 00 wrote:
> Suppose that I receive a request from the client. I start processing
> the request, but it's possible that I'm waiting after the database
> before continuing the process. The request from the client will be
> blocked until the database return the results and after that the server
> will be able to continue to process the client request.. and after all
> that. the request will receive the response.
>
>
> ok.. just to understand outside grizzly, suppose we used selector , from
> the thread on which we use the selector.. it will block. Yes it make
> sense.. Even if the database have a pool.
>
> I think I get it.. without the suspendable filter we would have to do
> that : if the database pool is full.. to avoid the block, we should
> create another thread.. that will do polling and when the database is
> available.. bla bla bla.. (like you send below)
>
>
> suppose this case : we have a pipeline of 10. All the 10 connectors are
> currently use. so the suspendablefilter.. is pausing the current
> thread.. so another thread will start right ?
The SuspendableFilter will stop the execution and release the thread
back to the pool so we aren't wasting a thread blocked). Another thread
(let's say a thread that monitor the database connection availability)
will later call the resume() the pending operations.
if yes.. what will
> happen if all the connectors are use and one that was suspended resume ?
You should make sure you aren't resuming if there is no connector
available. Your logic should always make sure the resume operation will
succeed.
A+
-- Jeanfrancois
>
>
> 2008/7/4 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com
> <mailto:Jeanfrancois.Arcand_at_sun.com>>:
>
> Salut,
>
>
> Survivant 00 wrote:
>
> I don't understand when to use SuspendableFilter.
>
>
> Suppose that I receive a request from the client. I start
> processing the request, but it's possible that I'm waiting after
> the database before continuing the process. The request from
> the client will be blocked until the database return the results
> and after that the server will be able to continue to process
> the client request.. and after all that. the request will
> receive the response.
>
>
> I have a basic client/server application. The clients can send
> multiples requests to the server, and the server will response
> when it able to process them.
>
> so I don't understand what the SuspendableFilter will add to that .
>
> can someone explain it to me with a example ?
>
>
>
> Using your scenario, you will use the SuspendableFilter to avoid
> blocking a thread until the database returns the result. The
> database operation may takes a while to return, so freeing the
> Thread and resuming it later will help avoid all the thread blocked
> on a database operation.
>
> Another example is when you have more Threads than database
> connection. In that case, some thread may block on the database
> pool, waiting for a connection to be available. In that scenario,
> the Thread are wasted, waiting for a connection. A better approach
> would consist of suspending the execution (freeing the thread), and
> once database connection are available, resume the operation by
> getting back a thread.
>
> Hence the SuspendableFilter could be used for doing such
> suspend/resume. But with the new api I've discussed here[1], you
> will be able to do the same operations (suspend/resume) without the
> needs of using the SuspendableFilter.
>
> Does it help?
>
> Thanks
>
> -- Jeanfrancois
>
> [1] https://grizzly.dev.java.net/issues/show_bug.cgi?id=186
>
>
>
>
> thanks
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> <mailto:users-help_at_grizzly.dev.java.net>
>
>