HTTP metadata resolver XML config schema and parsers should support more HttpClient config options
Description
Environment
depends on
is related to
Activity
In r8508 added support to schema and parser AbstractDynamicHTTPMetadataProviderType for maxConnectionsTotal and maxConnectionsPerRoute. Each defaults to 100 connections.
There doesn't seem to be any point in adding these to the batch providers, since they only ever execute 1 HTTP request at a time.
Agree, I'd hold off and look at it for next version. We could always do it for 4.0 as part of yanking the legacy RP format which obviously is a given.
FWIW I'd not object to seeing the old one deprecated in 3.3, but thereagain I like hurrying people onto new stuff.
OTOH...
Given the size of HC and its continued fluidity I'm wondering whether we should move to getting people to only use Spring configured HCs and inject them. We can provide one of Scott's magical abstract beans if needed.
To make this tractable we'd need to make it possible to add <beans> statements into a metadata-providers.xml file. We have the technology to do this for attribute resolvers and attribute filters, but it may not be possible for Metadata. This is because the attribute config files have a noise element at the top level, but the top level of a metadata file (<MetadataResolver> has "meaning" and the whole parsng is a bit of a gubbins because of :
The legacy relying-party.xml support and
The implied chaining
..plus a bunch of relaxations in the schema
I can certainly look at this but for 3.4 - my head is elsewhere right now and anyway it feels like we are far too close to the wire to risk destabilising 3.3 with this.
In r8501 added schema and parser support for the 3 timeout options.
We may also want to consider adding connection management properties as described in JSPT-70. I say "may" because at some point trying to replicate all the possible HC config options become unwieldly. We do already have the option to directly inject an HC instance into the resolvers, which can be configured ad naseum, so maybe that should be the route to customize this.
As a related matter, the default of 2 max connections per route is not appropriate for the dynamic HTTP resolver. We need to decide how/where we would implement a higher default value. Similar to the discussion around timeout issues, personally I don't think we should have a "default" config (no properties explicitly set) which is pathological (e.g. infinite timeouts or only 2 concurrent connections).
Related to JSPT-66, at a minimum we need to expose all 3 timeout options as configurable properties on metadata resolvers:
connectionRequestTimeoutconnectionTimeoutsocketTimeoutCurrently there is just
requestTimeout, which sets HCconnectionTimeout, which is a little ambiguous. I would propose we deprecate this property and add 3 new properties with consistent naming per the above.