Closes gh-51666
* gh-51666:
Polish "Use TLS port for Docker Compose RabbitMQ connection when SSL is configured"
Use TLS port for Docker Compose RabbitMQ connection when SSL is configured
When a rabbitmq Docker Compose service has SSL bundle labels,
RabbitDockerComposeConnectionDetailsFactory created an SslBundle but
still resolved the address from container port 5672, the plain AMQP
listener. As the connection factory enables SSL when an SslBundle is
present, the TLS handshake was attempted against the non-TLS listener
and the connection failed.
The address is now resolved from container port 5671 when an SslBundle
is present, matching RabbitStreamDockerComposeConnectionDetailsFactory
and the Testcontainers-based RabbitContainerConnectionDetailsFactory.
The SSL integration test now opens a connection using the resolved
address and SslBundle so that it fails without this fix.
Signed-off-by: ohchanKyu <okc0202@naver.com>
See gh-51666
With OpenTelemetry, fields listed in management.tracing.baggage.tag-fields
only became span tags when the application itself touched the baggage
through the Tracer API. Baggage that arrived with a request was
propagated correctly, but spans were not tagged with it (see
micrometer-metrics/tracing#933).
This commit registers Micrometer Tracing's BaggageTaggingSpanProcessor
whenever baggage is enabled and at least one tag field is configured, so
that spans are tagged with the baggage that is present in their parent
context. A custom BaggageTaggingSpanProcessor bean backs off the
auto-configured one. The tag-fields property is now also mentioned in
the baggage section of the tracing documentation.
See gh-51656
Signed-off-by: Oleksandr Shevchenko <oleksandr.shevchenko@datarobot.com>
Changelog.computeDifferences() called
ConfigurationMetadataRepository.getAllProperties() from inside its main
loop. The default repository implementation builds a new map each time
that method is called, so the new version's properties were rebuilt once
per property of the old version. The ids that had already been seen were
also tracked in an ArrayList, turning each membership check into a linear
scan.
Read the properties of each repository once and use the old properties
map itself to detect the properties that have been added.
Computing the changelog between Spring Boot 3.4.0 and 3.5.0 (2,498 and
2,555 properties) drops from 203ms to 0.5ms and the generator's peak
memory from 302MB to 91MB. The generated asciidoc is byte for byte
identical.
See gh-51655
Signed-off-by: Junggi Kim <kimjg2477@gmail.com>
Baggage is already propagated over gRPC by the auto-configured
Micrometer observation interceptors: on the server side the
ObservationGrpcServerInterceptor hands the incoming metadata to the
tracing observation handlers, which extract the W3C baggage header as
well as the individual metadata keys listed in
management.tracing.baggage.remote-fields, and on the client side the
ObservationGrpcClientInterceptor writes them to the metadata of
outgoing calls. This was not documented, and it is easy to miss that
it requires micrometer-core on the classpath.
This commit adds an Observability section to the gRPC server
documentation, extends the gRPC client Observability section, and
mentions gRPC in the baggage section of the tracing documentation.
See gh-51597
Signed-off-by: Oleksandr Shevchenko <oleksandr.shevchenko@datarobot.com>
LayersIndex.Node kept its children in a list and scanned that list
linearly to find the child for each path segment. Building the index is
therefore O(entries x siblings), a cost that is dominated by the largest
flat directory in the jar: BOOT-INF/lib/ for the dependencies, and any
bundled resource directory such as a front-end build output.
Keep the children in a LinkedHashMap keyed by the segment name so that
lookups are constant time. Insertion order is preserved, so the order in
which buildIndex() walks the tree is unchanged.
For a jar with 32,529 entries, 426 dependencies and a 12,000 file static
resource directory, this reduces the number of string comparisons from
73.7M to 222K and the time spent building the index from 197ms to 12ms.
For a jar with no large flat directory (20,529 entries, 426
dependencies) the gain is much smaller: 1.58M comparisons to 162K, and
12.5ms to 9.6ms. The generated layers.idx is byte for byte identical in
both cases.
See gh-51654
Signed-off-by: Junggi Kim <kimjg2477@gmail.com>
IndexedLayers.getLayer() walked every entry of layers.idx for each jar
entry being extracted, making extraction O(entries x index size). The
dependency entries are listed first while the application classes are
covered by a single directory entry near the end, so the most numerous
entries consistently scanned the longest.
Index the candidates once when the index file is read, keeping the
directory candidates in a separate map that preserves index order. A
file name is then resolved with a single map lookup and only the
handful of directory candidates has to be scanned.
For a jar with 24,823 entries and 700 dependencies this reduces the
number of string comparisons from 17,179,582 to 72,946 (106.9ms to
2.5ms). With 4,173 entries it goes from 1,019,857 to 11,896 (5.4ms to
0.1ms) and with 903 entries from 70,612 to 2,426 (0.8ms to 0.1ms).
Lookups resolve to the same layer as before. LayersIndex only writes a
name once its whole subtree belongs to a single layer, so no indexed
name is a prefix of another and at most one candidate can match, which
makes the order the two kinds of candidate are consulted in immaterial.
See gh-51653
Signed-off-by: Junggi Kim <kimjg2477@gmail.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Stéphane Nicoll
Andy Wilkinson
Wan bin yu
ohchanKyu
Oleksandr Shevchenko
Tran Ngoc Nhan
Junggi Kim
