4:30 a.m.
I'm using CDI 2.0 and Weld 3.0.0.CR2 in "SE mode".
If I fire an asynchronous event without any special notification options,
my understanding is that the container will arrange for that event to be
delivered to asynchronous observers.
Is (appropriate) asynchronous observer method invocation guaranteed to
happen at some point? Section 10.2.2 seems to hint that it is:
"Event fired [sic] with the fireAsync() method is [sic] fired
asynchronously. *All the resolved asynchronous observers* (as defined in
Observer resolution) *are called* in one or more different threads."
To me, this says that if I use fireAsync() to fire an event, then if I have
a (resolved) asynchronous observer method for it it will be notified before
the container closes no matter what.
(I believe I am observing a race condition somewhere in here that might
show that Weld's default asynchronous event delivery machinery does not
actually get around to delivering the event I've queued up before the
container closes. Sometimes the event is received, sometimes it is not.
Obviously if there is no such guarantee this could be permitted behavior.)
Best,
Laird
3:19 p.m.
Hi Laird,
if I understand you correctly, there is no guarantee for that in Weld. If you fire an
async event it will spin another thread (or more), where it will start notifying async
observers.
Only after it is done, it will come back to the main thread with result. There is no
synchronization around this - that would kind of go against the nature of truly
asynchronous calls, wouldn't it?
As for spec interpretation, I don't think the implication you suggest is intended
there.
It's a shame we haven't clarified this earlier though.
What exactly is your use case?
Matej
----- Original Message -----
From: "Laird Nelson" <ljnelson(a)gmail.com>
To: "cdi-dev" <cdi-dev(a)lists.jboss.org>
Sent: Thursday, May 11, 2017 9:30:17 PM
Subject: [cdi-dev] What, if any, guarantees are made about invoking asynchronous event
observer methods?
I'm using CDI 2.0 and Weld 3.0.0.CR2 in "SE mode".
If I fire an asynchronous event without any special notification options, my
understanding is that the container will arrange for that event to be
delivered to asynchronous observers.
Is (appropriate) asynchronous observer method invocation guaranteed to happen
at some point? Section 10.2.2 seems to hint that it is:
"Event fired [sic] with the fireAsync() method is [sic] fired asynchronously.
All the resolved asynchronous observers (as defined in Observer resolution)
are called in one or more different threads."
To me, this says that if I use fireAsync() to fire an event, then if I have a
(resolved) asynchronous observer method for it it will be notified before
the container closes no matter what.
(I believe I am observing a race condition somewhere in here that might show
that Weld's default asynchronous event delivery machinery does not actually
get around to delivering the event I've queued up before the container
closes. Sometimes the event is received, sometimes it is not. Obviously if
there is no such guarantee this could be permitted behavior.)
Best,
Laird
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code
under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
2:08 a.m.
On Thu, May 11, 2017 at 11:19 PM Matej Novotny <manovotn(a)redhat.com> wrote:
if I understand you correctly, there is no guarantee for that in
Weld.
OK thanks.
If you fire an async event it will spin another thread (or more),
where it
will start notifying async observers.
Sure. My question is: is there any guarantee that the asynchronous
observer method will be *called* at all, regardless of whether it
finishes? I believe the answer is no. That is, there are absolutely no
semantics guaranteed about delivery (neither at-least-once nor at-most-once
nor exactly-once).
So I've learned that in an SE setting anyway it is important to know
that—depending on when the SeContainer is closed, obviously—some of your
asynchronous observers may never be notified. Additionally it is important
to know that calling thenRun()
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Completion...
(or other variants not ending in "Async") on the returned CompletionStage
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Completion...
may very well not work, and its exceptionally()
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Completion...
stuff may also never be called.
Only after it is done, it will come back to the main thread with
result.
There is no synchronization around this - that would kind of go against the
nature of truly asynchronous calls, wouldn't it?
I understand that the container won't block waiting for the asynchronous
method to *come back*. As you say, that wouldn't be asynchronous (although
you could make an argument that everything should be gathered up before the
container closes, but I understand that's contentious and has a lot of
overhead).
But I *am* interested in: is there any guarantee that the asynchronous
observer method will be *called*? The answer appears to be no. (Another
way to look at it is my questions are around the behavior of the returned
CompletionStage
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Completion...
.)
Martin referred me to https://issues.jboss.org/browse/CDI-570 which is
another variant of my questions.
What exactly is your use case?
Well, now it's just curiosity. :-) It looks like when SeContainer.close()
is called, everything stops more or less immediately, regardless of what
state anything is in (even if, say, your asynchronous observer has a bean
injected into it that observes the closing of the scope).
Best,
Laird
2:31 a.m.
On Fri, May 12, 2017 at 10:08 AM Laird Nelson <ljnelson(a)gmail.com> wrote:
Martin referred me to https://issues.jboss.org/browse/CDI-570 which
is
another variant of my questions.
I've put a Github repo up with some explorations that might be fun or
interesting to people: https://github.com/ljnelson/weld-570
Best,
Laird
4:13 p.m.
Hi Laird,
Thanks for creating a reproducer straight away.
I took a glance at the repo and here is what I think:
TestScenario1/2 are pretty much what we are discussing here - the container terminates and
observers don't get notified any more.
Obviously, if you hang any additional 'thenRun' etc. on top of that, it won't
work either.
TestScenario3 is with Weld parallel mode and is IMO out of scope of previous discussion
but important nonetheless.
This is indeed weird and I think you are observing a peculiar behaviour of default
executor in SE, which is ForkJoinPool.
We have a test[1] for parallel execution in SE, where we defined your own executor (see
'createWeld' method) and it works like a charm.
I think we need to look into FJP to see what's truly going on there.
Matej
____________________________________________________________________________________________
[1]https://github.com/weld/core/blob/master/environments/se/tests/src/test...
----- Original Message -----
From: "Laird Nelson" <ljnelson(a)gmail.com>
To: "cdi-dev" <cdi-dev(a)lists.jboss.org>, "Matej Novotny"
<manovotn(a)redhat.com>
Sent: Friday, May 12, 2017 7:31:44 PM
Subject: Re: [cdi-dev] What, if any, guarantees are made about invoking asynchronous
event observer methods?
On Fri, May 12, 2017 at 10:08 AM Laird Nelson <ljnelson(a)gmail.com> wrote:
> Martin referred me to https://issues.jboss.org/browse/CDI-570 which is
> another variant of my questions.
>
I've put a Github repo up with some explorations that might be fun or
interesting to people: https://github.com/ljnelson/weld-570
Best,
Laird
12:25 a.m.
On Mon, May 15, 2017 at 12:13 AM Matej Novotny <manovotn(a)redhat.com> wrote:
TestScenario1/2 are pretty much what we are discussing here - the
container terminates and observers don't get notified any more.
Obviously, if you hang any additional 'thenRun' etc. on top of that, it
won't work either.
Right.
TestScenario3 is with Weld parallel mode and is IMO out of scope of
previous discussion but important nonetheless.
Yeah—this git repo was less a reproducer and more just me playing around.
:-)
This is indeed weird and I think you are observing a peculiar
behaviour of
default executor in SE, which is ForkJoinPool.
We have a test[1] for parallel execution in SE, where we defined your own
executor (see 'createWeld' method) and it works like a charm.
I think we need to look into FJP to see what's truly going on there.
Oh, that is interesting. OK; thanks.
Best,
Laird
6:13 p.m.
Hey Laird,
managed to figure out your TestScenario3[1] with FJP in single thread.
I feel silly for not noticing earlier, but the only real problem is that your test GH
project used Weld 3.0.0.CR2[2] and the actual parallel option was added in
3.0.0.Final[3].
So, just upgrade your POM to 3.0.0.Final and it will magically work :)
Matej
_________________________________________________________________________________________________________
[1]https://github.com/ljnelson/weld-570/blob/master/src/test/java/weld/wel...
[2]https://github.com/ljnelson/weld-570/blob/master/pom.xml#L63
[3]https://issues.jboss.org/browse/WELD-2353
----- Original Message -----
From: "Laird Nelson" <ljnelson(a)gmail.com>
To: "Matej Novotny" <manovotn(a)redhat.com>
Cc: "cdi-dev" <cdi-dev(a)lists.jboss.org>
Sent: Monday, May 15, 2017 5:25:10 PM
Subject: Re: [cdi-dev] What, if any, guarantees are made about invoking asynchronous
event observer methods?
On Mon, May 15, 2017 at 12:13 AM Matej Novotny <manovotn(a)redhat.com> wrote:
> TestScenario1/2 are pretty much what we are discussing here - the
> container terminates and observers don't get notified any more.
> Obviously, if you hang any additional 'thenRun' etc. on top of that, it
> won't work either.
>
Right.
> TestScenario3 is with Weld parallel mode and is IMO out of scope of
> previous discussion but important nonetheless.
>
Yeah—this git repo was less a reproducer and more just me playing around.
:-)
> This is indeed weird and I think you are observing a peculiar behaviour of
> default executor in SE, which is ForkJoinPool.
> We have a test[1] for parallel execution in SE, where we defined your own
> executor (see 'createWeld' method) and it works like a charm.
> I think we need to look into FJP to see what's truly going on there.
>
Oh, that is interesting. OK; thanks.
Best,
Laird
3:39 p.m.
Dne 11.5.2017 v 21:30 Laird Nelson napsal(a):
I'm using CDI 2.0 and Weld 3.0.0.CR2 in "SE mode".
If I fire an asynchronous event without any special notification
options, my understanding is that the container will arrange for that
event to be delivered to asynchronous observers.
Is (appropriate) asynchronous observer method invocation guaranteed to
happen at some point? Section 10.2.2 seems to hint that it is:
"Event fired [sic] with the fireAsync() method is [sic] fired
asynchronously. *All the resolved asynchronous observers* (as defined in
Observer resolution) *are called* in one or more different threads."
To me, this says that if I use fireAsync() to fire an event, then if I
have a (resolved) asynchronous observer method for it it will be
notified before the container closes no matter what.
I think it's undefined. And I don't believe it would be reasonable to
block the container shutdown because of an async observer method waiting
for notification. The spec is clear that the container must destroy all
contexts when an application is stopped. And if we destroy the contexts
then the bean declaring the observer or its dependencies might be in
inconsistent state.
(I believe I am observing a race condition somewhere in here that might
show that Weld's default asynchronous event delivery machinery does not
actually get around to delivering the event I've queued up before the
container closes. Sometimes the event is received, sometimes it is
not. Obviously if there is no such guarantee this could be permitted
behavior.)
Best,
Laird
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
4:57 p.m.
FYI there is already https://issues.jboss.org/browse/CDI-570 which seems
to be related.
Martin
Dne 12.5.2017 v 08:39 Martin Kouba napsal(a):
Dne 11.5.2017 v 21:30 Laird Nelson napsal(a):
> I'm using CDI 2.0 and Weld 3.0.0.CR2 in "SE mode".
>
> If I fire an asynchronous event without any special notification
> options, my understanding is that the container will arrange for that
> event to be delivered to asynchronous observers.
>
> Is (appropriate) asynchronous observer method invocation guaranteed to
> happen at some point? Section 10.2.2 seems to hint that it is:
>
> "Event fired [sic] with the fireAsync() method is [sic] fired
> asynchronously. *All the resolved asynchronous observers* (as defined in
> Observer resolution) *are called* in one or more different threads."
>
> To me, this says that if I use fireAsync() to fire an event, then if I
> have a (resolved) asynchronous observer method for it it will be
> notified before the container closes no matter what.
I think it's undefined. And I don't believe it would be reasonable to
block the container shutdown because of an async observer method waiting
for notification. The spec is clear that the container must destroy all
contexts when an application is stopped. And if we destroy the contexts
then the bean declaring the observer or its dependencies might be in
inconsistent state.
>
> (I believe I am observing a race condition somewhere in here that might
> show that Weld's default asynchronous event delivery machinery does not
> actually get around to delivering the event I've queued up before the
> container closes. Sometimes the event is received, sometimes it is
> not. Obviously if there is no such guarantee this could be permitted
> behavior.)
>
> Best,
> Laird
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
2540
days inactive
2553
days old
8 comments
3 participants
participants (3)
-
Laird Nelson -
Martin Kouba -
Matej Novotny