0

I'm pretty sure I'm missing something basic here:

I have created a flow using this topology:

A | B | C

This is the application.properties of A:

spring.cloud.stream.bindings.requestChannel.destination=events-exchange

This is the application.properties of B:

spring.cloud.stream.bindings.input.destination=events-exchange

C is an OOTB log sink app.

With this setup, A | B is fine but C is not getting any logs. Although, B is delivering the message to the correct exchange, the link from B | C is disjoint.

Please note that I have not supplied the above properties during deploy time. They are static application.properties within the jar.

How should I let SCDF to join the apps correctly? What's the best practice/recommended approach around this? We have many apps that needs to be joined using the Rabbit Middleware and looking for a simpler, less error-prone approach. Thanks.

user1189332
  • 1,773
  • 4
  • 26
  • 46
  • Hi, What are your binding destination for B's `outbound` and C's `inbound`. Given, C is OOTB log app, does log's `spring.cloud.stream.bindings.input.destination` point to the same `exchange` that B's output (configured via `spring.cloud.stream.bindings..destination` is bound to? – Ilayaperumal Gopinathan Jul 21 '17 at 15:23
  • B's outbound is: `spring.cloud.stream.bindings.output.destination=work.out` – user1189332 Jul 21 '17 at 15:26
  • Does C have `spring.cloud.stream.bindings.input.destination=work.out`? – Ilayaperumal Gopinathan Jul 21 '17 at 15:29
  • B's outbound is: `spring.cloud.stream.bindings.output.destination=work.out` I haven't supplied any deploy-time properties for 'C'. As a side note, if I don't supply any of these, does SCDF automatically joins them based on streamName_appName convention? Supplying too many properties (or a props file per se) which defines the sequence somewhat feels difficult to track although the DSL reads A | B| C . What is the best practice here? – user1189332 Jul 21 '17 at 15:32

1 Answers1

0

If you set the output of B to work.out, then you'd need to override the input of C as well. What Spring Cloud Data Flow does is to set both the input and the output of adjacent apps to a common value (derived from the stream/app name). If you are overriding one of them, apps become disconnected as you have noticed. While we do intend to support overriding intermediate destinations in a better way in the future, A | B | C relies on relinqushing control of the binding of input/output to Spring Cloud Data Flow (you can override that, but as you noticed, you need to be explicit on both ends). As an alternative to renaming destinations mid-stream, you can use named destinations: http://docs.spring.io/spring-cloud-dataflow/docs/current/reference/html/spring-cloud-dataflow-stream-explicit-destination-names.html .

Marius Bogoevici
  • 2,380
  • 1
  • 13
  • 14