[cdi-dev] Today's meeting will be shorter and about SE
Jozef Hartinger
jharting at redhat.com
Thu Dec 18 09:12:27 EST 2014
But we should only be shutting down thread pools that we manage. Just
like CompletableFuture won't shut down your thread pool if you pass it
to *Async method.
On 12/18/2014 11:57 AM, José Paumard wrote:
> Yes, there are good use cases for letting the user provide his own ES
> to have async calls executed in them. They are the same kind of use
> cases we have for CompletionStage.
>
> José
>
> 2014-12-18 10:18 GMT+01:00 Romain Manni-Bucau <rmannibucau at gmail.com
> <mailto:rmannibucau at gmail.com>>:
>
> 2014-12-18 9:58 GMT+01:00 José Paumard <jose.paumard at gmail.com
> <mailto:jose.paumard at gmail.com>>:
> > From what we wrote about async events, ES can be submitted
> through the
> > fireAsync call, following the patterns of CompletionStage. We
> can also
> > submit a default ES while building a CDI container (a you
> wrote), and if we
> > dont the default ES will probably be the default ForkJoinPool.
> >
> > So we may have more than one ES, making things more complicated
> than the
> > pattern you wrote. I think that having the user to close all the
> ESes will
> > lead to the same pattern again and again :
> > for (ES es : cdi.getESes()) {
> > myShutdown(es) ;
> > }
> >
>
> Sorry I missed something here: how can we get multiple ES? Basically
> if CDI needs a ES behing the scene I expect it expose few config like
> potential concurrent calls number etc...In such a case I'm not sure if
> having multiple ES would be a good idea.
>
> > I'd prefer to have a cdi.shutdown(), cdi.shudownNow() or
> > cdi.awaitTermination(...) or whatever we call those methods, to
> encapsulate
> > this code. Seems cleaner to me. It might look like CDI is
> becoming an ES
> > itself, but it's delegation, not inheritance.
> >
> >
> >
> > 2014-12-18 9:28 GMT+01:00 Romain Manni-Bucau
> <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>>:
> >>
> >> Why exposing them? When not simply exposing the executor
> service (in
> >> "init" method).
> >>
> >> CDIContainer cdi =
> CDIContainer.init(singletonMap(ExecutorService.class,
> >> myEs));
> >> // do something awesome
> >> shutdownAsIwant(myEs);
> >> cdi.close();
> >>
> >> Would avoid to have a lot of method several users will not care
> about.
> >>
> >> By default it would do a if (timeout <= 0 ||
> >> !defaultEs.awaitTermination(timeout, MILLISECONDS)) { for
> (Runnable r
> >> : defaultEs.shutdownNow()) { try { r.cancel(); } catch(e) {
> log(e); }
> >> } } with timeout a property of the init map with a default in
> >> CDIContainer (constant)
> >>
> >> wdyt?
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com
> >> http://rmannibucau.wordpress.com
> >> https://github.com/rmannibucau
> >>
> >>
> >> 2014-12-18 9:19 GMT+01:00 José Paumard <jose.paumard at gmail.com
> <mailto:jose.paumard at gmail.com>>:
> >> > I think we need to think more about how to close the Container.
> >> >
> >> > We need to take into account the fact that there wil be async
> process
> >> > running in ExecutorServices (SE) or ManagedExecutorServices
> (EE). So the
> >> > shutting down the container will mean shutting down these ES too.
> >> >
> >> > So I think we should need to carefully look at the way ES are
> closed.
> >> > The
> >> > question being : what do we do with async tasks that are
> still running :
> >> > should we abruptely interrupt them ? give them a chance to
> complete ?
> >> > All
> >> > these are exposed in different methods of ES : shutdown(),
> shutdownNow()
> >> > and
> >> > awaitTermination(timeout). Since the container will have to
> call one of
> >> > these methods per ES it will manage, I think we should also
> expose them.
> >> >
> >> > José
> >> >
> >> >
> >> > 2014-12-18 9:14 GMT+01:00 Romain Manni-Bucau
> <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>>:
> >> >>
> >> >> ServiceLoader.load(<api>) = ServiceLoader.load(<api>, tccl)
> >> >>
> >> >> I was thinking to a plain servlet engine (tomcat to not say
> any name)
> >> >> and CDI container API to boot in webapps. Having cdi API in
> tomcat
> >> >> itself and CDI impl in webapps (Weld in webapp1, OWB in
> webapp2 for
> >> >> instance). This would mean using one webapp classloader to
> find the
> >> >> booter/container. This is fine excepted if the instance is
> cached.
> >> >>
> >> >> Same thought in more complicated about OSGi but I guess it
> is not yet
> >> >> the target.
> >> >>
> >> >>
> >> >> Romain Manni-Bucau
> >> >> @rmannibucau
> >> >> http://www.tomitribe.com
> >> >> http://rmannibucau.wordpress.com
> >> >> https://github.com/rmannibucau
> >> >>
> >> >>
> >> >> 2014-12-18 8:58 GMT+01:00 Jozef Hartinger
> <jharting at redhat.com <mailto:jharting at redhat.com>>:
> >> >> >
> >> >> > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote:
> >> >> >>
> >> >> >> Hi guys,
> >> >> >>
> >> >> >> - why shutdown and not AutoClosable?
> >> >> >
> >> >> > I like this idea.
> >> >> >>
> >> >> >> - about instance: it uses TCCL to load the impls, not
> sure it is
> >> >> >> intended but depending the deployment it can be an issue
> (is this
> >> >> >> api
> >> >> >> 100% JavaSE + flat classpath - ie more constrained than
> JavaSE?) +
> >> >> >> most of javax SPI creates a new instance each time
> "creator" is
> >> >> >> called.
> >> >> >
> >> >> > I don't follow. Who uses TCCL?
> >> >> >>
> >> >> >> - Why Booter and not Container (better than factory IMO)?
> 1) for
> >> >> >> consistency with other spec, 2) why can I shutdown a
> booter ;)?
> >> >> >
> >> >> > Exactly
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> Romain Manni-Bucau
> >> >> >> @rmannibucau
> >> >> >> http://www.tomitribe.com
> >> >> >> http://rmannibucau.wordpress.com
> >> >> >> https://github.com/rmannibucau
> >> >> >>
> >> >> >>
> >> >> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger
> <jharting at redhat.com <mailto:jharting at redhat.com>>:
> >> >> >>>
> >> >> >>> On 12/18/2014 04:33 AM, John D. Ament wrote:
> >> >> >>>
> >> >> >>> I thought today's meeting was pretty good. Based on one
> of the
> >> >> >>> discussion
> >> >> >>> points, I wanted to try putting together an interface that
> >> >> >>> described
> >> >> >>> the
> >> >> >>> boot paradigm. Unfortunately even in Java 8 it doesn't
> work too
> >> >> >>> well,
> >> >> >>> I
> >> >> >>> cannot assign a static variable in an interface the way
> I can in an
> >> >> >>> abstract
> >> >> >>> class. More importantly, it doesn't give us the private
> level
> >> >> >>> expectation I
> >> >> >>> would look for in this case. I best I could come up
> with using an
> >> >> >>> interface
> >> >> >>> is:
> >> >> >>>
> >> >> >>> public interface CDIBooter {
> >> >> >>> default BeanManager initialize() {
> >> >> >>> return initialize(new HashMap<>());
> >> >> >>> }
> >> >> >>>
> >> >> >>> BeanManager initialize(Map<?,?> properties);
> >> >> >>>
> >> >> >>> Why BeanManager? I think it would be better to return
> CDI or its
> >> >> >>> subclass
> >> >> >>> rather than this low-level SPI. With the CDI class we
> get more
> >> >> >>> user-friendly
> >> >> >>> Instance<T> for free. We could also expose Event<T>
> similarly.
> >> >> >>>
> >> >> >>>
> >> >> >>> void shutdown();
> >> >> >>>
> >> >> >>> class BootHolder {
> >> >> >>>
> >> >> >>> static CDIBooter instance = null;
> >> >> >>>
> >> >> >>> }
> >> >> >>>
> >> >> >>> static CDIBooter instance() {
> >> >> >>> if(BootHolder.instance == null) {
> >> >> >>> ServiceLoader<CDIBooter> serviceLoader =
> >> >> >>> ServiceLoader.load(CDIBooter.class);
> >> >> >>> for(CDIBooter booter : serviceLoader) {
> >> >> >>> BootHolder.instance = booter;
> >> >> >>> break;
> >> >> >>> }
> >> >> >>> }
> >> >> >>> return BootHolder.instance;
> >> >> >>> }
> >> >> >>> }
> >> >> >>>
> >> >> >>> where as the abstract class is a bit briefer, while also
> being
> >> >> >>> private.
> >> >> >>>
> >> >> >>> public abstract class CDIBooter {
> >> >> >>> public BeanManager initialize() {
> >> >> >>> return initialize(new HashMap<>());
> >> >> >>> }
> >> >> >>>
> >> >> >>> public abstract BeanManager initialize(Map<?,?>
> properties);
> >> >> >>>
> >> >> >>> public abstract void shutdown();
> >> >> >>>
> >> >> >>> private static CDIBooter instance = null;
> >> >> >>>
> >> >> >>> public static CDIBooter instance() {
> >> >> >>> if(instance == null) {
> >> >> >>> ServiceLoader<CDIBooter> serviceLoader =
> >> >> >>> ServiceLoader.load(CDIBooter.class);
> >> >> >>> for(CDIBooter booter : serviceLoader) {
> >> >> >>> instance = booter;
> >> >> >>> break;
> >> >> >>> }
> >> >> >>> }
> >> >> >>> return instance;
> >> >> >>> }
> >> >> >>> }
> >> >> >>>
> >> >> >>> Obviously ignore concurrency issues, etc. It does look
> to be safer
> >> >> >>> to
> >> >> >>> do
> >> >> >>> an
> >> >> >>> abstract class, rather than a factory-interface.
> >> >> >>>
> >> >> >>> John
> >> >> >>>
> >> >> >>>
> >> >> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand
> >> >> >>> <antoine at sabot-durand.net
> <mailto:antoine at sabot-durand.net>> wrote:
> >> >> >>>>
> >> >> >>>> Hi all,
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> I have business matter and will have to shorten the meeting
> >> >> >>>> tonight
> >> >> >>>> (half
> >> >> >>>> an hour instead of 1h).
> >> >> >>>>
> >> >> >>>> I updated the SE doc and Antonio added useful annexes :
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-wwF35Yw/edit?usp=sharing
> >> >> >>>>
> >> >> >>>> I propose we focus on this in these 30 mn
> >> >> >>>>
> >> >> >>>> regards,
> >> >> >>>>
> >> >> >>>> Antoine
> >> >> >>>> _______________________________________________
> >> >> >>>> cdi-dev mailing list
> >> >> >>>> cdi-dev at lists.jboss.org <mailto:cdi-dev at 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.
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> _______________________________________________
> >> >> >>> cdi-dev mailing list
> >> >> >>> cdi-dev at lists.jboss.org <mailto:cdi-dev at 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.
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> _______________________________________________
> >> >> >>> cdi-dev mailing list
> >> >> >>> cdi-dev at lists.jboss.org <mailto:cdi-dev at 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.
> >> >> >
> >> >> >
> >> >> _______________________________________________
> >> >> cdi-dev mailing list
> >> >> cdi-dev at lists.jboss.org <mailto:cdi-dev at 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.
> >> >
> >> >
> >> >
> >> > --
> >> > Java le soir Cours Java en ligne
> >> > Twitter Paris JUG Devoxx France
> >> > M : +33 6 76 82 91 47 <tel:%2B33%206%2076%2082%2091%2047>
> >
> >
> >
> > --
> > Java le soir Cours Java en ligne
> > Twitter Paris JUG Devoxx France
> > M : +33 6 76 82 91 47 <tel:%2B33%206%2076%2082%2091%2047>
>
>
>
> --
> Java le soir <http://blog.paumard.org> Cours Java en ligne
> <http://blog.paumard.org/cours-tutoriaux/>
> Twitter <http://twitter.com/#%21/JosePaumard> Paris JUG
> <http://www.parisjug.org> Devoxx France <http://www.devoxx.fr>
> M : +33 6 76 82 91 47
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141218/7a7ad98a/attachment-0001.html
More information about the cdi-dev
mailing list