You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Aki Yoshida <el...@googlemail.com> on 2011/11/09 05:39:03 UTC
Re: Async http requests and workqueue....
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 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