[
https://issues.apache.org/jira/browse/ARTEMIS-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-2566.
------------------------------------
> Thread safety in the Client InitialContext
> ------------------------------------------
>
> Key: ARTEMIS-2566
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2566
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 2.6.4
> Environment: Wildfly 14 on CentOS 7 with a remote Artemis broker
> Reporter: Gregor Tudan
> Assignee: Justin Bertram
> Priority: Major
> Fix For: 2.11.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When injecting a queue from a federated JNDI-Context we sometimes see
> exceptions:
> {noformat}
> Caused by: javax.naming.NamingException: Something already bound at
> PostboxSendMailFromTemplateQueue
> at
> [email protected]//org.apache.activemq.artemis.jndi.ReadOnlyContext.internalBind(ReadOnlyContext.java:158)
> at
> [email protected]//org.apache.activemq.artemis.jndi.LazyCreateContext.lookup(LazyCreateContext.java:33)
> at
> [email protected]//org.apache.activemq.artemis.jndi.ReadOnlyContext.lookup(ReadOnlyContext.java:270)
> at
> [email protected]//org.apache.activemq.artemis.jndi.ReadOnlyContext.lookup(ReadOnlyContext.java:239)
> at
> [email protected]//org.apache.activemq.artemis.jndi.ReadOnlyContext.lookup(ReadOnlyContext.java:270)
> at
> java.naming/javax.naming.InitialContext.lookup(InitialContext.java:413)
> at
> java.naming/javax.naming.InitialContext.lookup(InitialContext.java:413)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> [email protected]//org.jboss.as.naming.ExternalContextObjectFactory$CachedContext.invoke(ExternalContextObjectFactory.java:145)
> at
> [email protected]//javax.naming.InitialContext$$$$Proxy1.lookup(Unknown
> Source)
> at
> [email protected]//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:236)
> at
> [email protected]//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at
> [email protected]//org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:239)
> at
> [email protected]//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at
> [email protected]//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at
> java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)
> at
> java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)
> at
> [email protected]//org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:237)
> at
> [email protected]//org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices$1.createResource(WeldResourceInjectionServices.java:183)
> at
> [email protected]//org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:49)
> at
> [email protected]//org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:63)
> at
> [email protected]//org.jboss.weld.util.Beans.injectEEFields(Beans.java:309)
> at
> [email protected]//org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:68)
> at
> [email protected]//org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at
> [email protected]//org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:71)
> at
> [email protected]//org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:117)
> at
> [email protected]//org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159)
> at
> [email protected]//org.jboss.weld.contexts.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
> at
> [email protected]//org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
> at
> [email protected]//org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> at
> [email protected]//org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:700)
> at
> [email protected]//org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:800)
> at
> [email protected]//org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
> ... 38 more
> {noformat}
> This happens only under heavy load in a simple CDI Bean:
> {code:java}
> class NotificationSender {
> @Resource(lookup =
> "java:global/federation/artemis/dynamicQueues/PostboxMailQueue",
> name = "PostboxMailQueue")
> private Queue queue;
> {code}
> The
> [Javadoc|https://docs.oracle.com/en/java/javase/13/docs/api/java.naming/javax/naming/InitialContext.html]
> of the initial context is quiet clear that it is not guaranteed to be thread
> safe:
> {quote}An InitialContext instance is not synchronized against concurrent
> access by multiple threads. Multiple threads each manipulating a different
> InitialContext instance need not synchronize. Threads that need to access a
> single InitialContext instance concurrently should synchronize amongst
> themselves and provide the necessary locking.
> {quote}
> Since synchronization isn't that easy for non-programmatic lookups, it would
> be cool if the context could handle this at least for simple cases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
