[JBoss JIRA] (WFLY-3492) JSSE configuration in security domain wrongly acceptes empty parameters
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3492?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3492:
-----------------------------------------------
Alexey Loubyansky <olubyans(a)redhat.com> changed the Status of [bug 1080069|https://bugzilla.redhat.com/show_bug.cgi?id=1080069] from ASSIGNED to POST
> JSSE configuration in security domain wrongly acceptes empty parameters
> -----------------------------------------------------------------------
>
> Key: WFLY-3492
> URL: https://issues.jboss.org/browse/WFLY-3492
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Reporter: Chao Wang
> Assignee: Alexey Loubyansky
>
> Description from https://bugzilla.redhat.com/show_bug.cgi?id=1080069:
> {noformat}
> When adding a jsse configuration in security domain through CLI, it's not persisted correctly.
> Steps to reproduce:
> * Run CLI (./jboss-cli.sh -c) and use this commands to configure new security domain:
> /subsystem=security/security-domain=trust-domain:add
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore=>{password=1234test,url=/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> reload
> * check standalone.xml, where should be sth. like
> <security-domain name="trust-domain">
> <jsse truststore-password="1234test" truststore-url="/home/jcacek/projects/ocsp-check/build/trusted-clients.jks"/>
> </security-domain>
> But there is:
> <security-domain name="trust-domain">
> <jsse/>
> </security-domain>
> {noformat}
> {noformat}
> I had a mistake in the second command, it should be:
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore={password=>1234test,url=>/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> Then it works.
> Nevertheless it's probably still a bug, when the original command returns:
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JBMETA-379) Missing param-name in a web.xml causes NullPointerException during deployment
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/JBMETA-379?page=com.atlassian.jira.plugin... ]
Jean-Frederic Clere resolved JBMETA-379.
----------------------------------------
Resolution: Done
> Missing param-name in a web.xml causes NullPointerException during deployment
> ------------------------------------------------------------------------------
>
> Key: JBMETA-379
> URL: https://issues.jboss.org/browse/JBMETA-379
> Project: JBoss Metadata
> Issue Type: Bug
> Components: web
> Affects Versions: 8.0.0.Final
> Reporter: Jay Kumar SenSharma
> Assignee: Jean-Frederic Clere
> Fix For: 8.0.1.Final
>
> Attachments: ContextParamNullDemo.war
>
>
> - While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException as following:
> {code}
> 00:12:09,583 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "ContextParamNullDemo.war" (runtime-name: "ContextParamNullDemo.war")
> 00:12:09,591 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ContextParamNullDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jsf.deployment.JSFVersionProcessor.deploy(JSFVersionProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> 00:12:09,598 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment \"ContextParamNullDemo.war\"
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (DROOLS-594) Accumulation causes node propagation failure which results in rule firing when it is not supposed to
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-594?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-594:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> Accumulation causes node propagation failure which results in rule firing when it is not supposed to
> ----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-594
> URL: https://issues.jboss.org/browse/DROOLS-594
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.Beta1
> Reporter: John Le
> Assignee: Mario Fusco
> Attachments: AggregateIssue.java
>
>
> Accumulation causes node propagation failure which results in rule firing when it is not supposed to. Please see attached code file to reproduce the issue. Rule "RS7402.42.2" is supposed to fire once but it manages to fire twice without getting deactivate.
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - ACTIVATION CREATED rule:RS7365.4.6_ activationId:RS7365.4.6_ [1, 2, 3, 4, 12] declarations: $benefitAssessmentResults=BenefitAssessmentResults
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - BEFORE ACTIVATION FIRED rule:RS7365.4.6_ activationId:RS7365.4.6_ [1, 2, 3, 4, 12] declarations: $benefitAssessmentResults=BenefitAssessmentResults
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT ASSERTED value:EvaluatedData factId: 13
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT MODIFIED value:BenefitAssessmentResults factId: 12
> RS7365.4.6_ FIRED
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - AFTER ACTIVATION FIRED rule:RS7365.4.6_ activationId:RS7365.4.6_ [1, 2, 3, 4, 12] declarations: $benefitAssessmentResults=BenefitAssessmentResults
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - ACTIVATION CREATED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 11, 4, 12, 13, 15] declarations: $currentMortgagePaymentAmount=0.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - ACTIVATION CREATED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 10, 4, 12, 13, 14] declarations: $currentMortgagePaymentAmount=0.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - BEFORE ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 11, 4, 12, 13, 15] declarations: $currentMortgagePaymentAmount=0.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT MODIFIED value:EvaluatedData factId: 13
> RS7402.42.2_ FIRED
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - AFTER ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 11, 4, 12, 13, 15] declarations: $currentMortgagePaymentAmount=9180.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - BEFORE ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 10, 4, 12, 13, 14] declarations: $currentMortgagePaymentAmount=9180.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - OBJECT MODIFIED value:EvaluatedData factId: 13
> RS7402.42.2_ FIRED
> 2014-09-05 23:23:02 INFO WorkingMemoryConsoleLogger:51 - AFTER ACTIVATION FIRED rule:RS7402.42.2_ activationId:RS7402.42.2_ [1, 2, 3, 5, 10, 4, 12, 13, 14] declarations: $currentMortgagePaymentAmount=18360.0; $evaluatedData=EvaluatedData; $sum_1=9180.0
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1877 at 9/9/14 10:45 AM:
---------------------------------------------------------
Thanks David, one of our JGroups users has actually run into problems with {{System.currentTimeMillis()}} when the system time was adjusted via NTP.
I misread the javadoc: {{nanoTime()}} doesn't return negative values, but the origin might be in the future, so I'll use your suggestion.
h5. Correction
{{System.nanoTime()}} can indeed wrap around and become negative when reaching {{Long.MAX_VALUE}}.
was (Author: belaban):
Thanks David, one of our JGroups users has actually run into problems with {{System.currentTimeMillis()}} when the system time was adjusted via NTP.
I misread the javadoc: {{nanoTime()}} doesn't return negative values, but the origin might be in the future, so I'll use your suggestion.
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3834) Memory leak in org.xnio.ByteBufferSlicePool
by Sergey Lisovoy (JIRA)
[ https://issues.jboss.org/browse/WFLY-3834?page=com.atlassian.jira.plugin.... ]
Sergey Lisovoy commented on WFLY-3834:
--------------------------------------
Wildfly 8.1.0 Final is running as monitoring remote process.
> Memory leak in org.xnio.ByteBufferSlicePool
> -------------------------------------------
>
> Key: WFLY-3834
> URL: https://issues.jboss.org/browse/WFLY-3834
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Sergey Lisovoy
> Labels: memory_leak, memoryleak
>
> I have a simple thread that monitor remote wildfly process status. After some time it fail with OutOfMemory exception.
> I wrote simple exsample how to reproduce its error:
> {code:java}
> package ru.kamis.tests.xniomemoryleaks;
> import org.jboss.as.controller.client.ModelControllerClient;
> import org.jboss.as.controller.client.helpers.Operations;
> import org.jboss.dmr.ModelNode;
> public class OutOfMemoryDemo {
> public static void main(String[] args) throws Exception {
>
> for(int i=0; i<1000000; i++) {
> ModelControllerClient client = null;
> client = ModelControllerClient.Factory.create("localhost", 9990);
>
> ModelNode operation = Operations.createReadAttributeOperation(new ModelNode().setEmptyList(), "server-state");
> client.execute(operation);
>
> client.close();
>
> if(i % 1000 == 0) {
> System.out.println("Processed: " + i);
> }
> }
> }
> }
> {code}
> Program produces folowing output:
> {noformat}
> сен 09, 2014 2:33:20 PM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.2.2.Final
> сен 09, 2014 2:33:20 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.2.2.Final
> сен 09, 2014 2:33:20 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.3.Final
> Processed: 0
> Processed: 1000
> Processed: 2000
> Processed: 3000
> Processed: 4000
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at java.lang.String.toCharArray(String.java:2746)
> at sun.net.www.ParseUtil.encodePath(ParseUtil.java:107)
> at sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:757)
> at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:842)
> at sun.misc.URLClassPath.getResource(URLClassPath.java:199)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:358)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:148)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at ru.kamis.tests.xniomemoryleaks.OutOfMemoryDemo.main(OutOfMemoryDemo.java:15)
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> сен 09, 2014 2:35:20 PM org.jboss.as.controller.client.impl.RemotingModelControllerClient finalize
> WARN: JBAS010600: Closing leaked controller client
> JBAS010649: Allocation stack trace:
> at java.lang.Thread.getStackTrace(Thread.java:1589)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:76)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:353)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:200)
> at ru.kamis.tests.xniomemoryleaks.OutOfMemoryDemo.main(OutOfMemoryDemo.java:12)
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> {noformat}
> Used libraries:
> {code:xml}
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-controller-client</artifactId>
> <version>8.1.0.Final</version>
> </dependency>
> {code}
> The same bug is reproduced on other xnio versions: 3.2.3.Final, 3.3.0.Beta2
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3834) Memory leak in org.xnio.ByteBufferSlicePool
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3834?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3834:
-----------------------------------
What is server side version used?
> Memory leak in org.xnio.ByteBufferSlicePool
> -------------------------------------------
>
> Key: WFLY-3834
> URL: https://issues.jboss.org/browse/WFLY-3834
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Sergey Lisovoy
> Labels: memory_leak, memoryleak
>
> I have a simple thread that monitor remote wildfly process status. After some time it fail with OutOfMemory exception.
> I wrote simple exsample how to reproduce its error:
> {code:java}
> package ru.kamis.tests.xniomemoryleaks;
> import org.jboss.as.controller.client.ModelControllerClient;
> import org.jboss.as.controller.client.helpers.Operations;
> import org.jboss.dmr.ModelNode;
> public class OutOfMemoryDemo {
> public static void main(String[] args) throws Exception {
>
> for(int i=0; i<1000000; i++) {
> ModelControllerClient client = null;
> client = ModelControllerClient.Factory.create("localhost", 9990);
>
> ModelNode operation = Operations.createReadAttributeOperation(new ModelNode().setEmptyList(), "server-state");
> client.execute(operation);
>
> client.close();
>
> if(i % 1000 == 0) {
> System.out.println("Processed: " + i);
> }
> }
> }
> }
> {code}
> Program produces folowing output:
> {noformat}
> сен 09, 2014 2:33:20 PM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.2.2.Final
> сен 09, 2014 2:33:20 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.2.2.Final
> сен 09, 2014 2:33:20 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.3.Final
> Processed: 0
> Processed: 1000
> Processed: 2000
> Processed: 3000
> Processed: 4000
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at java.lang.String.toCharArray(String.java:2746)
> at sun.net.www.ParseUtil.encodePath(ParseUtil.java:107)
> at sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:757)
> at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:842)
> at sun.misc.URLClassPath.getResource(URLClassPath.java:199)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:358)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:148)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at ru.kamis.tests.xniomemoryleaks.OutOfMemoryDemo.main(OutOfMemoryDemo.java:15)
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> сен 09, 2014 2:35:20 PM org.jboss.as.controller.client.impl.RemotingModelControllerClient finalize
> WARN: JBAS010600: Closing leaked controller client
> JBAS010649: Allocation stack trace:
> at java.lang.Thread.getStackTrace(Thread.java:1589)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:76)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:353)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:200)
> at ru.kamis.tests.xniomemoryleaks.OutOfMemoryDemo.main(OutOfMemoryDemo.java:12)
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space
> {noformat}
> Used libraries:
> {code:xml}
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-controller-client</artifactId>
> <version>8.1.0.Final</version>
> </dependency>
> {code}
> The same bug is reproduced on other xnio versions: 3.2.3.Final, 3.3.0.Beta2
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups
by Karim AMMOUS (JIRA)
[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ]
Karim AMMOUS edited comment on JGRP-1876 at 9/9/14 10:03 AM:
-------------------------------------------------------------
Adding a sample program to reproduce this issue.
was (Author: ammous):
Adding a sample program produce this issue.
> MERGE3 : Strange number and content of subgroups
> ------------------------------------------------
>
> Key: JGRP-1876
> URL: https://issues.jboss.org/browse/JGRP-1876
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.6
>
> Attachments: 4Subgroups.zip, DkeJgrpAddress.java, MergeTest4.java, MergeViewWith210Subgroups.log
>
>
> Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2).
> The final mergeView is correct and contains 210 members.
> Here is an extract of subviews:
> {code}
> INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172]
> 210 subgroups
> [....
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]]
> [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]]
> [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]]
> ....]
> {code}
> II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view.
> Example:
> {code}
> {A, B, C} => {A, B, C} and {C} => {A, B, C}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month