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 > > > > > > > > > >
