[JBoss JIRA] (WFLY-6898) ConcurrentModificationException when returning from JMS onMessage() MBean
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6898?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-6898:
-----------------------------------
Issue Type: Bug (was: Feature Request)
> ConcurrentModificationException when returning from JMS onMessage() MBean
> -------------------------------------------------------------------------
>
> Key: WFLY-6898
> URL: https://issues.jboss.org/browse/WFLY-6898
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.1.0.CR1
> Reporter: Harold Campbell
> Assignee: Stuart Douglas
>
> I receive the following stacktrace when an MBean's onMessage() returns. The transaction is rolled back and the message marked as undelivered. This started sometime after nightly #2280 which works fine for me.
> 2016-07-30 21:51:49,273 TRACE [com.envestnet.ejb.winthorpe.optimizer.WinthorpeRunListener] (Thread-0 (ActiveMQ-client-global-threads-556320704)) Finished processing run 16819
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:159)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$5$1.processInvocation(MessageDrivenComponentDescription.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> at com.envestnet.ejb.winthorpe.optimizer.WinthorpeRunListener$$$view3.onMessage(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:139)
> at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
> at com.envestnet.ejb.winthorpe.optimizer.WinthorpeRunListener$$$endpoint1.onMessage(Unknown Source)
> at org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:310)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1018)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:48)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1145)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:103)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
> at org.jboss.weld.context.AbstractContext.destroy(AbstractContext.java:160)
> at org.jboss.weld.context.AbstractManagedContext.deactivate(AbstractManagedContext.java:58)
> at org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:72)
> at org.jboss.weld.context.ejb.EjbRequestContextImpl.deactivate(EjbRequestContextImpl.java:47)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:76)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-6897) Replacing a disabled deployment destroys profile section of xml config
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6897?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-6897.
------------------------------------
Fix Version/s: 10.1.0.CR1
Assignee: Brian Stansberry (was: Jason Greene)
Resolution: Done
The WFCORE-1577 fix is in WildFly 10.1.0.CR1.
> Replacing a disabled deployment destroys profile section of xml config
> ----------------------------------------------------------------------
>
> Key: WFLY-6897
> URL: https://issues.jboss.org/browse/WFLY-6897
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.Final
> Environment: Fresh install of Wildfly 10 on Ubuntu 15.10 / JDK 8_101
> Reporter: Brian Rozmierski
> Assignee: Brian Stansberry
> Fix For: 10.1.0.CR1
>
>
> When replacing a deployment that is disabled at the time of replacement, Wildfly will write out a new configuration .xml that is missing the entire <profile> section, resulting in an application server that is, essentially, non-functional once restarted. There is no obvious effect until restart.
> Also note there is a forum post reporting this behavior from April.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1680) Tab completion for echo-dmr command is broken
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1680?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise edited comment on WFCORE-1680 at 8/1/16 9:16 AM:
----------------------------------------------------------------------
Looking at the src code, it seems that deployment-overlay, echo-dmr, batch-edit-line, if commands are passing a cursor value of 0.
OperationRequestCompleter and CommandCompleter are possibly impacted too.
was (Author: jdenise):
Looking at the src code, it seems that deployment-overlay, echo-dmr, batch-edit-line, if commands are passing a cursor value of 0.
OperationRequestCompleter is possibly impacted too.
> Tab completion for echo-dmr command is broken
> ---------------------------------------------
>
> Key: WFCORE-1680
> URL: https://issues.jboss.org/browse/WFCORE-1680
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Jean-Francois Denise
>
> Tab completion for echo-dmr command doesn't work.
> To reproduce, start the standalone server and connect with CLI
> *actual 3.0.0.Alpha5-SNAPSHOT 77673c5*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> {noformat}
> *expected*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=logging
> {noformat}
> The issue is not reproducible with 2.2.0.CR7 (EAP 7.1.0.DR1).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1680) Tab completion for echo-dmr command is broken
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1680?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1680:
----------------------------------------------
Looking at the src code, it seems that deployment-overlay, echo-dmr, batch-edit-line, if commands are passing a cursor value of 0.
OperationRequestCompleter is possibly impacted too.
> Tab completion for echo-dmr command is broken
> ---------------------------------------------
>
> Key: WFCORE-1680
> URL: https://issues.jboss.org/browse/WFCORE-1680
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Jean-Francois Denise
>
> Tab completion for echo-dmr command doesn't work.
> To reproduce, start the standalone server and connect with CLI
> *actual 3.0.0.Alpha5-SNAPSHOT 77673c5*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> {noformat}
> *expected*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=logging
> {noformat}
> The issue is not reproducible with 2.2.0.CR7 (EAP 7.1.0.DR1).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1682:
----------------------------------------------
WFCORE-1487 was logged and fixed in order to change the behaviour of completion to expose unnamed internal property name. So what you are observing seems the new expected behaviour.
I also think that it is misleading.
> Missleading tab completion for edit-batch-line command
> ------------------------------------------------------
>
> Key: WFCORE-1682
> URL: https://issues.jboss.org/browse/WFCORE-1682
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works.
> *command usage*
> {noformat}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] :read-resource
> [standalone@localhost:9990 / #] list-batch
> #1 /:read-resource
> [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type)
> #1 :read-attribute(name=launch-type)
> [standalone@localhost:9990 / #] list-batch
> #1 :read-attribute(name=launch-type)
> {noformat}
> *actual*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> [standalone@localhost:9990 / #] edit-batch-line --<TAB>
> --help --line-number
> [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type)
> Failed to parse line number '--line-number=1': For input string: "--line-number=1"
> {noformat}
> {{--line-number}} shouldn't be offered by tab completion for the command.
> Misleading tab completion ends up with syntax error.
> *expected*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> --help
> {noformat}
> The issue is a regression against EAP 7.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (DROOLS-414) Queries do not work with chained accessors as arguments
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-414?page=com.atlassian.jira.plugin... ]
Mario Fusco updated DROOLS-414:
-------------------------------
Priority: Critical (was: Major)
> Queries do not work with chained accessors as arguments
> -------------------------------------------------------
>
> Key: DROOLS-414
> URL: https://issues.jboss.org/browse/DROOLS-414
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 5.5.0.Final, 6.0.1.Final
> Reporter: Davide Sottara
> Assignee: Mario Fusco
> Priority: Critical
>
> When processing a query CE that uses chained property accessors:
> when
> $x : Foo()
> myQuery( $x.bar ; )
> then
> the QueryElementBuilder considers the whole expression $x.bar as a variable. Since no variable with that name has been bound, it is taken to be a new declaration, and thus an output. This results in an inconsistent behavior, since an obvious constraint will be ignored.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-2845) On WildFly clean shutdown: failed marshalling rsp (UnsuccessfulResponse)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2845?page=com.atlassian.jira.plugin.... ]
Radoslav Husar closed WFLY-2845.
--------------------------------
Resolution: Out of Date
> On WildFly clean shutdown: failed marshalling rsp (UnsuccessfulResponse)
> ------------------------------------------------------------------------
>
> Key: WFLY-2845
> URL: https://issues.jboss.org/browse/WFLY-2845
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.CR1
> Environment: RHEL6 x86_64; Oracle JDK 7
> Reporter: Michal Karm Babacek
> Assignee: Paul Ferraro
> Labels: clustering
> Fix For: 10.1.0.Final
>
>
> I've got two standalone-ha instances running on a one box. Each of these instances has {{<distributable/>}} [clusterbench|https://github.com/Karm/clusterbench/tree/simplified-and-pure] app deployed. When I start to shut the instances down via CLI command, one of them throws:
> {noformat}
> 08:59:33,341 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,shared=udp) ISPN000094: Received new cluster view: [jboss-eap-8.0/web|4] (1) [jboss-eap-8.0/web]
> 08:59:33,368 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher
> 08:59:33,379 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-0) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
> 08:59:33,380 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-1) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
> 08:59:33,392 INFO [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 558ms
> {noformat}
> In the log. It's a non-deterministic problem and it does not emerge always.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ]
Petr Kremensky commented on WFCORE-1682:
----------------------------------------
Tab completion for {{if}} command is affected as well
{noformat}
[domain@10.16.179.18:9990 /] if --<TAB>
--condition --help
{noformat}
however {{--condition}} is a not valid argument for the command
{noformat}
ARGUMENTS
--help - prints this description.
command_line - CLI command or an operation whose response
should be evaluated to determine which
block of the if-else should be executed next;
condition_expression - an expression that evaluates the response
and based on which the next block of the
if-else control flow to be executed is chosen.
{noformat}
> Missleading tab completion for edit-batch-line command
> ------------------------------------------------------
>
> Key: WFCORE-1682
> URL: https://issues.jboss.org/browse/WFCORE-1682
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works.
> *command usage*
> {noformat}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] :read-resource
> [standalone@localhost:9990 / #] list-batch
> #1 /:read-resource
> [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type)
> #1 :read-attribute(name=launch-type)
> [standalone@localhost:9990 / #] list-batch
> #1 :read-attribute(name=launch-type)
> {noformat}
> *actual*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> [standalone@localhost:9990 / #] edit-batch-line --<TAB>
> --help --line-number
> [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type)
> Failed to parse line number '--line-number=1': For input string: "--line-number=1"
> {noformat}
> {{--line-number}} shouldn't be offered by tab completion for the command.
> Misleading tab completion ends up with syntax error.
> *expected*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> --help
> {noformat}
> The issue is a regression against EAP 7.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months