Package io.envoyproxy.envoy.config.cluster.v3

Class Cluster.PreconnectPolicy.Builder

    • Field Detail

      • bitField0_

        private int bitField0_

      • perUpstreamPreconnectRatio_

        private com.google.protobuf.DoubleValue perUpstreamPreconnectRatio_

      • perUpstreamPreconnectRatioBuilder_

        private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,​com.google.protobuf.DoubleValue.Builder,​com.google.protobuf.DoubleValueOrBuilder> perUpstreamPreconnectRatioBuilder_

      • predictivePreconnectRatio_

        private com.google.protobuf.DoubleValue predictivePreconnectRatio_

      • predictivePreconnectRatioBuilder_

        private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,​com.google.protobuf.DoubleValue.Builder,​com.google.protobuf.DoubleValueOrBuilder> predictivePreconnectRatioBuilder_

    • Constructor Detail

      • Builder

        private Builder()

      • Builder

        private Builder​(com.google.protobuf.AbstractMessage.BuilderParent parent)

    • Method Detail

      • getDescriptor

        public static final com.google.protobuf.Descriptors.Descriptor getDescriptor()

      • internalGetFieldAccessorTable

        protected com.google.protobuf.GeneratedMessage.FieldAccessorTable internalGetFieldAccessorTable()
        Specified by:
        internalGetFieldAccessorTable in class com.google.protobuf.GeneratedMessage.Builder<Cluster.PreconnectPolicy.Builder>

      • maybeForceBuilderInitialization

        private void maybeForceBuilderInitialization()

      • getDescriptorForType

        public com.google.protobuf.Descriptors.Descriptor getDescriptorForType()
        Specified by:
        getDescriptorForType in interface com.google.protobuf.Message.Builder
        Specified by:
        getDescriptorForType in interface com.google.protobuf.MessageOrBuilder
        Overrides:
        getDescriptorForType in class com.google.protobuf.GeneratedMessage.Builder<Cluster.PreconnectPolicy.Builder>

      • getDefaultInstanceForType

        public Cluster.PreconnectPolicy getDefaultInstanceForType()
        Specified by:
        getDefaultInstanceForType in interface com.google.protobuf.MessageLiteOrBuilder
        Specified by:
        getDefaultInstanceForType in interface com.google.protobuf.MessageOrBuilder

      • build

        public Cluster.PreconnectPolicy build()
        Specified by:
        build in interface com.google.protobuf.Message.Builder
        Specified by:
        build in interface com.google.protobuf.MessageLite.Builder

      • buildPartial

        public Cluster.PreconnectPolicy buildPartial()
        Specified by:
        buildPartial in interface com.google.protobuf.Message.Builder
        Specified by:
        buildPartial in interface com.google.protobuf.MessageLite.Builder

      • isInitialized

        public final boolean isInitialized()
        Specified by:
        isInitialized in interface com.google.protobuf.MessageLiteOrBuilder
        Overrides:
        isInitialized in class com.google.protobuf.GeneratedMessage.Builder<Cluster.PreconnectPolicy.Builder>

      • mergeFrom

        public Cluster.PreconnectPolicy.Builder mergeFrom​(com.google.protobuf.CodedInputStream input,
                                                  com.google.protobuf.ExtensionRegistryLite extensionRegistry)
                                           throws java.io.IOException
        Specified by:
        mergeFrom in interface com.google.protobuf.Message.Builder
        Specified by:
        mergeFrom in interface com.google.protobuf.MessageLite.Builder
        Overrides:
        mergeFrom in class com.google.protobuf.AbstractMessage.Builder<Cluster.PreconnectPolicy.Builder>
        Throws:
        java.io.IOException

      • hasPerUpstreamPreconnectRatio

        public boolean hasPerUpstreamPreconnectRatio()
         Indicates how many streams (rounded up) can be anticipated per-upstream for each
 incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting
 will only be done if the upstream is healthy and the cluster has traffic.

 For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be
 established, one for the new incoming stream, and one for a presumed follow-up stream. For
 HTTP/2, only one connection would be established by default as one connection can
 serve both the original and presumed follow-up stream.

 In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100
 active streams, there would be 100 connections in use, and 50 connections preconnected.
 This might be a useful value for something like short lived single-use connections,
 for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection
 termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP
 or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more
 reasonable, where for every 100 connections, 5 preconnected connections would be in the queue
 in case of unexpected disconnects where the connection could not be reused.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight. This means in steady state if a connection is torn down,
 a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection.

 This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can
 harm latency more than the preconnecting helps.
        .google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }
        Specified by:
        hasPerUpstreamPreconnectRatio in interface Cluster.PreconnectPolicyOrBuilder
        Returns:
        Whether the perUpstreamPreconnectRatio field is set.

      • getPerUpstreamPreconnectRatio

        public com.google.protobuf.DoubleValue getPerUpstreamPreconnectRatio()
         Indicates how many streams (rounded up) can be anticipated per-upstream for each
 incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting
 will only be done if the upstream is healthy and the cluster has traffic.

 For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be
 established, one for the new incoming stream, and one for a presumed follow-up stream. For
 HTTP/2, only one connection would be established by default as one connection can
 serve both the original and presumed follow-up stream.

 In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100
 active streams, there would be 100 connections in use, and 50 connections preconnected.
 This might be a useful value for something like short lived single-use connections,
 for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection
 termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP
 or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more
 reasonable, where for every 100 connections, 5 preconnected connections would be in the queue
 in case of unexpected disconnects where the connection could not be reused.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight. This means in steady state if a connection is torn down,
 a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection.

 This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can
 harm latency more than the preconnecting helps.
        .google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }
        Specified by:
        getPerUpstreamPreconnectRatio in interface Cluster.PreconnectPolicyOrBuilder
        Returns:
        The perUpstreamPreconnectRatio.

      • setPerUpstreamPreconnectRatio

        public Cluster.PreconnectPolicy.Builder setPerUpstreamPreconnectRatio​(com.google.protobuf.DoubleValue value)
         Indicates how many streams (rounded up) can be anticipated per-upstream for each
 incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting
 will only be done if the upstream is healthy and the cluster has traffic.

 For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be
 established, one for the new incoming stream, and one for a presumed follow-up stream. For
 HTTP/2, only one connection would be established by default as one connection can
 serve both the original and presumed follow-up stream.

 In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100
 active streams, there would be 100 connections in use, and 50 connections preconnected.
 This might be a useful value for something like short lived single-use connections,
 for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection
 termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP
 or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more
 reasonable, where for every 100 connections, 5 preconnected connections would be in the queue
 in case of unexpected disconnects where the connection could not be reused.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight. This means in steady state if a connection is torn down,
 a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection.

 This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can
 harm latency more than the preconnecting helps.
        .google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }

      • setPerUpstreamPreconnectRatio

        public Cluster.PreconnectPolicy.Builder setPerUpstreamPreconnectRatio​(com.google.protobuf.DoubleValue.Builder builderForValue)
         Indicates how many streams (rounded up) can be anticipated per-upstream for each
 incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting
 will only be done if the upstream is healthy and the cluster has traffic.

 For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be
 established, one for the new incoming stream, and one for a presumed follow-up stream. For
 HTTP/2, only one connection would be established by default as one connection can
 serve both the original and presumed follow-up stream.

 In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100
 active streams, there would be 100 connections in use, and 50 connections preconnected.
 This might be a useful value for something like short lived single-use connections,
 for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection
 termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP
 or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more
 reasonable, where for every 100 connections, 5 preconnected connections would be in the queue
 in case of unexpected disconnects where the connection could not be reused.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight. This means in steady state if a connection is torn down,
 a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection.

 This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can
 harm latency more than the preconnecting helps.
        .google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }

      • mergePerUpstreamPreconnectRatio

        public Cluster.PreconnectPolicy.Builder mergePerUpstreamPreconnectRatio​(com.google.protobuf.DoubleValue value)
         Indicates how many streams (rounded up) can be anticipated per-upstream for each
 incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting
 will only be done if the upstream is healthy and the cluster has traffic.

 For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be
 established, one for the new incoming stream, and one for a presumed follow-up stream. For
 HTTP/2, only one connection would be established by default as one connection can
 serve both the original and presumed follow-up stream.

 In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100
 active streams, there would be 100 connections in use, and 50 connections preconnected.
 This might be a useful value for something like short lived single-use connections,
 for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection
 termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP
 or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more
 reasonable, where for every 100 connections, 5 preconnected connections would be in the queue
 in case of unexpected disconnects where the connection could not be reused.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight. This means in steady state if a connection is torn down,
 a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection.

 This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can
 harm latency more than the preconnecting helps.
        .google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }

      • clearPerUpstreamPreconnectRatio

        public Cluster.PreconnectPolicy.Builder clearPerUpstreamPreconnectRatio()
         Indicates how many streams (rounded up) can be anticipated per-upstream for each
 incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting
 will only be done if the upstream is healthy and the cluster has traffic.

 For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be
 established, one for the new incoming stream, and one for a presumed follow-up stream. For
 HTTP/2, only one connection would be established by default as one connection can
 serve both the original and presumed follow-up stream.

 In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100
 active streams, there would be 100 connections in use, and 50 connections preconnected.
 This might be a useful value for something like short lived single-use connections,
 for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection
 termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP
 or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more
 reasonable, where for every 100 connections, 5 preconnected connections would be in the queue
 in case of unexpected disconnects where the connection could not be reused.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight. This means in steady state if a connection is torn down,
 a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection.

 This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can
 harm latency more than the preconnecting helps.
        .google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }

      • getPerUpstreamPreconnectRatioBuilder

        public com.google.protobuf.DoubleValue.Builder getPerUpstreamPreconnectRatioBuilder()
         Indicates how many streams (rounded up) can be anticipated per-upstream for each
 incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting
 will only be done if the upstream is healthy and the cluster has traffic.

 For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be
 established, one for the new incoming stream, and one for a presumed follow-up stream. For
 HTTP/2, only one connection would be established by default as one connection can
 serve both the original and presumed follow-up stream.

 In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100
 active streams, there would be 100 connections in use, and 50 connections preconnected.
 This might be a useful value for something like short lived single-use connections,
 for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection
 termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP
 or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more
 reasonable, where for every 100 connections, 5 preconnected connections would be in the queue
 in case of unexpected disconnects where the connection could not be reused.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight. This means in steady state if a connection is torn down,
 a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection.

 This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can
 harm latency more than the preconnecting helps.
        .google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }

      • getPerUpstreamPreconnectRatioOrBuilder

        public com.google.protobuf.DoubleValueOrBuilder getPerUpstreamPreconnectRatioOrBuilder()
         Indicates how many streams (rounded up) can be anticipated per-upstream for each
 incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting
 will only be done if the upstream is healthy and the cluster has traffic.

 For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be
 established, one for the new incoming stream, and one for a presumed follow-up stream. For
 HTTP/2, only one connection would be established by default as one connection can
 serve both the original and presumed follow-up stream.

 In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100
 active streams, there would be 100 connections in use, and 50 connections preconnected.
 This might be a useful value for something like short lived single-use connections,
 for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection
 termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP
 or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more
 reasonable, where for every 100 connections, 5 preconnected connections would be in the queue
 in case of unexpected disconnects where the connection could not be reused.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight. This means in steady state if a connection is torn down,
 a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection.

 This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can
 harm latency more than the preconnecting helps.
        .google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }
        Specified by:
        getPerUpstreamPreconnectRatioOrBuilder in interface Cluster.PreconnectPolicyOrBuilder

      • getPerUpstreamPreconnectRatioFieldBuilder

        private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,​com.google.protobuf.DoubleValue.Builder,​com.google.protobuf.DoubleValueOrBuilder> getPerUpstreamPreconnectRatioFieldBuilder()
         Indicates how many streams (rounded up) can be anticipated per-upstream for each
 incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting
 will only be done if the upstream is healthy and the cluster has traffic.

 For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be
 established, one for the new incoming stream, and one for a presumed follow-up stream. For
 HTTP/2, only one connection would be established by default as one connection can
 serve both the original and presumed follow-up stream.

 In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100
 active streams, there would be 100 connections in use, and 50 connections preconnected.
 This might be a useful value for something like short lived single-use connections,
 for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection
 termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP
 or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more
 reasonable, where for every 100 connections, 5 preconnected connections would be in the queue
 in case of unexpected disconnects where the connection could not be reused.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight. This means in steady state if a connection is torn down,
 a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection.

 This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can
 harm latency more than the preconnecting helps.
        .google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }

      • hasPredictivePreconnectRatio

        public boolean hasPredictivePreconnectRatio()
         Indicates how many streams (rounded up) can be anticipated across a cluster for each
 stream, useful for low QPS services. This is currently supported for a subset of
 deterministic non-hash-based load-balancing algorithms (weighted round robin, random).
 Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a
 cluster, doing best effort predictions of what upstream would be picked next and
 pre-establishing a connection.

 Preconnecting will be limited to one preconnect per configured upstream in the cluster and will
 only be done if there are healthy upstreams and the cluster has traffic.

 For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first
 incoming stream, 2 connections will be preconnected - one to the first upstream for this
 cluster, one to the second on the assumption there will be a follow-up stream.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight, so during warm up and in steady state if a connection
 is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for
 connection establishment.

 If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met,
 basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each
 upstream.
        .google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }
        Specified by:
        hasPredictivePreconnectRatio in interface Cluster.PreconnectPolicyOrBuilder
        Returns:
        Whether the predictivePreconnectRatio field is set.

      • getPredictivePreconnectRatio

        public com.google.protobuf.DoubleValue getPredictivePreconnectRatio()
         Indicates how many streams (rounded up) can be anticipated across a cluster for each
 stream, useful for low QPS services. This is currently supported for a subset of
 deterministic non-hash-based load-balancing algorithms (weighted round robin, random).
 Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a
 cluster, doing best effort predictions of what upstream would be picked next and
 pre-establishing a connection.

 Preconnecting will be limited to one preconnect per configured upstream in the cluster and will
 only be done if there are healthy upstreams and the cluster has traffic.

 For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first
 incoming stream, 2 connections will be preconnected - one to the first upstream for this
 cluster, one to the second on the assumption there will be a follow-up stream.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight, so during warm up and in steady state if a connection
 is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for
 connection establishment.

 If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met,
 basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each
 upstream.
        .google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }
        Specified by:
        getPredictivePreconnectRatio in interface Cluster.PreconnectPolicyOrBuilder
        Returns:
        The predictivePreconnectRatio.

      • setPredictivePreconnectRatio

        public Cluster.PreconnectPolicy.Builder setPredictivePreconnectRatio​(com.google.protobuf.DoubleValue value)
         Indicates how many streams (rounded up) can be anticipated across a cluster for each
 stream, useful for low QPS services. This is currently supported for a subset of
 deterministic non-hash-based load-balancing algorithms (weighted round robin, random).
 Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a
 cluster, doing best effort predictions of what upstream would be picked next and
 pre-establishing a connection.

 Preconnecting will be limited to one preconnect per configured upstream in the cluster and will
 only be done if there are healthy upstreams and the cluster has traffic.

 For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first
 incoming stream, 2 connections will be preconnected - one to the first upstream for this
 cluster, one to the second on the assumption there will be a follow-up stream.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight, so during warm up and in steady state if a connection
 is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for
 connection establishment.

 If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met,
 basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each
 upstream.
        .google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }

      • setPredictivePreconnectRatio

        public Cluster.PreconnectPolicy.Builder setPredictivePreconnectRatio​(com.google.protobuf.DoubleValue.Builder builderForValue)
         Indicates how many streams (rounded up) can be anticipated across a cluster for each
 stream, useful for low QPS services. This is currently supported for a subset of
 deterministic non-hash-based load-balancing algorithms (weighted round robin, random).
 Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a
 cluster, doing best effort predictions of what upstream would be picked next and
 pre-establishing a connection.

 Preconnecting will be limited to one preconnect per configured upstream in the cluster and will
 only be done if there are healthy upstreams and the cluster has traffic.

 For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first
 incoming stream, 2 connections will be preconnected - one to the first upstream for this
 cluster, one to the second on the assumption there will be a follow-up stream.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight, so during warm up and in steady state if a connection
 is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for
 connection establishment.

 If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met,
 basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each
 upstream.
        .google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }

      • mergePredictivePreconnectRatio

        public Cluster.PreconnectPolicy.Builder mergePredictivePreconnectRatio​(com.google.protobuf.DoubleValue value)
         Indicates how many streams (rounded up) can be anticipated across a cluster for each
 stream, useful for low QPS services. This is currently supported for a subset of
 deterministic non-hash-based load-balancing algorithms (weighted round robin, random).
 Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a
 cluster, doing best effort predictions of what upstream would be picked next and
 pre-establishing a connection.

 Preconnecting will be limited to one preconnect per configured upstream in the cluster and will
 only be done if there are healthy upstreams and the cluster has traffic.

 For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first
 incoming stream, 2 connections will be preconnected - one to the first upstream for this
 cluster, one to the second on the assumption there will be a follow-up stream.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight, so during warm up and in steady state if a connection
 is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for
 connection establishment.

 If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met,
 basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each
 upstream.
        .google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }

      • clearPredictivePreconnectRatio

        public Cluster.PreconnectPolicy.Builder clearPredictivePreconnectRatio()
         Indicates how many streams (rounded up) can be anticipated across a cluster for each
 stream, useful for low QPS services. This is currently supported for a subset of
 deterministic non-hash-based load-balancing algorithms (weighted round robin, random).
 Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a
 cluster, doing best effort predictions of what upstream would be picked next and
 pre-establishing a connection.

 Preconnecting will be limited to one preconnect per configured upstream in the cluster and will
 only be done if there are healthy upstreams and the cluster has traffic.

 For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first
 incoming stream, 2 connections will be preconnected - one to the first upstream for this
 cluster, one to the second on the assumption there will be a follow-up stream.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight, so during warm up and in steady state if a connection
 is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for
 connection establishment.

 If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met,
 basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each
 upstream.
        .google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }

      • getPredictivePreconnectRatioBuilder

        public com.google.protobuf.DoubleValue.Builder getPredictivePreconnectRatioBuilder()
         Indicates how many streams (rounded up) can be anticipated across a cluster for each
 stream, useful for low QPS services. This is currently supported for a subset of
 deterministic non-hash-based load-balancing algorithms (weighted round robin, random).
 Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a
 cluster, doing best effort predictions of what upstream would be picked next and
 pre-establishing a connection.

 Preconnecting will be limited to one preconnect per configured upstream in the cluster and will
 only be done if there are healthy upstreams and the cluster has traffic.

 For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first
 incoming stream, 2 connections will be preconnected - one to the first upstream for this
 cluster, one to the second on the assumption there will be a follow-up stream.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight, so during warm up and in steady state if a connection
 is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for
 connection establishment.

 If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met,
 basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each
 upstream.
        .google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }

      • getPredictivePreconnectRatioOrBuilder

        public com.google.protobuf.DoubleValueOrBuilder getPredictivePreconnectRatioOrBuilder()
         Indicates how many streams (rounded up) can be anticipated across a cluster for each
 stream, useful for low QPS services. This is currently supported for a subset of
 deterministic non-hash-based load-balancing algorithms (weighted round robin, random).
 Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a
 cluster, doing best effort predictions of what upstream would be picked next and
 pre-establishing a connection.

 Preconnecting will be limited to one preconnect per configured upstream in the cluster and will
 only be done if there are healthy upstreams and the cluster has traffic.

 For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first
 incoming stream, 2 connections will be preconnected - one to the first upstream for this
 cluster, one to the second on the assumption there will be a follow-up stream.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight, so during warm up and in steady state if a connection
 is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for
 connection establishment.

 If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met,
 basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each
 upstream.
        .google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }
        Specified by:
        getPredictivePreconnectRatioOrBuilder in interface Cluster.PreconnectPolicyOrBuilder

      • getPredictivePreconnectRatioFieldBuilder

        private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,​com.google.protobuf.DoubleValue.Builder,​com.google.protobuf.DoubleValueOrBuilder> getPredictivePreconnectRatioFieldBuilder()
         Indicates how many streams (rounded up) can be anticipated across a cluster for each
 stream, useful for low QPS services. This is currently supported for a subset of
 deterministic non-hash-based load-balancing algorithms (weighted round robin, random).
 Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a
 cluster, doing best effort predictions of what upstream would be picked next and
 pre-establishing a connection.

 Preconnecting will be limited to one preconnect per configured upstream in the cluster and will
 only be done if there are healthy upstreams and the cluster has traffic.

 For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first
 incoming stream, 2 connections will be preconnected - one to the first upstream for this
 cluster, one to the second on the assumption there will be a follow-up stream.

 If this value is not set, or set explicitly to one, Envoy will fetch as many connections
 as needed to serve streams in flight, so during warm up and in steady state if a connection
 is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for
 connection establishment.

 If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met,
 basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each
 upstream.
        .google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }