[
https://issues.apache.org/jira/browse/OWB-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14185388#comment-14185388
]
Tobias Stoeckmann commented on OWB-1013:
----------------------------------------
Yeah, race.diff introduces a memory leak.
Unfortunately there are some cases in which these injection points are accessed
in larger code spans. AbstractProducer#isDelegateInjection for example would
access getInjectionPoint() just to see if there is one. It would take all
callers to properly get in sync. As my knowledge of OpenWebBeans is too limited
for this massive task, I would have to fall back to a less intrusive way.
The leak could be fixed by removing the stack when it's empty. Well... the
topic is not an easy one. Even I can tell. ;)
> Race condition in Instance injection
> ------------------------------------
>
> Key: OWB-1013
> URL: https://issues.apache.org/jira/browse/OWB-1013
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Injection and Lookup
> Affects Versions: 1.2.6
> Reporter: Tobias Stoeckmann
> Assignee: Arne Limburg
> Attachments: instance-race.zip, race.diff
>
>
> OpenWebBeans is prone to flip instances of javax.enterprise.inject.Instance
> in multi-threaded environments.
> It is possible for multiple threads to access InstanceProducer at the same
> time with the same creational context. If that happens, it is not verified
> that these threads get the correct injectionPoint out of the injectionPoints
> stack in the shared CreationalContextImpl.
> Please see attached example source (with comments included). It'll require a
> debugger because it's quite tricky to get the threads into proper timing.
> Start main method of class de.cewe.race.Main. It constructs a simple SE
> container and executes two threads which will trigger the issue.
> Set breakpoints at:
> - de.cewe.race.CDIMain, line 46 (System.out.println)
> - org.apache.webbeans.portable.InstanceProducer, line 65 (getInjectionPoint)
> Wait until threads "RunnableA" and "RunnableB" reached the second breakpoint.
> Then let RunnableA finish. It will trigger a ClassCastException. For your own
> convenience, activate the second breakpoint after first one is reached. It
> reduces debugger noise during startup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)