@Scheduled method invoked both on original bean and @Alternative bean #24212
Comments
|
/cc @mkouba |
|
Note that However, in your particular case I'd say that only the scheduled method declared on @machi1990 @manovotn I think that we should clarify the inheritance rules for @aluckenbaugh In your case I'd recommend to separate the logic that should be executed (and can be overriden) and the scheduled method itself (here the @ApplicationScoped
public class ScheduledBean {
@Inject
Logic logic;
@Scheduled(every = "10s")
void execute() {
logic.execute();
}
}
@ApplicationScoped
class Logic {
void execute() {
// do something
}
}
@Alternative
@ApplicationScoped
class AlternativeLogic extends Logic {
void execute() {
// do something
}
}You can also consider using the default beans: @DefaultBean
@ApplicationScoped
class Logic {
void execute() {
// do something
}
}
@ApplicationScoped
class AlternativeLogic extends Logic {
void execute() {
// do something
}
} |
|
Thank you for your response, @mkouba. Your recommendation for separating the logic and the scheduling in different beans provides us with a usable pattern.
Would this mean that the behavior of the Quarkus scheduler needs to change? At the moment in the code example I provided both the This behavior seems to cause a problem if an identity is specified in the scheduled annotation on the In that case with the Error:
If I don't use the explicitly defined
Is this its intended behavior? |
Yes, and given the fact that scheduled methods with identity may cause troubles we'll need to think about this and find some acceptable solution. TBH we did not think a lot about |
|
FTR the "inheritance" for |
|
Hm, I think that It would be a breaking change but I'm +1 since the current behavior does not make a lot of sense. AFAIK it's an undocumented feature anyway. |
+1 on having consistent behavior that can be clearly documented. So I am in favor of making the public interface ICounterBean {
@Scheduled(identity="the idenitity")
void increment()
}
public class CounterBean implements ICounterBean {
@Override
void increment() {
// actual implementation
}
} |
Hm, this is not supported ATM and to be honest, I don't see any benefit in this pattern... |
Thanks, I wrote the snippet with a vague recollection of it being supported but I was wrong. |
- this is a breaking change - however, the current behavior is undocumented and inconsistent; e.g. if Scheduled#identity() is used then the build always fails - also the scope annotation is not added automatically to a subclass of a class that declares a Scheduled annotation, i.e. the class would be ignored and would result in runtime error - resolves quarkusio#24212
- this is a breaking change - however, the current behavior is undocumented and inconsistent; e.g. if Scheduled#identity() is used then the build always fails - also the scope annotation is not added automatically to a subclass of a class that declares a Scheduled annotation, i.e. the class would be ignored and would result in runtime error - resolves quarkusio#24212
- this is a breaking change - however, the current behavior is undocumented and inconsistent; e.g. if Scheduled#identity() is used then the build always fails - also the scope annotation is not added automatically to a subclass of a class that declares a Scheduled annotation, i.e. the class would be ignored and would result in runtime error - resolves quarkusio#24212
Describe the bug
If
@Scheduledis applied to a function and an@Alternativesubclass is created for the bean containing the annotated method, the method is invoked twice by the scheduler, once for each bean. This means that when the alternative bean is being used the scheduled method is invoked twice, which is unexpected.A reproducer is attached with the minimal changes necessary to show this, applied on the scheduler-quickstart project.
Our use case is we are creating a bean like
CounterBeanin the attached example that lives inside a library. ThisCounterBeancould be subclassed and customized by providing an alternative likeAlternativeCounterBeanin different projects that use the library, and if that is done at the moment we find multiple invocations of the scheduled method, one immediately after the other.Expected behavior
Only one invocation of the
@Scheduledmethod should be performed on the alternative bean; the original bean's invocation should not be performed. In the given example, onlyAlternativeCounterBean#increment()should be invoked by the scheduler.Actual behavior
As can be seen in the log output, both the
CounterBean#increment()and theAlternativeCounterBean#increment()are invoked by the scheduler.How to Reproduce?
scheduler-quickstart-reproducer.zip
Output of
uname -aorverMicrosoft Windows [Version 10.0.19042.1526]
Output of
java -versionopenjdk version "11.0.9.1" 2020-11-04 LTS OpenJDK Runtime Environment Corretto-11.0.9.12.1 (build 11.0.9.1+12-LTS) OpenJDK 64-Bit Server VM Corretto-11.0.9.12.1 (build 11.0.9.1+12-LTS, mixed mode)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.7.3.Final
Build tool (ie. output of
mvnw --versionorgradlew --version)Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Maven home: C:\ProgramData\Chocolatey\lib\maven\apache-maven-3.8.4 Java version: 11.0.9.1, vendor: Amazon.com Inc., runtime: C:\Program Files\Amazon Corretto\jdk11.0.9_12 Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Additional information
No response
The text was updated successfully, but these errors were encountered: