You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2011/10/06 03:31:30 UTC
Async http requests and workqueue....
I have a question for folks to see what folks would think is the "best
option". Basically, if you use one of the JAX-WS async methods on a client
when talking to an HTTP service, we have to put a runnable on the workqueue to
handle the response. The question is, what should we do if the workqueue is
full? Could options:
1) (current behavior) Throw the RejectedExecutionException so the user knows
they are exceeding defaults and likely should reconfigure things.
2) Loop in a Thread.yield and retry putting it on the queue until successfull.
3) Run the runnable synchronously on the calling thread.
Likely 2 and 3 would both log a WARNING to let the user know to reconfigure.
Obviously, the best solution would be to finish the work I did to use the
apache http-client instead of the HttpURLConnection, but lets not go there
right now. :-)
Anyway, thoughts?
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Async http requests and workqueue....
Posted by Johan Edstrom <jo...@apache.org>.
If async in a client is a "loop" then only 2 really makes sense, that forces
all the error handling on the client though.
#3 is a possible thing a #2 could do?
Number 1 is just an "INONLY" and thx, k bai type solution?
On Wed, Oct 5, 2011 at 7:31 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> I have a question for folks to see what folks would think is the "best
> option". Basically, if you use one of the JAX-WS async methods on a
> client
> when talking to an HTTP service, we have to put a runnable on the workqueue
> to
> handle the response. The question is, what should we do if the workqueue
> is
> full? Could options:
>
> 1) (current behavior) Throw the RejectedExecutionException so the user
> knows
> they are exceeding defaults and likely should reconfigure things.
>
> 2) Loop in a Thread.yield and retry putting it on the queue until
> successfull.
>
> 3) Run the runnable synchronously on the calling thread.
>
> Likely 2 and 3 would both log a WARNING to let the user know to
> reconfigure.
>
>
> Obviously, the best solution would be to finish the work I did to use the
> apache http-client instead of the HttpURLConnection, but lets not go there
> right now. :-)
>
> Anyway, thoughts?
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
Re: Async http requests and workqueue....
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday, November 09, 2011 5:39:03 AM Aki Yoshida wrote:
> 2011/10/11 Daniel Kulp <dk...@apache.org>:
> > On Sunday, October 09, 2011 9:27:09 AM Willem Jiang wrote:
> >> Hi Dan,
> >>
> >> I think the first option is OK, and it can let the user know what's
> >> wrong immediately.
> >> The other two option will be confused to the user if he just see the
> >> error and the call is succeed.
> >
> > After thinking about this some more, option 1 is REALLY a bad option.
> > The problem is that the request has been sent. Thus, the server is
> > processing it and doing whatever it's supposed to do. However, the
> > client has no indication about the status of that request, any way to
> > get a response, fault, etc....
>
> The situation where the service being called but the response is not
> fully returned to the client can happen to a synchronous case as well.
> So, the behavior of 1 is unfriendly, but considering its simplicity, I
> thought it was not so bad.
>
> In the worst case, if option 2 accumulates rejected calls for later
> queuing, some of those calls must eventually take the same fate as in
> the option 1 to avoid an uncontrolled accumulation of calls. So,
> option 2 isn't necessarily a better solution than option 1, or is it?
No, it's not. That's why it now uses a combination of #2 and #3. Our
workqueue has an execute method that takes a timeout where it will timeout
trying to call Offer on the queue. We not use that to offer it to the queue
with a couple second timeout (that should be configurable, but it's not right
now). If it timeout's, it just executes it like a synchronous request. Not
ideal, but I think its better than it was. It really is only an issue if you
have a ton of outstanding async requests (by default 281, 25 threads + 256
queue) so it's not likely to be hit in normal operation, but under heavy load,
this does help a lot.
That said, after doing all these benchmarks and such, I'm definitely bumping
up the priority to getting the HTTP-commons based client working. That would
solve most of the issues itself.
Dan
>
> regards, aki
>
> > I put #3 in place, but that has other issues with Camel, but none as bad
> > a option #1. I'm still playing with various options.
> >
> > Dan
> >
> >> On Thu Oct 6 09:31:30 2011, Daniel Kulp wrote:
> >> > I have a question for folks to see what folks would think is the
> >> > "best
> >> > option". Basically, if you use one of the JAX-WS async methods
> >> > on a
> >> > client when talking to an HTTP service, we have to put a runnable
> >> > on
> >> > the workqueue to handle the response. The question is, what
> >> > should we do if the workqueue is full? Could options:
> >> >
> >> > 1) (current behavior) Throw the RejectedExecutionException so the
> >> > user
> >> > knows they are exceeding defaults and likely should reconfigure
> >> > things.
> >> >
> >> > 2) Loop in a Thread.yield and retry putting it on the queue until
> >> > successfull.
> >> >
> >> > 3) Run the runnable synchronously on the calling thread.
> >> >
> >> > Likely 2 and 3 would both log a WARNING to let the user know to
> >> > reconfigure.
> >> >
> >> >
> >> > Obviously, the best solution would be to finish the work I did to
> >> > use
> >> > the
> >> > apache http-client instead of the HttpURLConnection, but lets not
> >> > go
> >> > there right now. :-)
> >> >
> >> > Anyway, thoughts?
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
> > Talend - http://www.talend.com
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Async http requests and workqueue....
Posted by Aki Yoshida <el...@googlemail.com>.
2011/10/11 Daniel Kulp <dk...@apache.org>:
> On Sunday, October 09, 2011 9:27:09 AM Willem Jiang wrote:
>> Hi Dan,
>>
>> I think the first option is OK, and it can let the user know what's
>> wrong immediately.
>> The other two option will be confused to the user if he just see the
>> error and the call is succeed.
>
> After thinking about this some more, option 1 is REALLY a bad option. The
> problem is that the request has been sent. Thus, the server is processing it
> and doing whatever it's supposed to do. However, the client has no
> indication about the status of that request, any way to get a response, fault,
> etc....
The situation where the service being called but the response is not
fully returned to the client can happen to a synchronous case as well.
So, the behavior of 1 is unfriendly, but considering its simplicity, I
thought it was not so bad.
In the worst case, if option 2 accumulates rejected calls for later
queuing, some of those calls must eventually take the same fate as in
the option 1 to avoid an uncontrolled accumulation of calls. So,
option 2 isn't necessarily a better solution than option 1, or is it?
regards, aki
>
> I put #3 in place, but that has other issues with Camel, but none as bad a
> option #1. I'm still playing with various options.
>
> Dan
>
>
>>
>> On Thu Oct 6 09:31:30 2011, Daniel Kulp wrote:
>> > I have a question for folks to see what folks would think is the "best
>> > option". Basically, if you use one of the JAX-WS async methods on a
>> > client when talking to an HTTP service, we have to put a runnable on
>> > the workqueue to handle the response. The question is, what should we
>> > do if the workqueue is full? Could options:
>> >
>> > 1) (current behavior) Throw the RejectedExecutionException so the user
>> > knows they are exceeding defaults and likely should reconfigure things.
>> >
>> > 2) Loop in a Thread.yield and retry putting it on the queue until
>> > successfull.
>> >
>> > 3) Run the runnable synchronously on the calling thread.
>> >
>> > Likely 2 and 3 would both log a WARNING to let the user know to
>> > reconfigure.
>> >
>> >
>> > Obviously, the best solution would be to finish the work I did to use
>> > the
>> > apache http-client instead of the HttpURLConnection, but lets not go
>> > there right now. :-)
>> >
>> > Anyway, thoughts?
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
Re: Async http requests and workqueue....
Posted by Daniel Kulp <dk...@apache.org>.
On Sunday, October 09, 2011 9:27:09 AM Willem Jiang wrote:
> Hi Dan,
>
> I think the first option is OK, and it can let the user know what's
> wrong immediately.
> The other two option will be confused to the user if he just see the
> error and the call is succeed.
After thinking about this some more, option 1 is REALLY a bad option. The
problem is that the request has been sent. Thus, the server is processing it
and doing whatever it's supposed to do. However, the client has no
indication about the status of that request, any way to get a response, fault,
etc....
I put #3 in place, but that has other issues with Camel, but none as bad a
option #1. I'm still playing with various options.
Dan
>
> On Thu Oct 6 09:31:30 2011, Daniel Kulp wrote:
> > I have a question for folks to see what folks would think is the "best
> > option". Basically, if you use one of the JAX-WS async methods on a
> > client when talking to an HTTP service, we have to put a runnable on
> > the workqueue to handle the response. The question is, what should we
> > do if the workqueue is full? Could options:
> >
> > 1) (current behavior) Throw the RejectedExecutionException so the user
> > knows they are exceeding defaults and likely should reconfigure things.
> >
> > 2) Loop in a Thread.yield and retry putting it on the queue until
> > successfull.
> >
> > 3) Run the runnable synchronously on the calling thread.
> >
> > Likely 2 and 3 would both log a WARNING to let the user know to
> > reconfigure.
> >
> >
> > Obviously, the best solution would be to finish the work I did to use
> > the
> > apache http-client instead of the HttpURLConnection, but lets not go
> > there right now. :-)
> >
> > Anyway, thoughts?
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Async http requests and workqueue....
Posted by Willem Jiang <wi...@gmail.com>.
Hi Dan,
I think the first option is OK, and it can let the user know what's
wrong immediately.
The other two option will be confused to the user if he just see the
error and the call is succeed.
On Thu Oct 6 09:31:30 2011, Daniel Kulp wrote:
>
> I have a question for folks to see what folks would think is the "best
> option". Basically, if you use one of the JAX-WS async methods on a client
> when talking to an HTTP service, we have to put a runnable on the workqueue to
> handle the response. The question is, what should we do if the workqueue is
> full? Could options:
>
> 1) (current behavior) Throw the RejectedExecutionException so the user knows
> they are exceeding defaults and likely should reconfigure things.
>
> 2) Loop in a Thread.yield and retry putting it on the queue until successfull.
>
> 3) Run the runnable synchronously on the calling thread.
>
> Likely 2 and 3 would both log a WARNING to let the user know to reconfigure.
>
>
> Obviously, the best solution would be to finish the work I did to use the
> apache http-client instead of the HttpURLConnection, but lets not go there
> right now. :-)
>
> Anyway, thoughts?
>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang