[
https://issues.apache.org/jira/browse/TOMEE-4112?focusedWorklogId=826799&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-826799
]
ASF GitHub Bot logged work on TOMEE-4112:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 17/Nov/22 10:26
Start Date: 17/Nov/22 10:26
Worklog Time Spent: 10m
Work Description: jgallimore opened a new pull request, #971:
URL: https://github.com/apache/tomee/pull/971
This PR introduces an optional (and by default it is OFF) cache for
resolution failures in WebappInjectionResolver, to address a regression since
1.7.x which will potentially have a performance impact on EAR applications.
Issue Time Tracking
-------------------
Worklog Id: (was: 826799)
Remaining Estimate: 0h
Time Spent: 10m
> 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
> Reporter: Jonathan Gallimore
> Assignee: Jonathan Gallimore
> Priority: Major
> Time Spent: 10m
> 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)
