Petals BC SOAP

Remove Component's ws-clients-pool-size-max parameter and add Component's max-http-connections-per-host

Details

  • Type: Improvement Request Improvement Request
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 4.4.0
  • Fix Version/s: 4.4.1
  • Component/s: None
  • Security Level: Public
  • Description:
    Hide

    Currently, the BC SOAP component supports a parameter named ws-clients-pool-size-max parameter that actually tunes the number of maximum connections that can exist concurrently per host (for Provides thus).

    It makes no sense to configure such things knowing that:

    • We have a maximum number, per provides, of http client that can hold such connections.
    • We have a maximum number, per component, of processor threads that can hold such http client.

    The maximum number of http client should be equal to the maximum number of processor (the idea being that there can't be more clients needed that the number of processors).
    The maximum number of processor is configurable (see the CDK configuration).

    So the maximum number of connections should be configured based on the maximum number of http client that can hold them, i.e., the maximum number of processors.
    Also, the maximum number of connections to a same host should be configurable using the parameter max-http-connections-per-host.
    It should default to the maximum number of processor too.

    Show
    Currently, the BC SOAP component supports a parameter named ws-clients-pool-size-max parameter that actually tunes the number of maximum connections that can exist concurrently per host (for Provides thus). It makes no sense to configure such things knowing that:
    • We have a maximum number, per provides, of http client that can hold such connections.
    • We have a maximum number, per component, of processor threads that can hold such http client.
    The maximum number of http client should be equal to the maximum number of processor (the idea being that there can't be more clients needed that the number of processors). The maximum number of processor is configurable (see the CDK configuration). So the maximum number of connections should be configured based on the maximum number of http client that can hold them, i.e., the maximum number of processors. Also, the maximum number of connections to a same host should be configurable using the parameter max-http-connections-per-host. It should default to the maximum number of processor too.
  • Environment:
    -

Activity

Hide
Christophe DENEUX added a comment - Wed, 28 Oct 2015 - 15:58:26 +0100

Are you sure that ws-clients-pool-size-max is the maximum number of connection per host ? IMO, its the maximum number of WS clients for a given operation of a web service, that is not the same thing.

Show
Christophe DENEUX added a comment - Wed, 28 Oct 2015 - 15:58:26 +0100 Are you sure that ws-clients-pool-size-max is the maximum number of connection per host ? IMO, its the maximum number of WS clients for a given operation of a web service, that is not the same thing.
Hide
Victor NOËL added a comment - Wed, 28 Oct 2015 - 16:04:04 +0100

Well I don't know what was the plan at first, but in the code, it was used for the maximum number of connections per host.

If it was for the maximum number of WS clients for a given operation, then it would be settable per Provides and not per Component.

For now I didn't change the current behaviour, that is to have the same max number of ws client per service than the max number of processors.
In some case, we could find ourselves with more ws clients that usable (since there will be many services per components), for example just after a lot of call to the same service happened. But I think it's an ok default situation and after some time the extra ws clients will be purged from the pool and things will be ok

We could think about introducing a parameter to set the ws client pool (actually named ws-clients-pool-size-max but PER PROVIDES and not component), but I'm not really convinced it is so useful…

Show
Victor NOËL added a comment - Wed, 28 Oct 2015 - 16:04:04 +0100 Well I don't know what was the plan at first, but in the code, it was used for the maximum number of connections per host. If it was for the maximum number of WS clients for a given operation, then it would be settable per Provides and not per Component. For now I didn't change the current behaviour, that is to have the same max number of ws client per service than the max number of processors. In some case, we could find ourselves with more ws clients that usable (since there will be many services per components), for example just after a lot of call to the same service happened. But I think it's an ok default situation and after some time the extra ws clients will be purged from the pool and things will be ok We could think about introducing a parameter to set the ws client pool (actually named ws-clients-pool-size-max but PER PROVIDES and not component), but I'm not really convinced it is so useful…

People

Dates

  • Created:
    Wed, 28 Oct 2015 - 15:01:10 +0100
    Updated:
    Wed, 28 Oct 2015 - 16:21:18 +0100
    Resolved:
    Wed, 28 Oct 2015 - 15:50:13 +0100