6 Replies Latest reply on Feb 24, 2020 7:13 AM by ochaloup

Asynchronous handling for Narayana CDI extension

ochaloup Jan 16, 2020 8:37 AM

I would need to check with you how to integrate the asynchronous handling for Narayana CDI extension. As the WildFly is about to support the MicroProfile specs the context propagation is one of them. I started to talk about it with kabirkhan.

Kabir started with integration of WildFly and the MicroProfile context propagation. The issue we've disscused was the asynchronous handling for transactions.

The Quarkus managed it with adding this code

quarkus/TransactionalInterceptorBase.java at master · quarkusio/quarkus · GitHub

on top of the code available in Narayana interceptor.

narayana/TransactionalInterceptorBase.java at master · jbosstm/narayana · GitHub

The code in Quarkus depends on the org.reactivestreams and on the io.smallrye.reactive.converters. My initial idea was that the code dependent on the reactive features could be part of the WFLY integration. And Narayana interceptor would then only inject that functionality e.g. via CDI.

But my attempts to cleanly separate the functionality did not go well. The quarkus code is coupled on both sides. You can check the attempt here.

Comparing master...async-handling-from-quarkus · ochaloup/narayana · GitHub

Then now I support the idea to make the Narayana dependent to that reactive libraries. All the code which is currently in Quarkus will be moved to Narayana. But the reactive libraries won't be required during runtime. When the reactive features are not available on classpath then they won't be used.

Additional advantage would be that Narayana code may could be potentially used directly in Quarkus. The CDI interceptor code would not be duplicated there.

Please, what is your perspective on this?

Thanks

Ondra

1. Re: Asynchronous handling for Narayana CDI extension

kabirkhan Jan 21, 2020 6:17 AM (in response to ochaloup)

tomjenkinson mmusgrov The reason this is important is that it is something missing in WildFly 19 for MicroProfile (reactive) context propagation to work as it does in Quarkus.

In WildFly, a test like quarkus/ContextEndpoint.java at ba1872440834519a88b88f5b7de04f645965a2cb · quarkusio/quarkus · GitHub can not work. The issue is that if the code in the async block happens after main thread exits the interceptor (which it may well do), the transaction status is not as expected. Ondrej's suggestion is to allow my MP Reactive feature pack to add the same mechanisms that Quarkus uses to work. I believe the intent is to leave 'raw' WildFly untouched unless the MP Reactive feature pack is installed.
Actions
2. Re: Asynchronous handling for Narayana CDI extension

mmusgrov Jan 22, 2020 8:13 AM (in response to ochaloup)

ochaloup I like your suggestion [of making Narayana dependent on the reactive libraries]. Is that something that you could prepare or should I investigate?
Actions
3. Re: Asynchronous handling for Narayana CDI extension

ochaloup Jan 22, 2020 8:39 AM (in response to mmusgrov)

mmusgrov ok, fine. All my initial attempts for migration are linked as references to github in the initial post. That's if you want to check the code.
I'm fine to take care of it. I plan to work on it next week (this week I'm struggling with preparation of presentation for DevConf.cz). I talked with Kabir and he is ok with this time schedule.
I will let you know if I find some trouble.
Actions
4. Re: Asynchronous handling for Narayana CDI extension

tomjenkinson Jan 24, 2020 4:57 AM (in response to ochaloup)

Please can you expand a bit on where the coupling on Comparing master...async-handling-from-quarkus · ochaloup/narayana · GitHub is? I was thinking it might be something in WFLY code?
Actions
5. Re: Asynchronous handling for Narayana CDI extension

ochaloup Jan 27, 2020 3:10 AM (in response to tomjenkinson)

By coupling I meant the fact that's hard to separate the async functionality from the non-async functionality. The asynchronous code requires code we already have in the JTA interceptor currently and the JTA interceptor needs to call back to the async callbacks to find out the results and work with it. The code is coupled in way that's pretty difficult to separate the asynchronous functionality and strip it away in form of some interface that could be implemented in the WildFly MicroProfile integration code.
Does it make sense?

My proposal is to have all the functionality in the JTA interceptor, which I think is reasonable as it's all about transactions - in sync or async mode.

I'm not sure what you mean by "something in WFLY code". Do you mean something specific? Then just point me to the place. I will try to investigate on it then.
Actions
6. Re: Asynchronous handling for Narayana CDI extension

ochaloup Feb 24, 2020 7:13 AM (in response to ochaloup)

The outcome of the further discussion of this topic on different channels the result was done that we could implement the asynchronous functionality in the Narayana code base. If there is some code that will be adopted from the Quarkus code base it has to be correctly licensed (the possible option is to create a separate class which will be licensed with apache license v2).

I started to work on the solution and there could be seen the PR here:
[JBTM-3246] adapting async handling for CDI interceptors by ochaloup · Pull Request #1558 · jbosstm/narayana · GitHub
(the PR is mostly done but some adjustments still have to be done as the integration with WildFly has to work and the context propagation tests have to pass)
Actions

Go to original post