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:21:01 GMT
What about reusing @Futurable on the producer and create a new tag -
something like "ds:preload value=#{supplierNames}", which be placed early
in the content?

2016-04-09 9:18 GMT+02:00 Thomas Andraschko <andraschko.thomas@gmail.com>:

> 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