Hey thanks heaps for that, very flexible and better than my semaphore approach. I like your license choice too :-)
On Tue, May 29, 2012 at 3:41 PM, Abhishek Sharma <[email protected]> wrote: > Hi Jason, > > This article explain the throttle which schedule the request in a sliding > time window manner: > http://www.cordinc.com/blog/2010/06/ordered-java-multichannel-asyn.html > > This was written for service provider but if you want to schedule your calls > at client side you can use similar concept. > > Regards, > Abhishek > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Jason > Pell > Sent: Tuesday, May 29, 2012 10:54 AM > To: [email protected] > Subject: Re: throttling http-conduit connections > > How can I force the same HttpConduit instance to be used by two > different clients (that both have the same underlying URL address)? > > Would further simplify as I could contain all of the throttling to the > Connection factory inside of the HttpConduit - assuming I can move the > call to prepare to a PREPARE_SEND interceptor. > > I am assuming I can probably modify the standard XML Out client change > (I am using jaxws with bindingId xformat), by removing the > MessageSender interceptor that calls the HttpConduit prepare() and > instead call prepare and close in the MessageSenderEnding interceptor > and write the Cached Output Stream to the connection. > > I know this will result in some blocked threads, but I do not think > this is going to be too much of an issue for me at this point. > > I would really appreciate any insight or suggestions you might have > > On Tue, May 29, 2012 at 3:19 PM, Jason Pell <[email protected]> wrote: >> Hi, >> >> I have started looking at the async jax-ws stuff and I can see how >> that might assist me, but it >> still does not solve the problem of throttling the number of http >> connections. >> >> Can I make use of the ConduitSelector to somehow provide a proxy >> around HttpConduit and force >> selectConduit to wait until there is a free http connection available? >> I wanted to get some reactions around the approach, including if >> appropriate.... >> >> 1) That won't work >> 2) Its a really stupid idea :-) >> 3) Here's an alternative... >> >> I am really trying to throttle the number of Http Connections >> themselves and since HttpConduit is where these suckers are created I >> am thinking it might be in the right general direction. >> >> Since the factory for HttpConduits is created from the >> HttpTransportFactory which is something I am hesitant to even think >> about stuffing around with, I was thinking I could have my own >> ConduitSelector where I could throttle in the selectConduit method. >> >> I would also have to somehow delay the call to the prepare method in >> my client interceptor chain until PREPARE_SEND. Because my clients >> cache all the output stream anyway, I don't actually need the Http >> Connection to be opened until the PREPARE_SEND anyway. In this way >> I could throttle the opening of the Http Connection until there is an >> available connection from the call to Semaphore.acquire(some timeout >> in ms); >> >> As an alternative I was wondering what would be involved in overriding >> the HttpTransportFactory with my own implementation and also extending >> HttpConduit to make use of my own Connection Factory (which would >> respect the Semaphore approach I already discussed) >> >> >> >> >> >> >> >> On Mon, May 28, 2012 at 4:04 PM, Freeman Fang <[email protected]> wrote: >>> Hi, >>> >>> May not answer your question directly, but as the service provider has >>> connection limitation, IMO it's hard to control the connection count from >>> client side, you possibly have multiple clients even on different hosts >>> launched by different person, how could one client know other client's >>> connection? Using a global process to maintain the different clients >>> connections is so ugly. >>> >>> For your scenario, I believe the new cxf server side asynchronous handling >>> introduced since CXF 2.6.0 should help, it leverage CXF continuation API >>> hence won't block the transport level thread, you may need take a look at >>> jaxws_async example shipped with CXF 2.6.0 kit to get more details. >>> >>> Freeman >>> >>> On 2012-5-28, at 上午11:29, Jason Pell wrote: >>> >>>> Hi, >>>> >>>> I have a requirement to be able to throttle my jaxws:client >>>> connections to an external web service. So lets say the service >>>> provider requires me to limit the number of simultaneous connections >>>> to their web site to be 10 connections. I was thinking I could use a >>>> counting semaphore with a constructor arg of 10 and then call acquire >>>> before opening the connection to the external web service and >>>> release() when i receive the response and close the connection. The >>>> external calls are synchronous. >>>> >>>> However I am not sure where to start looking at this. It would be >>>> awesome if I could include this into the HttpConduit class. >>>> >>>> The other thing to keep in mind is that I have the potential to have >>>> multiple jaxws:client that refer to the same external url, and so I >>>> want to be able throttle the total connections across both client >>>> beans. >>>> >>>> I guess what I would like to do is share a HttpConduit across both >>>> clients (the url would be exactly the same for both of the clients) >>>> >>>> The reason why I can have two clients pointing at the same url, is I >>>> have xslt transformations in the interceptors so they expose different >>>> interfaces but get mapped to the same one going out to the external >>>> service. >>>> >>>> Could I provide my own HttpConduit implementation, or would this be >>>> something that CXF would be interested in having contributed? >>> >>> >>> --------------------------------------------- >>> Freeman Fang >>> >>> FuseSource >>> Email:[email protected] >>> Web: fusesource.com >>> Twitter: freemanfang >>> Blog: http://freemanfang.blogspot.com >>> http://blog.sina.com.cn/u/1473905042 >>> weibo: http://weibo.com/u/1473905042 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>
