September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9305) ActiveMQ Resource Adapter can not lookup destination in app namespace

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-9305?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFLY-9305: ----------------------------------- There is no issue with binding the JMS destination in the app namespace. The issue is that when the ActiveMQ RA is activated, it attempts to lookup the destination but its JNDI context is not aware of the app namespace. I don't understand the full issue yet but it seems to me that the underlying cause is that work performed by the resource adapter when a deployment is installed is not using the correct JNDI context selector . It is using the *default* JNDI context selector (that is set in org.jboss.as.naming.service.DefaultNamespaceContextSelectorService#start) instead of the one relevant to deployment (org.jboss.as.ee.naming.InjectedEENamespaceContextSelector) This selector can be pushed/popped appropriately by deployments that use the JavaNamespaceSetup action (attached to Attachments.JAVA_NAMESPACE_SETUP_ACTION). However it is not clear to me who and where should setup this JavaNamespaceSetup when a MDB is deployed. When the MDB is activated (org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent#activate), it calls endpoint.activate() that calls Artemis' org.apache.activemq.artemis.ra.inflow.ActiveMQActivation#start method. This method will then schedule JCA work to run its SetupActivation Work that is responsible to look up the resources in JNDI. Ultimately, the thread executing this code is owned by IronJacamar and it is on this thread that we should push/pop the namespaceContextSelector. the connector subsystem defines a WildflyWorkWrapper that would be the correct place to put the push/pop calls... However I have no idea how to pass the correct InjectedEENamespaceContextSelector to this class. TL;DR when a MDB is activated (in org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent#activate), I can get the correct namespaceContextSelector but I have no idea how to pass it to the IJ WorkManager so that Artemis' SetupActivation work is run with it. [~maeste] Do you have an idea about this? > ActiveMQ Resource Adapter can not lookup destination in app namespace > --------------------------------------------------------------------- > > Key: WFLY-9305 > URL: https://issues.jboss.org/browse/WFLY-9305 > Project: WildFly > Issue Type: Bug > Components: JMS, Naming > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > When using JMSDefinition defining a non-global JNDI name, Queue/Topic isn't created and MDB listening to those won't read incoming messages. > Example using non global JNDI (this doesn't work (x) ): > {code:java} > @JMSDestinationDefinition( > name = "java:app/jms/queue", > interfaceName = "javax.jms.Queue" > ) > {code} > Example using global JNDI (this works (/)): > {code:java} > @JMSDestinationDefinition( > name = "java:/app/jms/queue", > interfaceName = "javax.jms.Queue" > ) > {code} > When using the non-global JNDI and deploying, a message like this can be seen: > {noformat} > 13:20:15,542 INFO [org.apache.activemq.artemis.ra] (default-threads - 2) AMQ151001: Attempting to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.apache.activemq.artemis.ra.ActiveMQResourceAdapter@78712571 destination=java:app/jms/queue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15) > {noformat} > and creating an MDB to listen sent messages won't receive any. > Attached a reproducer WAR Maven project. Just deploy, access index.xhtml, click on "Test" button and check logs. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8929) Race condition if timers overlap due to long running execution and short schedules if database persistence is used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-8929?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-8929: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1461416|https://bugzilla.redhat.com/show_bug.cgi?id=1461416] from VERIFIED to CLOSED > Race condition if timers overlap due to long running execution and short schedules if database persistence is used > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-8929 > URL: https://issues.jboss.org/browse/WFLY-8929 > Project: WildFly > Issue Type: Bug > Components: EJB > Environment: Configure DB persistence for timers as file-persistence will not have a persistence check for shouldRun to lock the timer execution. > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Fix For: 11.0.0.Beta1 > > Attachments: server-extract.log, server1.log > > > If timers (here calendar timer) are running longer than scheduled, or the schedule/processing get stuck do to thread or cpu bottleneck, it is possible that the updates for persistence overlap. > The issue seems that the task(1) try to finish the timer and task(2) is about to start but see the concurrency. > The DB is updated with the 'old' next timeout, but the internal Timer instance will be updated with the next possible schedule due to a race condition between the two threads updating the object. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9305) ActiveMQ Resource Adapter can not lookup destination in app namespace

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-9305?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-9305: ------------------------------ Component/s: JCA > ActiveMQ Resource Adapter can not lookup destination in app namespace > --------------------------------------------------------------------- > > Key: WFLY-9305 > URL: https://issues.jboss.org/browse/WFLY-9305 > Project: WildFly > Issue Type: Bug > Components: JCA, JMS, Naming > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > When using JMSDefinition defining a non-global JNDI name, Queue/Topic isn't created and MDB listening to those won't read incoming messages. > Example using non global JNDI (this doesn't work (x) ): > {code:java} > @JMSDestinationDefinition( > name = "java:app/jms/queue", > interfaceName = "javax.jms.Queue" > ) > {code} > Example using global JNDI (this works (/)): > {code:java} > @JMSDestinationDefinition( > name = "java:/app/jms/queue", > interfaceName = "javax.jms.Queue" > ) > {code} > When using the non-global JNDI and deploying, a message like this can be seen: > {noformat} > 13:20:15,542 INFO [org.apache.activemq.artemis.ra] (default-threads - 2) AMQ151001: Attempting to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.apache.activemq.artemis.ra.ActiveMQResourceAdapter@78712571 destination=java:app/jms/queue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15) > {noformat} > and creating an MDB to listen sent messages won't receive any. > Attached a reproducer WAR Maven project. Just deploy, access index.xhtml, click on "Test" button and check logs. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1080) MDC is lost during @Asynchronous EJB calls

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1080?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1080: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1464134|https://bugzilla.redhat.com/show_bug.cgi?id=1464134] from VERIFIED to CLOSED > MDC is lost during @Asynchronous EJB calls > ------------------------------------------ > > Key: WFLY-1080 > URL: https://issues.jboss.org/browse/WFLY-1080 > Project: WildFly > Issue Type: Feature Request > Components: Logging > Reporter: Patrick Ruckstuhl > Assignee: David Lloyd > Fix For: 8.0.0.Alpha2 > > > If I set a variable into the MDC, this is propagated fine through to synchronous EJB calls, but is lost in asynchronous EJB calls. > Should the MDC not be copied over to the thread retrieved from the thread pool? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2916) JMX client hangs when closing an unresponsive connection

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2916?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-2916: ------------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1454564|https://bugzilla.redhat.com/show_bug.cgi?id=1454564] from VERIFIED to CLOSED > JMX client hangs when closing an unresponsive connection > -------------------------------------------------------- > > Key: WFCORE-2916 > URL: https://issues.jboss.org/browse/WFCORE-2916 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Petr Jurak > Assignee: Petr Jurak > Fix For: 3.0.0.Beta25 > > Attachments: reproducer-wfcore-2916.zip > > > When JMX client close the connection via remoting socket, the client waits for a long time by unresponsive connection/server. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2154) Enhance CLI logging

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2154?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2154: ------------------------------------- Issue Type: Enhancement (was: Bug) > Enhance CLI logging > ------------------- > > Key: WFCORE-2154 > URL: https://issues.jboss.org/browse/WFCORE-2154 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Martin Stefanko > > When debugging complex use cases, the current level of CLI logging is weak. Furthermore aesh 0.66.x does handle logs in a custom way that can't be enabled from cli logging config file. > I plan to fix that once we are have aesh-readline in. > - aesh-readline logging is pure JUL, so can be enabled from CLI > - CLI config file will be updated to have aesh logger enabled. > - New traces will be added to CLI. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2154) Enhance CLI logging

by Martin Stefanko (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2154?page=com.atlassian.jira.plugi... ] Martin Stefanko reassigned WFCORE-2154: --------------------------------------- Assignee: Martin Stefanko (was: Jean-Francois Denise) > Enhance CLI logging > ------------------- > > Key: WFCORE-2154 > URL: https://issues.jboss.org/browse/WFCORE-2154 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Martin Stefanko > > When debugging complex use cases, the current level of CLI logging is weak. Furthermore aesh 0.66.x does handle logs in a custom way that can't be enabled from cli logging config file. > I plan to fix that once we are have aesh-readline in. > - aesh-readline logging is pure JUL, so can be enabled from CLI > - CLI config file will be updated to have aesh logger enabled. > - New traces will be added to CLI. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2216) IllegalFormatException in DefaultDNSResolver#getDnsContext()

by Johan Vogelzang (JIRA)

Johan Vogelzang created JGRP-2216: ------------------------------------- Summary: IllegalFormatException in DefaultDNSResolver#getDnsContext() Key: JGRP-2216 URL: https://issues.jboss.org/browse/JGRP-2216 Project: JGroups Issue Type: Bug Affects Versions: 4.0.5, 3.6.10 Reporter: Johan Vogelzang Assignee: Bela Ban An IllegalFormatException is thrown at: DefaultDNSResolver#getDnsContext() {code} log.trace("Initializing DNS Context with factory: %s and url: %s" + dnsContextFactory, dnsAddress); {code} should be: {code} log.trace("Initializing DNS Context with factory: %s and url: %s", dnsContextFactory, dnsAddress); {code} plus sign changed in to comma. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1717) Concurrency problems with enum constraints in MVEL

by Kris Verlaenen (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1717?page=com.atlassian.jira.plugi... ] Kris Verlaenen updated DROOLS-1717: ----------------------------------- Sprint: 2017 Week 34-35, 2017 Week 36-37 (was: 2017 Week 34-35) > Concurrency problems with enum constraints in MVEL > -------------------------------------------------- > > Key: DROOLS-1717 > URL: https://issues.jboss.org/browse/DROOLS-1717 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.2.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Labels: concurrency > > Having a test case like this [1], it sometimes fails on > java.lang.RuntimeException: java.util.concurrent.ExecutionException: [Error: unable to resolve method using strict-mode: org.drools.compiler.integrationtests.facts.FactWithEnum.AnEnum()] > [Near : {... enumValue == AnEnum.SECOND ....}] > ... see here [2]. When using direct imports that are commented out in the pasted example, I see very rarely also a ClassCastException. See stacktrace here [3]. > Tested with mvel 2.2.8 on 6.5.x branch, 2.3.0 and 2.3.1 on master branch. > [1] https://gist.github.com/baldimir/d0f5f21d5b1a383887c5ebfb6013e5af > [2] https://gist.github.com/baldimir/da5c9cb23fab2eae1576948c8ca2a4c8 > [3] https://gist.github.com/baldimir/72eafe3909c21e25265cd3ee9a731d8e -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1715) Running DMN evaluation in parallel causes a ConcurrentModificationException

by Kris Verlaenen (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1715?page=com.atlassian.jira.plugi... ] Kris Verlaenen updated DROOLS-1715: ----------------------------------- Sprint: 2017 Week 34-35, 2017 Week 36-37 (was: 2017 Week 34-35) > Running DMN evaluation in parallel causes a ConcurrentModificationException > --------------------------------------------------------------------------- > > Key: DROOLS-1715 > URL: https://issues.jboss.org/browse/DROOLS-1715 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.2.0.Final > Reporter: David Le Moing > Assignee: Matteo Mortari > > When launching some Parameterized tests in parallel, I noticed that I was not getting any answer (it works with only 1 thread). When I started digging, I found that the cause was a ConcurrentModificationException thrown when iterating over events in the processEvents method of DMNDTExpressionEvaluator. > {code} > at java.util.ConcurrentModificationException.<init>(ConcurrentModificationException.java:78) > at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901) > at java.util.ArrayList$Itr.next(ArrayList.java:851) > at org.kie.dmn.core.ast.DMNDTExpressionEvaluator.processEvents(DMNDTExpressionEvaluator.java:101) > at org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(DMNDTExpressionEvaluator.java:92) > at org.kie.dmn.core.impl.DMNRuntimeImpl.evaluateDecision(DMNRuntimeImpl.java:337) > at org.kie.dmn.core.impl.DMNRuntimeImpl.evaluateAll(DMNRuntimeImpl.java:92) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2017