[JBoss JIRA] (CDI-729) Async event not CompletionStage friendly
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-729:
----------------------------------------
To enable exceptionally and friends ;)
> Async event not CompletionStage friendly
> ----------------------------------------
>
> Key: CDI-729
> URL: https://issues.jboss.org/browse/CDI-729
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched.
> Here is a sample:
> 1. fireAsync(persistEvent)
> 2. observer implementation does: return future.thenCompose(db::doAsyncPersist)
> 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (CDI-729) Async event not CompletionStage friendly
by James Roper (JIRA)
[ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.sy... ]
James Roper commented on CDI-729:
---------------------------------
Ah, sorry I misunderstood.
Why is a {{CompletionStage}} of the event needed to be passed to the method? To use it, the first thing that will need to be done is to attach a {{thenCompose}} to the completion stage. Why not have CDI do a {{thenCompose}} first, and then just invoke the method directly with the actual event? I don't see what value is gained by passing in a {{CompletionStage}}, an event when published is always available immediately, {{CompletionStage}} is for values that aren't available yet.
> Async event not CompletionStage friendly
> ----------------------------------------
>
> Key: CDI-729
> URL: https://issues.jboss.org/browse/CDI-729
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched.
> Here is a sample:
> 1. fireAsync(persistEvent)
> 2. observer implementation does: return future.thenCompose(db::doAsyncPersist)
> 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (CDI-729) Async event not CompletionStage friendly
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau edited comment on CDI-729 at 6/19/18 12:51 PM:
------------------------------------------------------------------
What I'm saying is that supporting to inject the completionstage event and use the returned completion stage (which can include a database call) for the "wait completion" logic on cdi side is trivial to impl and enable a lot of cases in user land so it does worth it a lot. Exception are a simple impl of backpressure with CompletionStage, even using bulkhead (different pool) works. This is clearly out of cdi (which is good) and already handled in the jre for the basic stuff. Advanced impl will use rx, hystrix or other impl and the link to CompletionStage.
Side note: you don't block the caller thread anyway ;) and if you want to append your db call you expect to block the async thread and this is the whole goal of that ticket. In practise I expect to use NIO at the end (remote http service in my case).
was (Author: rmannibucau):
What I'm saying is that supporting to inject the completionstage event and use the returned completion stage (which can include a database call) for the "wait completion" logic on cdi side is trivial to impl and enable a lot of cases in user land so it does worth it a lot. Exception are a simple impl of backpressure with CompletionStage, even using bulkhead (different pool) works. This is clearly out of cdi (which is good) and already handled in the jre for the basic stuff. Advanced impl will use rx, hystrix or other impl and the link to CompletionStage.
> Async event not CompletionStage friendly
> ----------------------------------------
>
> Key: CDI-729
> URL: https://issues.jboss.org/browse/CDI-729
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched.
> Here is a sample:
> 1. fireAsync(persistEvent)
> 2. observer implementation does: return future.thenCompose(db::doAsyncPersist)
> 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (CDI-729) Async event not CompletionStage friendly
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-729:
----------------------------------------
What I'm saying is that supporting to inject the completionstage event and use the returned completion stage (which can include a database call) for the "wait completion" logic on cdi side is trivial to impl and enable a lot of cases in user land so it does worth it a lot. Exception are a simple impl of backpressure with CompletionStage, even using bulkhead (different pool) works. This is clearly out of cdi (which is good) and already handled in the jre for the basic stuff. Advanced impl will use rx, hystrix or other impl and the link to CompletionStage.
> Async event not CompletionStage friendly
> ----------------------------------------
>
> Key: CDI-729
> URL: https://issues.jboss.org/browse/CDI-729
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched.
> Here is a sample:
> 1. fireAsync(persistEvent)
> 2. observer implementation does: return future.thenCompose(db::doAsyncPersist)
> 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (CDI-729) Async event not CompletionStage friendly
by James Roper (JIRA)
[ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.sy... ]
James Roper commented on CDI-729:
---------------------------------
Not sure that I understand, are you saying that what I described above is already supported today? Because, at least according to the Weld documentation, the only thing an observer can return today is {{void}}.
And for back pressure, sure, the CDI implementation might be fast, but if an event handler is doing an operation on a database or remote service, and that is overloaded and taking 10 seconds to respond, how can that backpressure be propagated back to the thing that fired the event so that it doesn't continue firing events and increase the load on the already overloaded slow component? Currently, the only way is for the consumer to block the thread it's running on, that's not asynchronous.
> Async event not CompletionStage friendly
> ----------------------------------------
>
> Key: CDI-729
> URL: https://issues.jboss.org/browse/CDI-729
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched.
> Here is a sample:
> 1. fireAsync(persistEvent)
> 2. observer implementation does: return future.thenCompose(db::doAsyncPersist)
> 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (CDI-729) Async event not CompletionStage friendly
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-729:
----------------------------------------
Not sure what you mean. From the point you can return a CompletionStage and cdi container append it to the "waited" CompletionStage then you are good and can introduce the error handling you want in all layers (either the nested one for internal error handling and backpressure to the fireAsync caller or directly in the caller layer to get a default error handling. Indeed you can stack a lot of promises but it is what you intend with this pattern and if you care (means you dont trust observers) then you combine it with timeouts.
In terms of implementations it is really <5mn with tests on cdi impl side.
> Async event not CompletionStage friendly
> ----------------------------------------
>
> Key: CDI-729
> URL: https://issues.jboss.org/browse/CDI-729
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched.
> Here is a sample:
> 1. fireAsync(persistEvent)
> 2. observer implementation does: return future.thenCompose(db::doAsyncPersist)
> 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (CDI-729) Async event not CompletionStage friendly
by James Roper (JIRA)
[ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.sy... ]
James Roper commented on CDI-729:
---------------------------------
The problem is that while it is possible for event publishers to fire an event asynchronously, that is, fire it and then continue processing immediately, and then asynchronously be notified when the event has been successfully observed by all the observers, there is no way for event observers to handle the event asynchronously, that is, they can't trigger some asynchronous IO, then return immediately from the method, and then asynchronously let the publisher know that they event was handled successfully. The only thing they can do is block.
So, imagine I wanted to do a REST call using an asynchronous HTTP client, this REST call is done using the following method:
{code:java}
public CompletionStage<Response> makeRequest(Request request);
{code}
Now, if I implement an observer:
{code:java}
public void handleEvent(@ObservesAsync MyEvent event) {
CompletionStage<Response> response = makeRequest(convertEventToRequest(event));
// Now what do I do?
}
{code}
The problem with the above is that {{handleEvent}} is going to return before the REST request has been made, and so neither the status, nor backpressure, can be propagated back to the event publisher, unless of course I block on the {{CompletionStage}}, in which case, I'm no longer asynchronous. In order to support asynchronous propagation of backpressure and success signalling, CDI needs to support observer methods that return {{CompletionStage}} so that the methods can indicate when they are done handling the event, eg:
{code:java}
public CompletionStage<?> handleEvent(@ObservesAsync MyEvent event) {
CompletionStage<Response> response = makeRequest(convertEventToRequest(event));
return response;
}
{code}
What the impact here is is when I publish the event using the following code:
{code:java}
CompletionStage<?> fireEventResult = event.fireAsync(myEvent);
{code}
The {{fireEventResult}} completion stage won't be redeemed until after the {{CompletionStage}} returned by {{handleEvent}} is redeemed. This ensures that something publishing events asynchronously doesn't overwhelm the event handlers, by ensuring backpressure gets propagated, and also ensures that if there's an error that's asynchronously encountered, that the publisher can be aware of that.
We're looking at integrating the MicroProfile messaging spec with CDI asynchronous events, and the ability to propagate backpressure asynchronously through event publishing is necessary before we can do that, otherwise an incoming message stream from a message broker could easily overwhelm a server. Our issue for tracking that feature is here:
https://github.com/eclipse/microprofile-reactive/issues/30
> Async event not CompletionStage friendly
> ----------------------------------------
>
> Key: CDI-729
> URL: https://issues.jboss.org/browse/CDI-729
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched.
> Here is a sample:
> 1. fireAsync(persistEvent)
> 2. observer implementation does: return future.thenCompose(db::doAsyncPersist)
> 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (CDI-727) CDI.current() should use privileged block
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-727?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-727:
-----------------------------
Labels: security-manager (was: )
> CDI.current() should use privileged block
> -----------------------------------------
>
> Key: CDI-727
> URL: https://issues.jboss.org/browse/CDI-727
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Javadoc and API
> Affects Versions: 2.0 .Final
> Reporter: Jan Kalina
> Labels: security-manager
>
> When deployment in container with security manager enabled try to use {{CDI.current()}} call, {{CDI}} class directly access JAR of CDI provider, because of which security manager requires from the deployment to have permission to read the JAR.
> *{{CDI.findAllProviders}} method should read the JAR in privileged block.*
> (as discussed in WFLY-10125)
> {code}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/1cfa62fc/jboss-eap-7.2/modules/system/layers/base/org/jboss/as/weld/main/wildfly-weld-7.2.0.CD12-redhat-2.jar" "read")" in code source "(vfs:/content/test.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.test.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360)
> at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:152)
> at java.net.URL.openStream(URL.java:1045)
> at javax.enterprise.inject.spi.CDI.findAllProviders(CDI.java:109)
> at javax.enterprise.inject.spi.CDI.current(CDI.java:53)
> at org.jboss.as.test.integration.ee.injection.support.jpa.beanManager.TestEntityListener.obtainFooViaCdiCurrent(TestEntityListener.java:97)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (CDI-699) AnnotationLiteral should use privileged actions for reflective operations
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-699?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-699:
-----------------------------
Labels: security-manager (was: )
> AnnotationLiteral should use privileged actions for reflective operations
> -------------------------------------------------------------------------
>
> Key: CDI-699
> URL: https://issues.jboss.org/browse/CDI-699
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Javadoc and API
> Reporter: Martin Kouba
> Labels: security-manager
> Fix For: 2.1 (Discussion)
>
>
> Currently, if an application declares its own literal which extends {{AnnotationLiteral}} and is run with {{SecurityManager}} enabled, some methods might lead to {{SecurityException}} (e.g. {{AnnotationLiteral.getMembers()}} called in constructor requires {{accessDeclaredMembers}} permission). The only possible fix seems to be to grant the permission to the deployment/application which is not very convenient. If privileged actions were used, the app server could grant the permissions to the provided CDI API module only.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (CDI-729) Async event not CompletionStage friendly
by Gordon Hutchison (JIRA)
[ https://issues.jboss.org/browse/CDI-729?page=com.atlassian.jira.plugin.sy... ]
Gordon Hutchison edited comment on CDI-729 at 6/19/18 8:19 AM:
---------------------------------------------------------------
This sort of approach could prove very useful in trying to 'plug-together' a stream of CDI events from some other reactive stream.
was (Author: hutchig):
This sort of approach could prove very useful in tryin to 'plug-together' a stream of CDI events from some other reactive stream.
> Async event not CompletionStage friendly
> ----------------------------------------
>
> Key: CDI-729
> URL: https://issues.jboss.org/browse/CDI-729
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> The goal of this ticket is to enable user to get injected the completion future instead of the raw event and return another completion stage (generic type ignored) to enable the "chain" to be synched.
> Here is a sample:
> 1. fireAsync(persistEvent)
> 2. observer implementation does: return future.thenCompose(db::doAsyncPersist)
> 3. when the user gets back the result of the fireAsync the doAsyncPersist is completed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months