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 ? if yes.. what will happen if all the
connectors are use and one that was suspended resume ?
2008/7/4 Jeanfrancois Arcand <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
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>