On Wednesday, November 09, 2011 5:39:03 AM Aki Yoshida wrote: > 2011/10/11 Daniel Kulp <[email protected]>: > > 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 > > [email protected] > > http://dankulp.com/blog > > Talend - http://www.talend.com -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
