[JBoss JIRA] (JGRP-1613) FORK: cactus stacks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1613?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1613:
--------------------------------
Hmm... Are your components going to be created on *all* cluster nodes ? COUNTER and CENTRAL_LOCK require a coordinator to maintain cluster wide unique counters / locks. However, if we have view \{A,B,C,D\} where A's the coordinator, but the components is only created on B and D, then COUNTER / CENTRAL_LOCK won't work as they send their requests to A, which is the same as to /dev/null as the component isn't running on A...
> FORK: cactus stacks
> -------------------
>
> Key: JGRP-1613
> URL: https://issues.jboss.org/browse/JGRP-1613
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: IMAG0129.jpg
>
>
> Introduce cactus stacks where we can have multiple, different, stacks grafted onto the same base stack.
> The problem today is that different applications need different functionality (protocol stack configs) in the AS. For example, we have the default stack used by AS. Then, Hibernate Search wants to use distributed locking (CENTRAL_LOCK) and counting (COUNTER). The total order stack wants to use TOA/SEQUENCER and so on.
> Cactus stacks add the ability to:
> * Provide custom (partial) stacks that are grafted onto a base stack
> * Add/remove stacks at runtime
> See the attached picture for details.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (DROOLS-206) Deadlock between AbstractWorkingMemory and DefaultAgenda
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-206?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-206.
--------------------------------
Fix Version/s: 5.5.1.Final
6.0.0.CR2
Resolution: Done
> Deadlock between AbstractWorkingMemory and DefaultAgenda
> --------------------------------------------------------
>
> Key: DROOLS-206
> URL: https://issues.jboss.org/browse/DROOLS-206
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Reporter: Winfried Umbrath
> Assignee: Mario Fusco
> Fix For: 5.5.1.Final, 6.0.0.CR2
>
> Attachments: jbrules-3700-test.tgz
>
>
> I experienced a deadlock when running in STREAM mode and using negative patterns with temporal constraints.
> When the rule gets fired by the installed timer job and at the same time another thread is firing rules, a deadlock can occur:
> 1. [rule firing thread] StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:820)
> acquires lock in AbstractWorkingMemory
> 2. [timer-thread] DefaultAgenda.fireActivation()
> call of synchronized method
> 3. [rule firing thread] DefaultAgenda.fireActivation()
> synchronized method, wait for other thread to exit synchornized method
> 4. [timer-thread] AbstractWorkingMemory.getGlobal()
> tries to access a global, tries to acquire lock in AbstractWorkingMemory which is held by the other thread
> --> Deadlock
> Excerpt from thread dump:
> "http-thread-pool-8082(374)":
> at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1264)
> - waiting to lock <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
> at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
> at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
> at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:679)
> at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:234)
> at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:102)
> at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:32)
> at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:155)
> at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:76)
> at org.drools.impl.StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:821)
> "pool-4251-thread-1":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for 0x00007f503fc71a20> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
> at org.drools.common.AbstractWorkingMemory.getGlobal(AbstractWorkingMemory.java:634)
> at myrules.Rule_ruleWithTimeout_ece4a3c9fc2741a4ab97a92b77611203DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
> - locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> at org.drools.common.DefaultAgenda.fireTimedActivation(DefaultAgenda.java:1344)
> - locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:83)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (JGRP-1669) UDP should not stop message receiver thread after SocketException is caught
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1669?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1669:
--------------------------------
Hi Aleksandr,
sorry, but 2.12.x is not officially maintained anymore.
Can't you make that change in your own private repo and build a 2.12.x release yourself ?
> UDP should not stop message receiver thread after SocketException is caught
> ---------------------------------------------------------------------------
>
> Key: JGRP-1669
> URL: https://issues.jboss.org/browse/JGRP-1669
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 2.6.13
> Environment: Windows 2008 R2, Oracle JDK 1.6.0.24
> Reporter: Aleksandr Korostov
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> One of our customers is getting the following error sporadically:
> {code}
> java.net.SocketException: socket closed
> at java.net.PlainDatagramSocketImpl.receive0(Native Method)
> at java.net.PlainDatagramSocketImpl.receive(Unknown Source)
> at java.net.DatagramSocket.receive(Unknown Source)
> at org.jgroups.protocols.UDP.run(UDP.java:262)
> at java.lang.Thread.run(Unknown Source)
> {code}
> (note that I modified UPD class to log the full stack trace because this stack trace was not logged by original version of UDP)
> I'm sure that socket was not closed by any Java code, the sender thread keeps running and sending messages via the same socket (if mcast_socket.close() had been called, the mcast_socket.send() would have thrown "socket closed" exception too but it did not).
> The main problem that this error stops the receiver thread so node stops receiving UDP messages from other nodes in the cluster.
> We cannot reproduce the error in our environment but I found cases of similar problem on the Internet:
> * https://forums.oracle.com/thread/2190450 (read the last post). It looks like Time-to-live-exceeded ICMP packet could force such an error on the multicast socket.
> * https://github.com/elasticsearch/elasticsearch/pull/2783 Here this problem was faced but the devs did not manage to find the root cause so they ended up implementing socket re-creation on error
> Given all that I think that UDP receiver thread should check mcast_socket.isClosed() before exiting. If socket is still open the thread should continue running (it may be safer to close the old socket and create a new one though)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (DROOLS-206) Deadlock between AbstractWorkingMemory and DefaultAgenda
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-206?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-206:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> Deadlock between AbstractWorkingMemory and DefaultAgenda
> --------------------------------------------------------
>
> Key: DROOLS-206
> URL: https://issues.jboss.org/browse/DROOLS-206
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Reporter: Winfried Umbrath
> Assignee: Mario Fusco
> Attachments: jbrules-3700-test.tgz
>
>
> I experienced a deadlock when running in STREAM mode and using negative patterns with temporal constraints.
> When the rule gets fired by the installed timer job and at the same time another thread is firing rules, a deadlock can occur:
> 1. [rule firing thread] StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:820)
> acquires lock in AbstractWorkingMemory
> 2. [timer-thread] DefaultAgenda.fireActivation()
> call of synchronized method
> 3. [rule firing thread] DefaultAgenda.fireActivation()
> synchronized method, wait for other thread to exit synchornized method
> 4. [timer-thread] AbstractWorkingMemory.getGlobal()
> tries to access a global, tries to acquire lock in AbstractWorkingMemory which is held by the other thread
> --> Deadlock
> Excerpt from thread dump:
> "http-thread-pool-8082(374)":
> at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1264)
> - waiting to lock <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
> at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
> at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
> at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:679)
> at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:234)
> at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:102)
> at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:32)
> at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:155)
> at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:76)
> at org.drools.impl.StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:821)
> "pool-4251-thread-1":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for 0x00007f503fc71a20> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
> at org.drools.common.AbstractWorkingMemory.getGlobal(AbstractWorkingMemory.java:634)
> at myrules.Rule_ruleWithTimeout_ece4a3c9fc2741a4ab97a92b77611203DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
> - locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> at org.drools.common.DefaultAgenda.fireTimedActivation(DefaultAgenda.java:1344)
> - locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:83)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (WFLY-1809) The security subsystem plugins use deprecated Infinispan API
by Tristan Tarrant (JIRA)
Tristan Tarrant created WFLY-1809:
-------------------------------------
Summary: The security subsystem plugins use deprecated Infinispan API
Key: WFLY-1809
URL: https://issues.jboss.org/browse/WFLY-1809
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 8.0.0.Alpha3
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Priority: Blocker
Fix For: 8.0.0.Final
org.jboss.as.security.plugins.JNDIBasedSecurityManagement uses a deprecated way of configuring an Infinispan cache which must be removed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (WFLY-1796) Creating a pooled-connection-factory via the CLI requires confusing syntax
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-1796?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-1796:
-----------------------------------
The use of a map for the connectors is for backwards compatibility.
A previous version of HornetQ was requiring to defining a tuple of live/backup connectors. That's why AS7 (and now WildFly) uses a map representation for its connectors attribute.
Then, it was changed in HornetQ and only a list of connectors was required. But we could not change the format of the pooled-connection-factory:add operation or the older clients would not be able to work anymore.
I'll check whether we can transform the operation if a list is passed to a map (with undefined values) but I am not sure that this functionality is available in WildFly.
> Creating a pooled-connection-factory via the CLI requires confusing syntax
> --------------------------------------------------------------------------
>
> Key: WFLY-1796
> URL: https://issues.jboss.org/browse/WFLY-1796
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 8.0.0.Alpha3
> Reporter: Justin Bertram
> Assignee: Jeff Mesnil
>
> When creating a pooled-connection factory via the CLI the syntax for the "connector" is confusing. Here is a simple example:
> {noformat}
> /subsystem=messaging/hornetq-server=default/pooled-connection-factory=my-pooled-connection-factory/:add(connector={"in-vm" => "xyz"}, entries=["java:/MyPooledCF"])
> {noformat}
> The "connector" wants a list of name-value pairs, but only the name is taken into consideration. This command results in this XML:
> {noformat}
> <pooled-connection-factory name="my-pooled-connection-factory">
> <connectors>
> <connector-ref connector-name="in-vm"/>
> </connectors>
> <entries>
> <entry name="java:/MyPooledCF"/>
> </entries>
> </pooled-connection-factory>
> {noformat}
> The "xyz" is completely unnecessary.
> I believe this is because {{org.jboss.as.messaging.jms.ConnectionFactoryAttributes.Common#CONNECTOR}} is defined as a {{org.jboss.as.controller.SimpleMapAttributeDefinition}} and it should probably just be a {{org.jboss.as.controller.PrimitiveListAttributeDefinition}} when used in the pooled-connection-factory.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months