[
https://issues.redhat.com/browse/WFLY-12836?page=com.atlassian.jira.plugi...
]
Ashley Abdel-Sayed commented on WFLY-12836:
-------------------------------------------
I don't think it would be possible to add a roles field to the SecurityIdentity as
there wouldn't be a way of telling when it should be updated, so I think we need to
stick with mapping everytime getRoles is called. As a lot of the allocations were coming
from creating a HashSet every time here:
https://github.com/wildfly-security/wildfly-elytron/blob/de462529f5c5f49e...,
I tried adding a {{HashMap<Attributes.Entry, HashSet>}} to map the entry to a
HashSet if its already been created. While this did reduce the allocations from creating
the HashSet, this increased the allocations from searching the HashMap more significantly.
This is due to {{HashMap#get}} calling {{MapAttributes#size}} which calls
{{MapAttributes#get}}:
!screenshot-1.png|thumbnail!
Before my changes, the total allocations from this 526KiB for the test I ran.
[~dlofthouse] I was wondering if you had any thoughts or suggestions for this isssue.
Thanks!
Large allocations in EJBContextImpl#isCallerInRole
--------------------------------------------------
Key: WFLY-12836
URL:
https://issues.redhat.com/browse/WFLY-12836
Project: WildFly
Issue Type: Bug
Components: EJB, Security
Affects Versions: 18.0.1.Final
Reporter: Philippe Marschall
Assignee: Ashley Abdel-Sayed
Priority: Major
Attachments: elytron_allocations_redacted.PNG, screenshot-1.png
In our application we have the need to know the roles of the current user. We would like
to do this using Java / Jakarta EE APIs rather than rely on WildFly implementation
classes. We do this by iterating over all roles, which we know statically, and calling
{{EJBContext#isCallerInRole}} for each one. This seem to be a common technique, see [How
to get user roles in a JSP /
Servlet|https://stackoverflow.com/questions/344117/how-to-get-user-roles-...].
That's about 100 roles for us. We were expecting that would be a lookup into a
{{HashMap}} or similar with O(1) complexity and almost no allocations.
This however does not seem to be case as {{EJBContextImpl#isCallerInRole}} seems to do
the role mapping for every call. This results in a large amount of allocations. In our
case this completely dominates our allocation profile. See attached screenshot from JFR.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)