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

Two @Incoming via smallrye-reactive-messaging causes build errors. #19562

Closed
navkast opened this issue Aug 21, 2021 · 3 comments · Fixed by #19565
Closed

Two @Incoming via smallrye-reactive-messaging causes build errors. #19562

navkast opened this issue Aug 21, 2021 · 3 comments · Fixed by #19565
Assignees
Milestone

Comments

@navkast
Copy link

navkast commented Aug 21, 2021

Describe the bug

I'm trying this experimental feature: https://smallrye.io/smallrye-reactive-messaging/smallrye-reactive-messaging/2/advanced/incomings.html using the smallrye-kafka connector.

I consistently get this failure when building the application:

[ERROR] Failed to execute goal io.quarkus:quarkus-maven-plugin:2.1.3.Final:build (default) on project smallrye-kafka-multiple-incomings: Failed to build quarkus application: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
[ERROR] 	[error]: Build step io.quarkus.smallrye.reactivemessaging.deployment.SmallRyeReactiveMessagingProcessor#build threw an exception: javax.enterprise.inject.spi.DefinitionException: SRMSG00052: Invalid method annotated with @Outgoing: org.acme.kafka.processor.Example#process - the method must not be `void`
[ERROR] 	at io.smallrye.reactive.messaging.MediatorConfigurationSupport.validatePublisher(MediatorConfigurationSupport.java:229)
[ERROR] 	at io.smallrye.reactive.messaging.MediatorConfigurationSupport.validate(MediatorConfigurationSupport.java:87)
[ERROR] 	at io.quarkus.smallrye.reactivemessaging.deployment.QuarkusMediatorConfigurationUtil.create(QuarkusMediatorConfigurationUtil.java:105)
[ERROR] 	at io.quarkus.smallrye.reactivemessaging.deployment.SmallRyeReactiveMessagingProcessor.build(SmallRyeReactiveMessagingProcessor.java:393)
[ERROR] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] 	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
[ERROR] 	at io.quarkus.deployment.ExtensionLoader$2.execute(ExtensionLoader.java:820)
[ERROR] 	at io.quarkus.builder.BuildContext.run(BuildContext.java:277)
[ERROR] 	at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
[ERROR] 	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2449)
[ERROR] 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1478)
[ERROR] 	at java.base/java.lang.Thread.run(Thread.java:834)
[ERROR] 	at org.jboss.threads.JBossThread.run(JBossThread.java:501)

Expected behavior

It should work as described in the documentation: it simply processes both messages from the channels in no particular order

Actual behavior

There's a build failure that shows the usage of @Outcoming. I suspect the building of two @Incoming on the same function internally uses an @Outcoming to facilitate this, but the usage of @Outcoming makes the build step fail with Invalid method annotated with @Outgoing: org.acme.kafka.processor.Example#process - the method must not be void

How to Reproduce?

A reproducer is here: https://github.com/navkast/quarkus-reproducer. It's a very simple reproducer amounting to just:

  @Incoming("topic1")
  @Incoming("topic2")
  public CompletionStage<Void> process(Message<String> msg) {
    return msg.ack();
  }

Adding @Blocking or using public void process(String msg) { have the same results.

Output of uname -a or ver

Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64

Output of java -version

openjdk version "11.0.10" 2021-01-19 OpenJDK Runtime Environment (build 11.0.10+9) OpenJDK 64-Bit Server VM (build 11.0.10+9, mixed mode)

Quarkus version or git rev

2.1.3.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)

@navkast navkast added the kind/bug Something isn't working label Aug 21, 2021
@quarkus-bot
Copy link

quarkus-bot bot commented Aug 21, 2021

@cescoffier cescoffier self-assigned this Aug 22, 2021
cescoffier added a commit to cescoffier/quarkus that referenced this issue Aug 22, 2021
The reactive messaging extension has its own customized configuration layer to configure reactive messaging to use the Quarkus built time mechanism. This layer didn't support @Incomings.
This commit adds support for it.

Fix quarkusio#19562
@cescoffier
Copy link
Member

@navkast Quarkus didn't support @Incomings. I just opened a PR to add support for it.

@navkast
Copy link
Author

navkast commented Aug 23, 2021

@cescoffier Thank you for looking and for the prompt reply / resolution!

cescoffier added a commit to cescoffier/quarkus that referenced this issue Aug 23, 2021
The reactive messaging extension has its own customized configuration layer to configure reactive messaging to use the Quarkus built time mechanism. This layer didn't support @Incomings.
This commit adds support for it.

Fix quarkusio#19562
@quarkus-bot quarkus-bot bot added this to the 2.3 - main milestone Aug 24, 2021
@gsmet gsmet modified the milestones: 2.3 - main, 2.2.0.Final Aug 24, 2021
gsmet pushed a commit to gsmet/quarkus that referenced this issue Aug 24, 2021
The reactive messaging extension has its own customized configuration layer to configure reactive messaging to use the Quarkus built time mechanism. This layer didn't support @Incomings.
This commit adds support for it.

Fix quarkusio#19562

(cherry picked from commit 2c2474c)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants