Retry not executing code #1083
Comments
|
Since we don't have something like: in the wrong flow I only can assume that the target Does it make sense to you? Maybe you can indeed debug your app when you have that |
|
I tried using application/json and it has the same effect, sometimes it works, sometimes it doesn't. |
|
Ah, this one! Would you mind sharing more stack trace for that The issue seems for me obsolete, but looks like we still may have some race condition when we have already started OK, let's don't speculate! Show, please, more stack trace and we'll see. |
|
It is easy to reproduce: https://github.com/JMesens/asyncHttp |
|
OK. Look. You have this: And seems for me you confuse the Spring Cloud Stream binding functionality with the same Since we fail to send via Feign we get an exception on the So, to fix your problem, consider to distinguish Producer and Consumer to different application or use different names for the Meanwhile I think this is definitely bug and |
|
Well, after closer look, we indeed have to reject such a configuration because we can't register several beans for the same name. There might be something like @viniciusccarvalho , WDYT? |
|
I think the confusion is how we communicate the fact that the value of the annotation is really the bean name not the destination, and then we use it as default for the destination. We should revisit this on 2.0 for sure, the fix now is simple just use a different name for the channels and use For 2.0 there's a new wrapper type called |
|
Good. Thank you for confirmation! So, independently of the fact for the new |
|
@artembilan Thank you for handling this issue so thorough, it was very helpful. I implemented the bindings work-around and it works. (more info: https://github.com/JMesens/asyncHttp/commit/e8e5f4bb4536caaf7b60e8423bd32742aece5319) |
Resolves spring-cloud#1083 By default Spring Framework allows beans overriding via the same name. The binding target definitions (`@Input` and `@Output`) populate beans as well and when we use the same name for target we end up with unexpected behavior but without errors. Since it isn't so obvious via Spring Framework bean definition DSLs (XML or Java & Annotations) how to override beans with the same name, that is absolutely easy to use the same value for `@Input` and `@Output` definitions even in different binding interfaces. That's hard to analyze fro the target application since mostly `@Input` and `@Output` produce `MessageChannel` beans. * Fail fast with the `BeanDefinitionStoreException` when we meet existing bean definition for the same name * Add JavaDocs to the `@Input` and `@Output` to explain that their `value` is a bean name, as well as destination by default Since `@EnableBinding` is `@Inherited`, the inheritor picks up it from the super class during configuration class parsing. The parsing process logic is such that after the root class we go to parse its super classes, and therefore come back to the `@EnableBinding` again. In this case we process all the `@Import`s one more time and collect them to the root `configurationClass`. Essentially we get a duplication for the `ImportBeanDefinitionRegistrar`s such as `BindingBeansRegistrar`. The last one parsed `@EnableBinding` and registers appropriate beans for the `@Input` and `@Output`, as well as for the binding interface - `BindableProxyFactory`. But since we have it twice in the `configurationClass` we end up with `BeanDefinitionStoreException` mentioned before. That's how Spring Framework works with inheritance for configuration classes and that's may be why it allows to override beans by default * Skip parsing `@EnableBinding` one more time if the bean definition for binding interface is already present in the `registry` * Fix `AggregateWithMainTest` do not process `@ComponentScan` what causes picking up the configuration classes for children contexts in the aggregation * Fix `testBindableProxyFactoryCaching()` do not register `Source` and `Processor` in the same application context because both of them cause registration for the `Source.OUTPUT` bean
Resolves spring-cloud#1083 By default Spring Framework allows beans overriding via the same name. The binding target definitions (`@Input` and `@Output`) populate beans as well and when we use the same name for target we end up with unexpected behavior but without errors. Since it isn't so obvious via Spring Framework bean definition DSLs (XML or Java & Annotations) how to override beans with the same name, that is absolutely easy to use the same value for `@Input` and `@Output` definitions even in different binding interfaces. That's hard to analyze fro the target application since mostly `@Input` and `@Output` produce `MessageChannel` beans. * Fail fast with the `BeanDefinitionStoreException` when we meet existing bean definition for the same name * Add JavaDocs to the `@Input` and `@Output` to explain that their `value` is a bean name, as well as destination by default Since `@EnableBinding` is `@Inherited`, the inheritor picks up it from the super class during configuration class parsing. The parsing process logic is such that after the root class we go to parse its super classes, and therefore come back to the `@EnableBinding` again. In this case we process all the `@Import`s one more time and collect them to the root `configurationClass`. Essentially we get a duplication for the `ImportBeanDefinitionRegistrar`s such as `BindingBeansRegistrar`. The last one parsed `@EnableBinding` and registers appropriate beans for the `@Input` and `@Output`, as well as for the binding interface - `BindableProxyFactory`. But since we have it twice in the `configurationClass` we end up with `BeanDefinitionStoreException` mentioned before. That's how Spring Framework works with inheritance for configuration classes and that's may be why it allows to override beans by default * Skip parsing `@EnableBinding` one more time if the bean definition for binding interface is already present in the `registry` * Fix `AggregateWithMainTest` do not process `@ComponentScan` what causes picking up the configuration classes for children contexts in the aggregation * Fix `testBindableProxyFactoryCaching()` do not register `Source` and `Processor` in the same application context because both of them cause registration for the `Source.OUTPUT` bean Conflicts: spring-cloud-stream/src/test/java/org/springframework/cloud/stream/aggregation/AggregationTest.java
Resolves spring-cloud#1083 By default Spring Framework allows beans overriding via the same name. The binding target definitions (`@Input` and `@Output`) populate beans as well and when we use the same name for target we end up with unexpected behavior but without errors. Since it isn't so obvious via Spring Framework bean definition DSLs (XML or Java & Annotations) how to override beans with the same name, that is absolutely easy to use the same value for `@Input` and `@Output` definitions even in different binding interfaces. That's hard to analyze fro the target application since mostly `@Input` and `@Output` produce `MessageChannel` beans. * Fail fast with the `BeanDefinitionStoreException` when we meet existing bean definition for the same name * Add JavaDocs to the `@Input` and `@Output` to explain that their `value` is a bean name, as well as destination by default Since `@EnableBinding` is `@Inherited`, the inheritor picks up it from the super class during configuration class parsing. The parsing process logic is such that after the root class we go to parse its super classes, and therefore come back to the `@EnableBinding` again. In this case we process all the `@Import`s one more time and collect them to the root `configurationClass`. Essentially we get a duplication for the `ImportBeanDefinitionRegistrar`s such as `BindingBeansRegistrar`. The last one parsed `@EnableBinding` and registers appropriate beans for the `@Input` and `@Output`, as well as for the binding interface - `BindableProxyFactory`. But since we have it twice in the `configurationClass` we end up with `BeanDefinitionStoreException` mentioned before. That's how Spring Framework works with inheritance for configuration classes and that's may be why it allows to override beans by default * Skip parsing `@EnableBinding` one more time if the bean definition for binding interface is already present in the `registry` * Fix `AggregateWithMainTest` do not process `@ComponentScan` what causes picking up the configuration classes for children contexts in the aggregation * Fix `testBindableProxyFactoryCaching()` do not register `Source` and `Processor` in the same application context because both of them cause registration for the `Source.OUTPUT` bean Conflicts: spring-cloud-stream/src/test/java/org/springframework/cloud/stream/aggregation/AggregationTest.java
I have run into a problem with the RetryTemplate. I'm building a client for jira (issue tracking) with feign and spring cloud stream. The issues that need to produced are send to the component over http, then the component enqueues the issues (buffering, our on premise jira is very unstable) on a queue using Spring Cloud Stream (Chelsea.SR2) and RabbitMQ binder. The same component also listens to the queue for sending the issues further to jira using feign.
But the problem is that Spring Cloud Stream not always does the retry correctly. (Yes, sometimes it works, not always..) In the wrong flow you can see JiraClient isn't invoked. (Yes we have multiple retries, jira client does retry 5 times, the message should retry for a long time, int max)
Expected flow:
Wrong flow:
Code:
Configuration:
The text was updated successfully, but these errors were encountered: