Hi,
I haven't seen async processing in real-life yet, so I can't really
comment on its usefulness.
> my very first idea was to be able to serve more request with the same
thread count
Most examples I've found just move processing to a different thread - as
I have done it in my example too :(.
You'd be able to server more requests by utilizing a notification based
API which doesn't block a thread, e.g. with async HTTP requests:|||
|
| public void onClick() {|
||| Suspension suspension = getRequestCycle().suspend(5000);| ||
httpclient.execute(request2, new FutureCallback<HttpResponse>()
{
public void completed(final HttpResponse response) {
analyseResponse(response)
suspension.resume();
}
});
>Any other thought is welcome.
Branch "suspend_request_cycle" is just a proof-of-concept. Regretfully
at the moment I can't make use of it in any of my projects.
Have fun
Sven
On 04.03.2017 18:26, guillaume.mary wrote:
Hi,
Thank you for your code, I gave it a try and looked at it closer, and I'm
ont sure it feets a real need, well at least mine : it delegates the answer
to another thread, so it's as if we add a worker thread to the container,
kind of machine load. It is not what I expected : my very first idea was to
be able to serve more request with the same thread count, not to overload
the machine. I thought that async nio would allow this, but I'm far from an
expert about nio, even after reading more about it.
So even if your code works, I don't see a real benefit for Wicket, and even
less a feature for it.
Any other thought is welcome.
(I didn't post on @dev as you offered since we're more on a "feature"
discussion)
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Wicket-8-and-servlet-3-1-async-nio-tp4677098p4677242.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
