[jira] [Updated] (TOMEE-4112) Performance Regression in bean resolution in EAR files

["Richard Zowalla (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TOMEE-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Zowalla updated TOMEE-4112:
-----------------------------------
    Fix Version/s: 9.0.1
                   9.1.0

> Performance Regression in bean resolution in EAR files
> ------------------------------------------------------
>
>                 Key: TOMEE-4112
>                 URL: https://issues.apache.org/jira/browse/TOMEE-4112
>             Project: TomEE
>          Issue Type: Bug
>          Components: TomEE Core Server
>    Affects Versions: 9.0.0.RC1
>            Reporter: Jonathan Gallimore
>            Assignee: Jonathan Gallimore
>            Priority: Major
>             Fix For: 9.0.1, 9.1.0
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> This is an interesting regression:
>  
> If a component in the webapp part of an EAR-based application performs a lookup programmatically to a CDI bean, and that bean belongs to the EJB part of the EAR application, there is some interesting behaviour:
>  
> The InjectionResolver is wrapped by a WebappInjectionResolver. This will attempt to lookup by type in the webapp bean archives. If the bean cannot be resolved here (because it is part of the EJB module), WebappInjectionResolver will then look it up in the parent (which will succeed).
>  
> InjectionResolver caches the lookups, but doesn't cache lookup failures (previously it did). The impact is that each time the lookup happens, WebappInjectionResolver will attempt to resolve (and fail) the bean in the webapp archives first, without looking at the cache. 
> This can lead to a significant performance issue, depending on the number of beans in the archives. I have measure it as 1000 TPS vs 60000 TPS.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)