deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Andraschko <andraschko.tho...@gmail.com>
Subject Re: Context capturing and JSF Parallel-Preloading
Date Sat, 09 Apr 2016 07:18:09 GMT
Hi Christian,

basically thats an interesting idea, just not sure if we could implement it
in a nicer way.
I think scanning the component tree and analyzing every EL expression feels
a little risky and slow.

Using a bytecode library isn't the problem in the JSF module, we already
use there our proxy module.

Couldn't we just reuse our @Futureable?
Sure, the handling in the UI would be little bit different (supplierNames
vs supplierNames.get()) but Future should work, right?

Regards,
Thomas



2016-04-09 8:06 GMT+02:00 Christian Beikov <christian.beikov@gmail.com>:

> Hello,
>
> I am implementing some POCs for parallel preloading of named producer
> methods and think I have a working prototype.
> I wanted to know if you are interested in including this into Deltaspike
> and if so, how I should contribute it.
>
> It is separated into two parts, one is the context capturing in one thread
> and the possibility to start these contexts for a new thread.
> The other part is a phase listener that scans the component tree for
> UEL-Expressions that evaluate to a named producer method which is annotated
> with a special interceptor annotation(@PreloadingSafe). These producers are
> then invoked in the before render response phase in parallel. This
> currently works by creating a proxy from the returned interface. The
> invocation handler behind it, just delegates to the result of the future
> that was received by submitting the producer method to an ExecutorService.
> It would be nice if this could also work with non-interface types but that
> would require some bytecode library which I didn't want to introduce yet.
>
> Here some example code:
>
> public class SomeProducerBean {
>
>   @PreloadingSafe
>   @Named
>   @Produces
>   @RequestScoped
>   public List<String> getSupplierNames() { /* Some DB call */ }
>
> }
>
> <html>
> ...
> <ui:repeat value="#{supplierNames}" var="supplName">
>   #{supplName}
> <ui:repeat>
> ...
> </html>
>
> So the rendering until it reaches the ui:repeat runs in parallel to the
> preloading of the supplier names. When the JSF-Component tries the evaluate
> the expression it might need to block. Also note that other expressions
> will still be evaluated in parallel even if one blocks so this can be a
> huge boost for performance.
>
> It's not fully tested yet. The easy case works but I haven't tested more
> complex scenarios or possible threading issues yet.
>
> What do you say?
>
> --
>
> Mit freundlichen Grüßen,
> ------------------------------------------------------------------------
> *Christian Beikov*
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message