[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:
--------------------------------------
Hi, Davide. Thank you for confirming the issue. I tried many times to reproduce the problem with 5.6.0.CR1, yet I was unable to do so. It appears that the bug is not present in that version.
> 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, 6 months
[JBoss JIRA] (DROOLS-323) Incremental Builds Result in ClassCastExceptions
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-323?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-323:
---------------------------------------
Confirmed with 5.5.0.Final, but I could not reproduce the problem with 5.6.0.CR1. Could you try that version please? Thanks!
Davide
> 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, 6 months
[JBoss JIRA] (WFLY-1548) Add fallback querry to jconsole plugin
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1548?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1548:
-----------------------------------------------
Shaun Appleton <sappleto(a)redhat.com> made a comment on [bug 901311|https://bugzilla.redhat.com/show_bug.cgi?id=901311]
testing with EAP 6.2.0.Beta1
gives
Nov 07, 2013 8:17:06 PM org.xnio.Xnio <clinit>
INFO: XNIO Version 3.0.7.GA-redhat-1
Nov 07, 2013 8:17:06 PM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.0.7.GA-redhat-1
Nov 07, 2013 8:17:06 PM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 3.2.16.GA-redhat-1
Exception in thread "VMPanel.connect" java.lang.RuntimeException: Operation failed with status WAITING
at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:219)
at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:144)
at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:95)
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:267)
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:226)
at sun.tools.jconsole.ProxyClient.tryConnect(ProxyClient.java:366)
at sun.tools.jconsole.ProxyClient.connect(ProxyClient.java:316)
at sun.tools.jconsole.VMPanel$2.run(VMPanel.java:298)
> 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
12 years, 6 months
[JBoss JIRA] (WFLY-2466) Remoting subsystem: Concurrent modification exception during server shutdown
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-2466:
--------------------------------------
Summary: Remoting subsystem: Concurrent modification exception during server shutdown
Key: WFLY-2466
URL: https://issues.jboss.org/browse/WFLY-2466
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management, Remoting
Affects Versions: 8.0.0.Beta1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 8.0.0.CR1
Jitka Kozana reports that the following exception was sometimes logged during server shutdown:
[0m[33m01:46:29,696 WARN [org.jboss.msc.service.fail] (MSC service thread 1-55) MSC000004: Failure during stop of service jboss.remoting.endpoint.management.channel.management: java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) [rt.jar:1.6.0_45]
at java.util.HashMap$KeyIterator.next(HashMap.java:828) [rt.jar:1.6.0_45]
at java.util.AbstractCollection.addAll(AbstractCollection.java:305) [rt.jar:1.6.0_45]
at java.util.HashSet.<init>(HashSet.java:100) [rt.jar:1.6.0_45]
at org.jboss.as.remoting.AbstractChannelOpenListenerService.stop(AbstractChannelOpenListenerService.java:123)
at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
--
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, 6 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:
---------------------------
Fix Version/s: 3.4.1
> 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
12 years, 6 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 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
12 years, 6 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
12 years, 6 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
12 years, 6 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
12 years, 6 months