Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Presence of Single Consumer is forcing other producers exposed under output-bindings property to be treated as BindableFunctionProxyFactory bean with "functionExist" parameter set to TRUE, even when Streambridge is used instead of Supplier #3034

Open
Saumrit opened this issue Nov 7, 2024 · 0 comments

Comments

@Saumrit
Copy link

Saumrit commented Nov 7, 2024

In one of the microservice , i am having one Producer, for which StreamBridge is used instead of Supplier and a consumer which is backed up by Consumer Functional interface. Because of the presence of only one consumer , i see the producer which is exposed under spring.cloud.stream.output-bindings application property , is registered as BindableFunctionProxyFactory bean with "functionExist" parameter set to TRUE . [While debugging i see normalizeFunctionDefinition() from org.springframework.cloud.function.context.catalog.SimpleFunctionRegistry is doing this explicitely when only one consumer is pressent]

  • I was expecting this to be false since there is no Supplier backing it up for my producer. Now i am confused if its a BUG or any purpose is there behind it .
  • What to do so that "functionExist" will set to FALSE for the producer in my case since i have only one consumer backed UP by Consumer interface and exposed under spring.cloud.function.definition property.
  • Please let me know if in this scenario i should avoid output-bindings property.
  • And what is the real use of output-bindings apart from pre-creating the bindings ? Is it mandatory to use when i go with Streambridge?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant