[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
12 years, 8 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
12 years, 8 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
12 years, 8 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
12 years, 8 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
12 years, 8 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
12 years, 8 months
[JBoss JIRA] (JGRP-1717) Bundling reduces performance in scenario mimicking Inifinispan
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1717:
--------------------------------
Note that batching does make sense for regular messages: since all messages in a batch are from the same sender, we'd have to deliver them in turn anyway. Therefore, delivering them as a batch is more efficient.
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
> Key: JGRP-1717
> URL: https://issues.jboss.org/browse/JGRP-1717
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.
--
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, 8 months
[JBoss JIRA] (JGRP-1717) Bundling reduces performance in scenario mimicking Inifinispan
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1717 at 11/7/13 10:04 AM:
----------------------------------------------------------
Note that batching does make sense for regular messages: since all messages in a batch are from the same sender, we'd have to deliver them in turn anyway (to preserve FIFO order). Therefore, delivering them as a batch is more efficient.
was (Author: belaban):
Note that batching does make sense for regular messages: since all messages in a batch are from the same sender, we'd have to deliver them in turn anyway. Therefore, delivering them as a batch is more efficient.
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
> Key: JGRP-1717
> URL: https://issues.jboss.org/browse/JGRP-1717
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.
--
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, 8 months
[JBoss JIRA] (JGRP-1717) Bundling reduces performance in scenario mimicking Inifinispan
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1717:
--------------------------------
I think the underlying problem is that bundled *OOB messages* will get delivered as message *batches* at the receiver(s). This means that if we have a batch of 5 OOB RPCs [1,2,3,4,5], then RPC #1 will get invoked, then RPC #2 etc, *even if these RPCs are all tagged as OOB*. RPC #5 for example will be delayed by the cummulative delays of all RPCs ahead of it.
So while message batching increases throughput, it also increases latency, which decreases performance of synchronous RPCs. Note that the RPC responses are also going to be delivered as a batch.
Therefore, currently message batching and sync OOB RPCs only makes sense if the receivers use the Async Invocation API and and internal thread pool. If this is not the case, sync OOB RPCs should be marked with a {{DONT_BUNDLE}} flag.
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
> Key: JGRP-1717
> URL: https://issues.jboss.org/browse/JGRP-1717
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.
--
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, 8 months
[JBoss JIRA] (AS7-5970) RichFaces Showcase portlet is unable to switch skins
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5970?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-5970:
----------------------------------------------
Honza Fnukal <hfnukal(a)redhat.com> changed the Status of [bug 877560|https://bugzilla.redhat.com/show_bug.cgi?id=877560] from VERIFIED to CLOSED
> RichFaces Showcase portlet is unable to switch skins
> ----------------------------------------------------
>
> Key: AS7-5970
> URL: https://issues.jboss.org/browse/AS7-5970
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Ken Finnigan
> Assignee: Stan Silvert
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> The following exception is thrown when the user changes skins for the second time immediately after changing the skin for the first time:
> {noformat}
> Caused by: javax.faces.FacesException: Cannot remove the same component twice: pbG9dea276d_2dee9e_2d4150_2dad91_2d22255b5a57d2_j_id1:j_idt444
> at com.sun.faces.context.StateContext$AddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:489) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1]
> at com.sun.faces.context.StateContext$AddRemoveListener.handleRemove(StateContext.java:371) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1]
> at com.sun.faces.context.StateContext$AddRemoveListener.processEvent(StateContext.java:334) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1]
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) [jboss-jsf-api_2.1_spec-2.0.7.Final-redhat-1.jar:2.0.7.Final-redhat-1]
> {noformat}
> This error manifests due to the Portlet Bridge needing to retain the UIViewRoot from JSF between Portlet Requests, which causes the list of component tree actions, ie. adding and removing, to be retained making JSF think that it's trying to remove a component that was actually removed in a previous request.
> This has been raised as http://java.net/jira/browse/JAVASERVERFACES-2609, but wanted to raise this as a tracker so that when that fix is available it can be incorporated.
--
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, 8 months