[jboss-jira] [JBoss JIRA] (WFLY-11601) Weld vs Undertow bootstrap: Race condition

[Stefan Gr (Jira)]

    [ https://issues.jboss.org/browse/WFLY-11601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13742813#comment-13742813 ] 

Stefan Gr commented on WFLY-11601:
----------------------------------

{quote}Non-web modules are handled differently because Weld alone knows when to fire that event. In order to know when do it for web modules, we need the mechanism that we use now - for undertow to tell us basically.{quote}
For web-modules this is done by {{WeldInitialListener#contextInitialized}} which again forwards to {{HttpContextLifecycle#contextInitialized}}. The logic I've described could be implemented in {{HttpContextLifecycle#contextInitialized}} and {{WeldStartup#endInitialization}}. Everything would be inside weld. I don't know if it is possible that one deployment can contain multiple web-modules. But that is also a task that could be handled easily.

So there are two scenarios:
First scenario:
* endInitialization is run first
* lock is aquired to ensure thread safety
* tests if any contextInitialized was already invoked before weld completed (list / map contains servletContext), nothing found
* flag is set to true
* lock is released
* contextIntialized is executed
* lock is aquired to ensure thread safety
* flag is read, flag is true
* lock is released
* event is fired

Second scenario:
* contextInitialied is run first
* lock is aquired to ensure thread safety
* flag is read, flag is false
* servletContext is added to some list / map, associated with the correct bean manager
* lock is released
* endInitialization is executed
* lock is aquired to ensure thread safety
* tests if any contextInitialized was already invoked before weld completed (list / map contains servletContext), found something
* event is fired using the bean manager and servlet context from that map
* lock is released

As i'm new to weld's internal I might have overseen some detail, but in theory that should be a practical solution which:
# does not affect existing code order
# keeps the optimization as it is used by wildfly
# improves reliability

> Weld vs Undertow bootstrap: Race condition
> ------------------------------------------
>
>                 Key: WFLY-11601
>                 URL: https://issues.jboss.org/browse/WFLY-11601
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, Web (Undertow)
>    Affects Versions: 15.0.1.Final
>            Reporter: Stefan Gr
>            Assignee: Matěj Novotný
>            Priority: Major
>         Attachments: TestApp.zip, TestLib.zip, changes.diff, deploy-failed.txt, deploy-mixed-success.txt, deploy-success.txt, test-app-1.0.0.war, weld-core-impl-3.0.5.Final.jar, weld-core-impl-3.0.5.Final.jar
>
>
> WFLY-9732 / WFLY-10784 moves the completion of WELD from the WeldStartService to WeldStartCompetionService. This causes a race condition with the UndertowDeploymentService which executes the servlet listeners for context-initialized which again fires ApplicationScope-initialized events in CDI.
> You can find more in [WELD-2557|https://issues.jboss.org/browse/WELD-2557?focusedCommentId=13682848&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13682848].
> In short: WeldStartCompletionService and UndertowDeploymentService pushes the logic to the executor service. It may happen, that the logik of undertow runs before the weld completion. Events fired in the servlet listeners won't find all event observers.
> A possible solution would bo to set the WeldStartCompletionService as a dependency of the UndertowDeploymentService



--
This message was sent by Atlassian Jira
(v7.12.1#712002)