Class Cluster.PreconnectPolicy.Builder

java.lang.Object
com.google.protobuf.AbstractMessageLite.Builder
com.google.protobuf.AbstractMessage.Builder<Cluster.PreconnectPolicy.Builder>
com.google.protobuf.GeneratedMessage.Builder<Cluster.PreconnectPolicy.Builder>
io.envoyproxy.envoy.config.cluster.v3.Cluster.PreconnectPolicy.Builder
All Implemented Interfaces:
com.google.protobuf.Message.Builder, com.google.protobuf.MessageLite.Builder, com.google.protobuf.MessageLiteOrBuilder, com.google.protobuf.MessageOrBuilder, Cluster.PreconnectPolicyOrBuilder, Cloneable
Enclosing class:
Cluster.PreconnectPolicy

public static final class Cluster.PreconnectPolicy.Builder extends com.google.protobuf.GeneratedMessage.Builder<Cluster.PreconnectPolicy.Builder> implements Cluster.PreconnectPolicyOrBuilder
Protobuf type envoy.config.cluster.v3.Cluster.PreconnectPolicy
  • Field Details

    • 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 Details

    • Builder

      private Builder()
    • Builder

      private Builder(com.google.protobuf.AbstractMessage.BuilderParent parent)
  • Method Details

    • 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()
    • clear

      Specified by:
      clear in interface com.google.protobuf.Message.Builder
      Specified by:
      clear in interface com.google.protobuf.MessageLite.Builder
      Overrides:
      clear in class com.google.protobuf.GeneratedMessage.Builder<Cluster.PreconnectPolicy.Builder>
    • 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
    • buildPartial0

      private void buildPartial0(Cluster.PreconnectPolicy result)
    • mergeFrom

      public Cluster.PreconnectPolicy.Builder mergeFrom(com.google.protobuf.Message other)
      Specified by:
      mergeFrom in interface com.google.protobuf.Message.Builder
      Overrides:
      mergeFrom in class com.google.protobuf.AbstractMessage.Builder<Cluster.PreconnectPolicy.Builder>
    • mergeFrom

    • 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 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:
      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
    • internalGetPerUpstreamPreconnectRatioFieldBuilder

      private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,com.google.protobuf.DoubleValue.Builder,com.google.protobuf.DoubleValueOrBuilder> internalGetPerUpstreamPreconnectRatioFieldBuilder()
       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
    • internalGetPredictivePreconnectRatioFieldBuilder

      private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,com.google.protobuf.DoubleValue.Builder,com.google.protobuf.DoubleValueOrBuilder> internalGetPredictivePreconnectRatioFieldBuilder()
       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) = { ... }