[JBoss JIRA] (JGRP-1734) Probe: restrict requests to certain clusters and/or nodes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1734?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1734.
----------------------------
Resolution: Done
Only implemented -cluster regexp
> Probe: restrict requests to certain clusters and/or nodes
> ---------------------------------------------------------
>
> Key: JGRP-1734
> URL: https://issues.jboss.org/browse/JGRP-1734
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Optional
> Fix For: 3.4.1, 3.5
>
>
> Probe.sh broadcasts requests to all reachable nodes in any cluster. The only way to restrict the reach of a probe request is to pass a time-to-live to it, but that's (a) too coarse-grained and (b) doesn't work for TCP.
> We should therefore be able to define a list of clusters and a list of nodes to which we want to restrict the request. Both clusters and nodes should be simple regexps.
> The filter is sent with the probe request. Nodes which don't pass the filter simply discard the request.
> Example:
> {noformat}
> probe.sh -cluster DrawCluster,cluster-*{noformat}
> This restricts the request to the {{DrawCluster}} and any cluster starting with {{cluster-}}.
> {noformat}
> probe.sh -nodes cluster-*
> {noformat}
> Sends the request only to nodes with a name starting with {{cluster}}.
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-228) TS: Migrate from Surefire to Failsafe maven plugin.
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-228?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar commented on WFLY-228:
-------------------------------------
What is the status of this?
> TS: Migrate from Surefire to Failsafe maven plugin.
> ---------------------------------------------------
>
> Key: WFLY-228
> URL: https://issues.jboss.org/browse/WFLY-228
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Reporter: Ondrej Zizka
> Assignee: Jakub Senko
> Fix For: 8.0.0.CR1
>
> Attachments: AS7-failsafe-surefire.html.zip
>
>
> Surefire aims at unit testing.
> Failsafe, unlike Surefire, binds to two build phases - integration-tests and verify.
> That not only moves test execution to the correct phase, but also brings possibility to test several issues present in the testsuite - like skipping successive Surefire executions in a single module if former fails (not affected by -fae).
>
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-1548) Add fallback querry to jconsole plugin
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-1548?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-1548:
----------------------------------------
This fix has resulted in a change that has gone into Beta1 so a new Jira will be needed if further work is required.
> Add fallback querry to jconsole plugin
> --------------------------------------
>
> Key: WFLY-1548
> URL: https://issues.jboss.org/browse/WFLY-1548
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Bartosz Baranowski
> Assignee: Darran Lofthouse
> Labels: JConsole, JMX, Plugin
> Fix For: 8.0.0.Beta1
>
>
> JConsolePlugin connecects to default port, despite chance to use proper info.
> Problem:
> Unless I miss somethingm JConsole has a bit tight isolation between components. There is no way for AS7 JConsolePlugin to access "connect dialog" info. Hence it has no idea what is the content of URL being passed as remote.
> AS7 JConsolePlugin checks if MBeanServerConnection is instance of RemotinConnection. If its not, it fallbacks to default: localhost:9990.
> However we can check for socket bindings and try to connect to proper socket.
--
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
11 years, 2 months
[JBoss JIRA] (JGRP-1735) JChannel.startFlush() does not attempt back-off on flush collision
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1735?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1735:
---------------------------
Fix Version/s: 3.5
> JChannel.startFlush() does not attempt back-off on flush collision
> ------------------------------------------------------------------
>
> Key: JGRP-1735
> URL: https://issues.jboss.org/browse/JGRP-1735
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Rich DiCroce
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> The Javadoc for JChannel.startFlush() says:
> {quote}
> In case of flush collisions, a random sleep time backoff algorithm is employed and the flush is reattempted for numberOfAttempts. Therefore this method is guaranteed to return after timeout x numberOfAttempts milliseconds.
> {quote}
> This does not appear to be true. I had two nodes call this method at the same time and immediately got an exception due to a flush collision. The salient part of the stack trace is:
> {noformat}
> Caused by: java.lang.Exception: Flush failed for EITSQL2-33698
> at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:435) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:501) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.RSVP.up(RSVP.java:221) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.UNICAST3.removeAndDeliver(UNICAST3.java:796) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.UNICAST3.handleBatchReceived(UNICAST3.java:752) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:466) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:662) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.FD.up(FD.java:274) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.TP.passBatchUp(TP.java:1422) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.TP$BatchHandler.run(TP.java:1574) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> ... 3 more
> {noformat}
> The Javadoc talks about "timeout" and "numberOfAttempts" as if they were method parameters, but they aren't. Were those part of an earlier version of JGroups? If they're still present, where are they? Will JGroups still retry a flush that failed due to a collision?
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2465) Weld @Resource injection type validation supporting for autoboxing
by Eduardo Martins (JIRA)
Eduardo Martins created WFLY-2465:
-------------------------------------
Summary: Weld @Resource injection type validation supporting for autoboxing
Key: WFLY-2465
URL: https://issues.jboss.org/browse/WFLY-2465
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: CDI / Weld
Reporter: Eduardo Martins
Assignee: Eduardo Martins
Weld must consider that autoboxing may be used when validating @Resource injection types, so for instance, a resource-ref of type "java.lang.Character" may be injected into a "char" class field.
--
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
11 years, 2 months
[JBoss JIRA] (JGRP-1735) JChannel.startFlush() does not attempt back-off on flush collision
by Rich DiCroce (JIRA)
Rich DiCroce created JGRP-1735:
----------------------------------
Summary: JChannel.startFlush() does not attempt back-off on flush collision
Key: JGRP-1735
URL: https://issues.jboss.org/browse/JGRP-1735
Project: JGroups
Issue Type: Bug
Affects Versions: 3.4
Reporter: Rich DiCroce
Assignee: Bela Ban
The Javadoc for JChannel.startFlush() says:
{quote}
In case of flush collisions, a random sleep time backoff algorithm is employed and the flush is reattempted for numberOfAttempts. Therefore this method is guaranteed to return after timeout x numberOfAttempts milliseconds.
{quote}
This does not appear to be true. I had two nodes call this method at the same time and immediately got an exception due to a flush collision. The salient part of the stack trace is:
{noformat}
Caused by: java.lang.Exception: Flush failed for EITSQL2-33698
at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:435) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:501) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.protocols.RSVP.up(RSVP.java:221) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.protocols.FRAG2.up(FRAG2.java:182) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:434) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:434) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.protocols.UNICAST3.removeAndDeliver(UNICAST3.java:796) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.protocols.UNICAST3.handleBatchReceived(UNICAST3.java:752) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:466) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:662) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.protocols.FD.up(FD.java:274) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.protocols.TP.passBatchUp(TP.java:1422) [jgroups-3.4.0.Final.jar:3.4.0.Final]
at org.jgroups.protocols.TP$BatchHandler.run(TP.java:1574) [jgroups-3.4.0.Final.jar:3.4.0.Final]
... 3 more
{noformat}
The Javadoc talks about "timeout" and "numberOfAttempts" as if they were method parameters, but they aren't. Were those part of an earlier version of JGroups? If they're still present, where are they? Will JGroups still retry a flush that failed due to a collision?
--
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
11 years, 2 months
[JBoss JIRA] (DROOLS-323) Incremental Builds Result in ClassCastExceptions
by David Templin (JIRA)
[ https://issues.jboss.org/browse/DROOLS-323?page=com.atlassian.jira.plugin... ]
David Templin commented on DROOLS-323:
--------------------------------------
I noticed another exception while testing today. I simply added a print statement to a valid rules file for debugging purposes, and received the following exception:
{noformat}
java.lang.NullPointerException
at org.drools.base.mvel.MVELCompilationUnit.updateFactory(MVELCompilationUnit.java:362)
at org.drools.base.mvel.MVELCompilationUnit.updateFactory(MVELCompilationUnit.java:289)
at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:59)
at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49)
at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
at org.drools.rule.constraint.MvelConstraint.isAllowedCachedRight(MvelConstraint.java:184)
at org.drools.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:97)
at org.drools.reteoo.NotNode.assertObject(NotNode.java:131)
at org.drools.reteoo.AlphaNode$ObjectSinkUpdateAdapter.assertObject(AlphaNode.java:328)
at org.drools.reteoo.ObjectTypeNode.updateSink(ObjectTypeNode.java:334)
at org.drools.reteoo.AlphaNode.updateSink(AlphaNode.java:203)
at org.drools.reteoo.BetaNode.attach(BetaNode.java:408)
at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:145)
at org.drools.reteoo.builder.GroupElementBuilder$NotBuilder.build(GroupElementBuilder.java:261)
at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:112)
at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:134)
at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:113)
at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445)
at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:952)
at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:629)
at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:472)
at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:149)
at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:1117)
at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:1003)
at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:686)
at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:207)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run_aroundBody0(KnowledgeAgentImpl.java:1301)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector$AjcClosure1.run(KnowledgeAgentImpl.java:1)
at com.foo.DroolsBugAspect.ajc$around$com_clj2_business_aop_DroolsBugAspect$1$b7e32854proceed(DroolsBugAspect.aj:8)
at com.foo.DroolsBugAspect.ajc$around$com_clj2_business_aop_DroolsBugAspect$1$b7e32854(DroolsBugAspect.aj:10)
at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1295)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:695)
{noformat}
> Incremental Builds Result in ClassCastExceptions
> ------------------------------------------------
>
> Key: DROOLS-323
> URL: https://issues.jboss.org/browse/DROOLS-323
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Reporter: David Templin
> Assignee: Mark Proctor
> Attachments: drools-bug.tar.gz
>
>
> Incremental builds via the {{KnowledgeAgent}} occasionally result in a {{ClassCastException}}, such as the following:
> {noformat}
> java.lang.ClassCastException: org.drools.reteoo.AlphaNode$AlphaMemory cannot be cast to org.drools.reteoo.BetaMemory
> at org.drools.reteoo.JoinNode.updateSink(JoinNode.java:398)
> at org.drools.reteoo.RuleTerminalNode.attach(RuleTerminalNode.java:346)
> at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:174)
> at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:134)
> at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:113)
> at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445)
> at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:952)
> at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:629)
> at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:472)
> at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:149)
> at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:1117)
> at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:1003)
> at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:686)
> at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:207)
> at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run_aroundBody0(KnowledgeAgentImpl.java:1301)
> at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector$AjcClosure1.run(KnowledgeAgentImpl.java:1)
> at com.foo.DroolsBugAspect.ajc$around$com_foo_DroolsBugAspect$1$b7e32854proceed(DroolsBugAspect.aj:8)
> at com.foo.DroolsBugAspect.ajc$around$com_foo_DroolsBugAspect$1$b7e32854(DroolsBugAspect.aj:10)
> at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1295)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:695)
> {noformat}
> Steps to reproduce:
> # Download the attached zip file ({{drools-bug.tar.gz}})
> # Extract the contents into a directory
> # {{cd <directory>}}
> # {{mvn install}}
> # Type {{sh target/classes/run.sh}}, or else type {{java -classpath target/classes:target/lib/* -javaagent:target/lib/aspectjweaver-1.7.3.jar com.foo.Main}}
> # Wait for a sequence of log messages similar to the following messages to begin to print to the console:
> {noformat}
> [2013-11-06 11:05:33,742:debug] ResourceChangeScanner attempt to scan 1 resources
> [2013-11-06 11:05:33,743:debug] ResourceChangeScanner thread is waiting for 2 seconds.
> {noformat}
> # Edit {{target/classes/recommendations.drl}} in some trivial manner; for instance, I have found that editing the RHS of rule "Initialize Recommendations" by adding a print statement ({{e.g. System.out.println("test");}}) and editing the print statement a few times will reliably reproduce the problem; occasionally, merely touching the file will cause the problem to manifest.
> # Wait for the exception to print to the console; it will look like the exception above
> Note that the exception is suppressed by the executor architecture in Drools. Thus, I had to weave an aspect that catches the exception and prints it.
> This bug also results in a memory leak, since the {{ResourceChangeNotifier}} continues to produce {{ChangeSet}} objects, but there are no consumers after the {{ChangeSetNotificationDetector}} thread terminates, resulting in an unbounded queue.
> I also noticed the following exception in development, yet was unable to reproduce it in the attached demonstration project:
> {noformat}
> java.lang.ClassCastException: com.foo.AidAgreement cannot be cast to com.foo.Unit
> at org.drools.base.com.foo.Unit1155259690$getAgency.getValue(Unknown Source)
> at org.drools.base.extractors.BaseObjectClassFieldReader.getHashCode(BaseObjectClassFieldReader.java:204)
> at org.drools.base.ClassFieldReader.getHashCode(ClassFieldReader.java:193)
> at org.drools.core.util.AbstractHashTable$SingleIndex.hashCodeOf(AbstractHashTable.java:521)
> at org.drools.core.util.index.RightTupleIndexHashTable.getOrCreate(RightTupleIndexHashTable.java:438)
> at org.drools.core.util.index.RightTupleIndexHashTable.add(RightTupleIndexHashTable.java:319)
> at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:136)
> at org.drools.reteoo.ObjectTypeNode.updateSink(ObjectTypeNode.java:334)
> at org.drools.reteoo.BetaNode.attach(BetaNode.java:408)
> at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:145)
> at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:142)
> at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:70)
> at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
> at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:134)
> at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:113)
> at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445)
> at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:952)
> at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:629)
> at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:472)
> at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:149)
> at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:1117)
> at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:1003)
> at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:686)
> at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:207)
> at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run_aroundBody0(KnowledgeAgentImpl.java:1301)
> at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector$AjcClosure1.run(KnowledgeAgentImpl.java:1)
> at com.foo.DroolsBugAspect.ajc$around$com.foo_DroolsBugAspect$1$b7e32854proceed(DroolsBugAspect.aj:8)
> at com.foo.DroolsBugAspect.ajc$around$com.foo_DroolsBugAspect$1$b7e32854(DroolsBugAspect.aj:10)
> at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1295)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:695)
> {noformat}
> The demonstration code is, of course, only intended to demonstrate the problem. It is a highly simplified and slightly sanitized version of actual code that is in development.
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2464) simpler (than OBJECT) parser for STRING parameters and properties
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFLY-2464:
---------------------------------------
Summary: simpler (than OBJECT) parser for STRING parameters and properties
Key: WFLY-2464
URL: https://issues.jboss.org/browse/WFLY-2464
Project: WildFly
Issue Type: Task
Security Level: Public (Everyone can see)
Components: CLI
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Fix For: 8.0.0.CR1
At the moment a general parser (which recognizes objects, lists, properties, etc) is used for properties and parameters of type STRING. The problem with this is that some characters that appear special in values of types OBJECT, PROPERTY, LIST, etc have to be escaped in values of type STRING. E.g.
--connection-url=jdbc:h2:~/unifiedpush;DB_CLOSE_DELAY=-1
Here the equals sign before -1 has to be escaped, otherwise the value will be treated as PROPERTY and the equals sign as a name/value separator.
--
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
11 years, 2 months
[JBoss JIRA] (JGRP-1734) Probe: restrict requests to certain clusters and/or nodes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1734?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1734:
---------------------------
Description:
Probe.sh broadcasts requests to all reachable nodes in any cluster. The only way to restrict the reach of a probe request is to pass a time-to-live to it, but that's (a) too coarse-grained and (b) doesn't work for TCP.
We should therefore be able to define a list of clusters and a list of nodes to which we want to restrict the request. Both clusters and nodes should be simple regexps.
The filter is sent with the probe request. Nodes which don't pass the filter simply discard the request.
Example:
{noformat}
probe.sh -cluster DrawCluster,cluster-*{noformat}
This restricts the request to the {{DrawCluster}} and any cluster starting with {{cluster-}}.
{noformat}
probe.sh -nodes cluster-*
{noformat}
Sends the request only to nodes with a name starting with {{cluster}}.
was:
Probe.sh broadcasts requests to all reachable nodes in any cluster. The only way to restrict the reach of a probe request is to pass a time-to-live to it, but that's (a) too coarse-grained and (b) doesn't work for TCP.
We should therefore be able to define a list of clusters and a list of nodes to which we want to restrict the request. Both clusters and nodes should be simple regexps.
The filter is sent with the probe request. Nodes which don't pass the filter simply discard the request.
Example:
{{probe.sh -cluster DrawCluster,cluster-*}}: this restricts the request to the {{DrawCluster}} and any cluster starting with {{cluster-}}.
{{probe.sh -nodes cluster-*}}: sends the request only to nodes with a name starting with {{cluster}}.
> Probe: restrict requests to certain clusters and/or nodes
> ---------------------------------------------------------
>
> Key: JGRP-1734
> URL: https://issues.jboss.org/browse/JGRP-1734
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Optional
> Fix For: 3.5
>
>
> Probe.sh broadcasts requests to all reachable nodes in any cluster. The only way to restrict the reach of a probe request is to pass a time-to-live to it, but that's (a) too coarse-grained and (b) doesn't work for TCP.
> We should therefore be able to define a list of clusters and a list of nodes to which we want to restrict the request. Both clusters and nodes should be simple regexps.
> The filter is sent with the probe request. Nodes which don't pass the filter simply discard the request.
> Example:
> {noformat}
> probe.sh -cluster DrawCluster,cluster-*{noformat}
> This restricts the request to the {{DrawCluster}} and any cluster starting with {{cluster-}}.
> {noformat}
> probe.sh -nodes cluster-*
> {noformat}
> Sends the request only to nodes with a name starting with {{cluster}}.
--
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
11 years, 2 months
[JBoss JIRA] (JGRP-1734) Probe: restrict requests to certain clusters and/or nodes
by Bela Ban (JIRA)
Bela Ban created JGRP-1734:
------------------------------
Summary: Probe: restrict requests to certain clusters and/or nodes
Key: JGRP-1734
URL: https://issues.jboss.org/browse/JGRP-1734
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Optional
Fix For: 3.5
Probe.sh broadcasts requests to all reachable nodes in any cluster. The only way to restrict the reach of a probe request is to pass a time-to-live to it, but that's (a) too coarse-grained and (b) doesn't work for TCP.
We should therefore be able to define a list of clusters and a list of nodes to which we want to restrict the request. Both clusters and nodes should be simple regexps.
The filter is sent with the probe request. Nodes which don't pass the filter simply discard the request.
Example:
{{probe.sh -cluster DrawCluster,cluster-*}}: this restricts the request to the {{DrawCluster}} and any cluster starting with {{cluster-}}.
{{probe.sh -nodes cluster-*}}: sends the request only to nodes with a name starting with {{cluster}}.
--
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
11 years, 2 months