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

Ascending order - Click to sort in descending order
Victor NOËL made changes - Wed, 28 Oct 2015 - 15:01:19 +0100
Field Original Value New Value
Status New [ 10000 ] Open [ 10002 ]
Priority Major [ 3 ]
Assignee Christophe DENEUX [ cdeneux ] Victor NOËL [ vnoel ]
Victor NOËL made changes - Wed, 28 Oct 2015 - 15:05:58 +0100
Summary Rename Component's ws-clients-pool-size-max parameter to ws-clients-per-host-pool-size-max Remove Component's ws-clients-pool-size-max parameter max-http-connections-per-host
Description 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 of http client that can hold such connections.
 - We have a maximum number of processor threads that can hold such http client.

The maximum number of http client is the same as 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.

So the maximum number of connections should be configured based on the maximum number of http client that can hold them, i.e., based on the maximum number of processors.
Also, the maximum number of connections to a same host should be configurable, and should default to the maximum number of processor too. 		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 of http client that can hold such connections.
 - We have a maximum number of processor threads that can hold such http client.

The maximum number of http client is the same as 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.

So the maximum number of connections should be configured based on the maximum number of http client that can hold them, i.e., based on the maximum number of processors.
Also, the maximum number of connections to a same host should be configurable, and should default to the maximum number of processor too.
It will be set using the parameter max-http-connections-per-host.
Victor NOËL made changes - Wed, 28 Oct 2015 - 15:11:34 +0100
Summary Remove Component's ws-clients-pool-size-max parameter max-http-connections-per-host Rename Component's ws-clients-pool-size-max parameter to Component's max-http-connections-per-host and add SU Provides ws-clients-pool-size-max.
Description 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 of http client that can hold such connections.
 - We have a maximum number of processor threads that can hold such http client.

The maximum number of http client is the same as 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.

So the maximum number of connections should be configured based on the maximum number of http client that can hold them, i.e., based on the maximum number of processors.
Also, the maximum number of connections to a same host should be configurable, and should default to the maximum number of processor too.
It will be set using the parameter max-http-connections-per-host. 		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 configurable using a SU Provides parameter named ws-clients-pool-size-max.
It should default to the maximum number of processor (the idea being that there can't be more clients needed that the number of processors).
Note that this default setting potentially can create situations where there is more pooled service client for the whole component than possibly usable... it's ok but it can thus be tweaked using the parameter if needed.
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.
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 (because it is configured for the whole component and not per provides).
Victor NOËL made changes - Wed, 28 Oct 2015 - 15:17:41 +0100
Summary Rename Component's ws-clients-pool-size-max parameter to Component's max-http-connections-per-host and add SU Provides ws-clients-pool-size-max. Rename Component's ws-clients-pool-size-max parameter to Component's max-http-connections-per-host
Description 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 configurable using a SU Provides parameter named ws-clients-pool-size-max.
It should default to the maximum number of processor (the idea being that there can't be more clients needed that the number of processors).
Note that this default setting potentially can create situations where there is more pooled service client for the whole component than possibly usable... it's ok but it can thus be tweaked using the parameter if needed.
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.
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 (because it is configured for the whole component and not per provides). 		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.
Victor NOËL made changes - Wed, 28 Oct 2015 - 15:50:04 +0100
Status Open [ 10002 ] In Progress [ 10003 ]
Victor NOËL made changes - Wed, 28 Oct 2015 - 15:50:13 +0100
Status In Progress [ 10003 ] Resolved [ 10004 ]
Fix Version/s 4.4.1 [ 10587 ]
Resolution Fixed [ 1 ]
Hide
Permalink
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
Permalink
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…
Victor NOËL made changes - Wed, 28 Oct 2015 - 16:21:18 +0100
Summary Rename Component's ws-clients-pool-size-max parameter to Component's max-http-connections-per-host Remove Component's ws-clients-pool-size-max parameter and add Component's max-http-connections-per-host
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
9s
1
Victor NOËL
Wed, 28 Oct 2015 - 15:01:19 +0100
Open Open In Progress In Progress
48m 45s
1
Victor NOËL
Wed, 28 Oct 2015 - 15:50:04 +0100
In Progress In Progress Resolved Resolved
9s
1
Victor NOËL
Wed, 28 Oct 2015 - 15:50:13 +0100

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
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.