Ensure that potentially blocking API's can be called asynchronously

[mmusgrov]

Ensure that potentially blocking API calls can be called in asynchronous mode. Some API methods such as LRAParticipant already do whereas others such as LRAClient do not,

[tomjenkinson]

Can we do anything more on the API further than Futures. @mmusgrov mentioned composable futures perhaps for a sequence like startLRA, do something, closeLRA

Perhaps @xstefank has some input from his research?

[xstefank]

The design is based on REST invocations which already provide asynchronous calls. Do we need anything more for the initial proposal? IMO the spec embedded execution may complicate / confuse first implementors.

[tomjenkinson]

This is for the LRAClient right, as in the programatic API. Under the covers it could use asynchronous REST but this is at the Java API level? Or perhaps I misunderstood the query @xstefank ?

[xstefank]

LRAClient is REST invocations (https://github.com/eclipse/microprofile-lra/blob/master/api/src/main/java/org/eclipse/microprofile/lra/client/LRAClient.java#L106). @mmusgrov already mentioned that programmatic API (LRAParticipant) already do support async invocations that's why I've described only REST. Sorry for the confusion @tomjenkinson .

[tomjenkinson]

I think what @mmusgrov is suggesting is to change things like:

URL startLRA(URL parentLRA, String clientID, Long timeout, TimeUnit unit)
throws GenericLRAException;

to:

Future<URL> startLRA(URL parentLRA, String clientID, Long timeout, TimeUnit unit)
throws GenericLRAException;

Then those rest invocations which can be async can be benefitted from in the business logic too?

[xstefank]

I see, wouldn't it be better to provide both options? Like startLRA and startLRAAsync. Even if I am not sure it makes sense for everything. In this particular case for start of the LRA, if ServiceA starts LRA asynchronously, it can't make a call to ServiceB as it doesn't know the LRA id yet.

[tomjenkinson]

That is a good point. startLRA puts the LRA on the thread (although implementations could use the future too and poll it before propagating?

I think if we do both we have to do both in LRAParticipant too right?

[mmusgrov]

Two points, firstly, @xstefank, what precisely do you mean by "The design is based on REST invocations ..". The spec specifies annotations that application developers apply to their JAX-RS resource methods. Is that what you mean?

Secondly, yes I am referring to the LRAClient API. Perhaps we could delay the async version of the APIs to release 1.x which I guess would imply that LRAParticipant methods should be synchronous.

[xstefank]

@mmusgrov 1/ yes, you are right. I also agree with 2/

[tomjenkinson]

I also agree with 2 from a consistency point of view