[ 
https://issues.apache.org/jira/browse/TOMEE-4112?focusedWorklogId=900624&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-900624
 ]

ASF GitHub Bot logged work on TOMEE-4112:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 19/Jan/24 08:24
            Start Date: 19/Jan/24 08:24
    Worklog Time Spent: 10m 
      Work Description: rzo1 commented on PR #973:
URL: https://github.com/apache/tomee/pull/973#issuecomment-1899963001

   @jgallimore Is this still a thing we should add to main?




Issue Time Tracking
-------------------

    Worklog Id:     (was: 900624)
    Time Spent: 0.5h  (was: 20m)

> 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.1.0
>
>          Time Spent: 0.5h
>  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)

Reply via email to