[JBoss JIRA] (WFCORE-1716) JMX domains jboss.as and jboss.as.expr do not always correctly handle propertly list patters in queryMBeans and queryNames
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1716?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1716:
-------------------------------------------------
Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1367784|https://bugzilla.redhat.com/show_bug.cgi?id=1367784] from NEW to ASSIGNED
> JMX domains jboss.as and jboss.as.expr do not always correctly handle propertly list patters in queryMBeans and queryNames
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1716
> URL: https://issues.jboss.org/browse/WFCORE-1716
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha6
>
>
> The ObjectName filtering logic added for WFLY-3161 does not handle queryMBeans and queryNames correctly in some cases where the ObjectName param to the method is a property list pattern (i.e. one that includes a simple '*' at the end of the list of properties, meaning "all other properties besides previous ones whose keys were specifically enumerated, match".)
> The problem occurs when the the ObjectName does specifically include some keys, and those keys don't correspond to the final elements of the related management resource's PathAddress. As the RootResourceIterator walks the management resource tree, ModelControllerMBeanHelper.ObjectNameMatchResourceAction will not identify the parent resources of children that should match as matching, with the result that the iterator will not descend into that part of the tree and the children will not be matched. For example, this query will return an empty set because the /socket-binding-group=standard-sockets parent will not be matched, preventing checks of the socket-binding-group children.
> {code}
> Set<ObjectInstance> instances = connection.queryMBeans(createObjectName("jboss.as:socket-binding=*,*"), null);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2092:
--------------------------------
Hi [~ndillman]
{quote}
We no longer see the issue as it was worked around with staggering responses for all of the "bulk response" messages (ie: view change, etc).
{quote}
This may have reduced the chances of such a scenario happening, but I don't think it eliminated it completely. In my next comment, I'll show how such a scenario can be reproduced.
Yes, a solution will involve a non-coordinator becoming merge leader, but this requires code changes in 3 places: the merge detection, the merge leader determination and the actual merge merge.
> MERGE3: merge never happens
> ---------------------------
>
> Key: JGRP-2092
> URL: https://issues.jboss.org/browse/JGRP-2092
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.txt
>
>
> (Reported by Neal Dillman)
> In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this.
> {noformat}
> Host A view: B, X, Y, Z, A (where B should be coordinator)
> Host B view: C, Q, R, S, B (where C should be coordinator)
> Host C view: A, M, N, O, C (where A should be coordinator)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1795) :query() operation fails with IllegalArgumentException when specifying a where parameter
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1795?page=com.atlassian.jira.plugi... ]
Harald Pehl updated WFCORE-1795:
--------------------------------
Summary: :query() operation fails with IllegalArgumentException when specifying a where parameter (was: :query operation fails with IllegalArgumentException when specifying a where parameter)
> :query() operation fails with IllegalArgumentException when specifying a where parameter
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-1795
> URL: https://issues.jboss.org/browse/WFCORE-1795
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Reporter: Harald Pehl
> Assignee: Alexey Loubyansky
>
> This operation works in WFLY 10:
> {code}
> /host=*/server=*:query(select=["name"],where={"server-group" = "main-server-group"})
> {code}
> whereas it fails with an IllegalArgumentException in WFLY 11
> Without the {{where}} parameter the operation works.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1795) :query operation fails with IllegalArgumentException when specifying a where parameter
by Harald Pehl (JIRA)
Harald Pehl created WFCORE-1795:
-----------------------------------
Summary: :query operation fails with IllegalArgumentException when specifying a where parameter
Key: WFCORE-1795
URL: https://issues.jboss.org/browse/WFCORE-1795
Project: WildFly Core
Issue Type: Feature Request
Components: CLI, Domain Management
Reporter: Harald Pehl
Assignee: Alexey Loubyansky
This operation works in WFLY 10:
{code}
/host=*/server=*:query(select=["name"],where={"server-group" = "main-server-group"})
{code}
whereas it fails with an IllegalArgumentException in WFLY 11
Without the {{where}} parameter the operation works.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1794) AttachmentHandler, handle invalid options and batch steps handling.
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-1794:
--------------------------------------------
Summary: AttachmentHandler, handle invalid options and batch steps handling.
Key: WFCORE-1794
URL: https://issues.jboss.org/browse/WFCORE-1794
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
The step number is not incremented. This makes the attachment command to behave strangely. As described in EAP7-602.
The file and overwrite options should be rejected for display. As described in EAP7-602 too.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7104) Elytron properties-realm enforces REALM_NAME comment
by Josef Cacek (JIRA)
Josef Cacek created WFLY-7104:
---------------------------------
Summary: Elytron properties-realm enforces REALM_NAME comment
Key: WFLY-7104
URL: https://issues.jboss.org/browse/WFLY-7104
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Josef Cacek
Assignee: Darran Lofthouse
Elytron enforces existence of {{"#$REALM_NAME=...$"}} comment in property file referenced from properties-realms.
When using legacy security and this line is missing, server starts without error.
*Expected behavior:*
Elytron's properties-realm *doesn't require* this comment. If the comment is present, it *may* verify if its content fits the realm name.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1285) NPE caused by forced flushing of unlinked path in stream mode
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-1285:
-----------------------------------
Summary: NPE caused by forced flushing of unlinked path in stream mode
Key: DROOLS-1285
URL: https://issues.jboss.org/browse/DROOLS-1285
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Mario Fusco
Assignee: Mario Fusco
In stream mode it is necessary to enforce flushing of path memories. However doing this on an unlinked path is a waste of time and moreover can causes a NPE in presence of a subnetwork like the following:
{code}
java.lang.NullPointerException
at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:725)
at org.drools.core.phreak.RuleNetworkEvaluator.unlinkAndDeleteChildLeftTuple(RuleNetworkEvaluator.java:718)
at org.drools.core.phreak.PhreakJoinNode.doLeftDeletes(PhreakJoinNode.java:418)
at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:47)
at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:519)
at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:505)
at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341)
at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301)
at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:573)
at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:500)
at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341)
at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301)
at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136)
at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94)
at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:969)
at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1311)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1250)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1356)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1347)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1328)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6989) Java deadlock with IdleRemover thread
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-6989?page=com.atlassian.jira.plugin.... ]
Stefano Maestri resolved WFLY-6989.
-----------------------------------
Resolution: Duplicate Issue
[~simkam] is right. Closing as duplicate issue
> Java deadlock with IdleRemover thread
> -------------------------------------
>
> Key: WFLY-6989
> URL: https://issues.jboss.org/browse/WFLY-6989
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.Final
> Environment: Java 8 b102 64-bit on Linux
> Using Oracle 12.c with Oracle thin client drivers.
> Reporter: David Rothenberger
> Assignee: Stefano Maestri
>
> We have had two Java deadlock issues involving the IdleRemover thread.
> We are using the following datasource definition:
> Data source definition:
> {code:xml}
> <datasource jndi-name="java:/EntomoNonTxDS" pool-name="EntomoNonTxDS" enabled="true" use-java-context="true">
> <connection-url>jdbc:oracle:thin:@//somehost:1541/somethingelse</connection-url>
> <driver>ojdbc6.jar</driver>
> <pool>
> <max-pool-size>200</max-pool-size>
> <allow-multiple-users>true</allow-multiple-users>
> </pool>
> <timeout>
> <idle-timeout-minutes>5</idle-timeout-minutes>
> </timeout>
> <validation>
> <validate-on-match>true</validate-on-match>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/>
> <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/>
> </validation>
> </datasource>
> {code}
> The information from Java relevant to the deadlock:
> {noformat}
> Found one Java-level deadlock:
> =============================
> "WorkflowMgr":
> waiting for ownable synchronizer 0x00000002d37eb7f0, (a java.util.concurrent.locks.ReentrantLock$FairSync),
> which is held by "IdleRemover"
> "IdleRemover":
> waiting to lock monitor 0x00007eff4c0a80e8 (object 0x00000002d280e6f0, a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri),
> which is held by "WorkflowMgr"
> "WorkflowMgr":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000002d37eb7f0> (a java.util.concurrent.locks.ReentrantLock$FairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover.internalRegisterPool(IdleRemover.java:184)
> at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover.registerPool(IdleRemover.java:166)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.initialize(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:184)
> at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.init(ManagedConnectionPoolFactory.java:191)
> at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.create(ManagedConnectionPoolFactory.java:173)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getManagedConnectionPool(AbstractPool.java:306)
> - locked <0x00000002d280e6f0> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:590)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:162)
> at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:73)
> ...
> "IdleRemover":
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.emptyManagedConnectionPool(AbstractPool.java:454)
> - waiting to lock <0x00000002d280e6f0> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.removeIdleConnections(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1034)
> at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner.run(IdleRemover.java:275)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months