Related to: https://github.com/spring-projects/spring-integration/issues/9362
After the fix in Spring Integration: bdcb856a90
we ended up in a deadlock situation with a `beginPublishingTrigger` in the `FunctionConfiguration`
used for the `delaySubscription()` on an original `Publisher`.
The `FluxMessageChannel` uses its own `delaySubscription()` until the channel has its subscribers.
Apparently the logic before was with errors, so the `FluxMessageChannel` was marked as active
even if its subscriber is not ready yet, leading to famous `Dispatcher does not have subscribers` error.
So, looks like this `beginPublishingTrigger` was introduced back in days in Spring Cloud Stream
to mitigate that situation until we really emit a `BindingCreatedEvent`.
The deadlock (and the flaw, respectively) is with the `setupBindingTrigger()` method implementation
where `FluxMessageChannel` now "really" delays a subscription to the provided `Publisher`,
therefore not triggering that `Mono.create()` fulfilment immediately.
The `BindingCreatedEvent` arrives earlier, than we have a subscriber on the channel,
but `triggerRef.get()` is `null`, so we don't `success()` it and in the end don't subscribe
to an original `Publisher` since `delaySubscription()` on it is never completed.
Since `FunctionConfiguration` fully relies on `IntegrationFlow.from(Publisher)`,
which ends up with the mentioned `FluxMessageChannel.subscribeTo()` and its own `delaySubscription()`
(which, in turn, apparently fixed now), we don't need our own `delaySubscription()` any more.
Therefore the fix in this PR is to propose to remove `beginPublishingTrigger` logic altogether.
- When concurrent threads publish to a binding, PartitionAwareFunctionWrapper
resets to null between invocations. Addressing this issue by guarding this reset
from occurring if the partiton header on the producer is found.
Fixes https://github.com/spring-cloud/spring-cloud-stream/issues/2961
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2932
Spring Boot provides `SanitizingFunction` to allow the applicaitons to clear out
sensitive data when using certain actuator endpoints. This feature can be
extended to custom endpoints as well. Enable the bindings actuator endpoint
to sanitze sensitive data based on user-provided logic in `SantizingFuction`
beans in the application.
* When output-bindings config is explicitly used for StreamBridge
and the RabbitMQ routing-key-expression is provided, Spring Cloud Stream
is throwing an exception due to a proper function is not found in
the catalog. Bypassing this step and letting the bootstrapping continues
if output-bindings and RabbitMQ routing-key-expression combination is used.
* Adding tests to verify
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2921
Fixes: #2901
* Rework an observation for Rabbit Binder
The observation propagation doesn't work in multi-binder configuration
* Remove `ObservationAutoConfiguration` since it is not visible in case of multi-binder configuration
* Instead move `setObservationEnabled` flag setting to the `RabbitMessageChannelBinder`
* Add `io.micrometer.observation.ObservationRegistry` into `shared.beans` to make it visible for binder-specific application context
* Add `RabbitMultiBinderObservationTests` integration test where Rabbit Binder is in a multi-binder environment
As a side effect, this fixes an observation propagation for the Kafka binder as well in the multi-binder environment.
Its configuration is OK, but an `ObservationRegistry` must make it visible for the binder-specific application context.
See the mentioned `shared. beans`
Related to https://github.com/spring-cloud/spring-cloud-stream/issues/2901
Also see https://github.com/spring-cloud/spring-cloud-stream/issues/2902 for possible evolution
* Update the copyright of the affected classes
Remove also a duplicated code from the `setAsync()`
which, essentially, may lead to the problem with class loader when `context-propagation` is optional on classpath
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2883
When an applicaiton provides a custom errorChannel bean that is not of type
`PublishSubscribeChannel`, the application fails to start with a CCE. This is
because `BindingServiceConfiguration` uses a hard cast on `PublishSubscribeChannel`
without pre-checking the channel type. Fixing this issue.
Fixes https://github.com/spring-cloud/spring-cloud-stream/issues/2885
The `DirectWithAttributesChannel` used by `StreamBridge` is missing naming
information. Adding the proper application context and component name data
to the channel so that it is able to construct a name when queried.
The expectation is like this `Binder<T, C extends ConsumerProperties, P extends ProducerProperties>`
so, the `BinderCustomizer` must be in extension bounds as well.
* Move Javadocs from the `BinderCustomizer.customize()` to the class level
* Add `BinderCustomizer` verification to the `KafkaConfigCustomizationTests`
Fixes https://github.com/spring-cloud/spring-cloud-stream/issues/2794
The custom ObjectMapper used in AMCB is unable to serialize java.time.Duration
values. To fix this, the ObjectMapper needs to register the JavaTimeModule from
the jackson-datatype-jsr310 libarary.
Adding a test to verify the fix.
- When closing multi-binder contexts, the application throws a StackOverflow error
due to an unnecessary addition of the binder child context as a separate bean
in the main context. This was done previously for testing purposes.
- Disabling the affected tests in the Pulsar binder until we come up with a
different solution.
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2870
- When there are multiple output bindings present and one of them defines
a routing-key-expression, there is a bug that bypasses the code that skips
the output conversion. This results in the framework attempts a pre-mature
type conversion causing in later downstream errors. This happens because
MessageConverterConfigurer tries to find a corresponding function for the
entire function definition rather than using the individual function under
consideraion. Fixing this issue by properly keeping track of the function
name keyed off of the channel name, since channel name is what
MessageConverterConfigurer uses to retrieve info about the function name.
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2847
