cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Pell <>
Subject Re: throttling http-conduit connections
Date Tue, 29 May 2012 05:23:59 GMT
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 <> 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 <> 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
>> Web:
>> Twitter: freemanfang
>> Blog:
>> weibo:

View raw message