[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:02 AM:
-------------------------------------------------------------
Adding a sample program produce this issue.
was (Author: ammous):
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
[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 updated JGRP-1876:
-------------------------------
Attachment: MergeTest4.java
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
[JBoss JIRA] (WFLY-3834) Memory leak in org.xnio.ByteBufferSlicePool
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3834?page=com.atlassian.jira.plugin.... ]
David Lloyd moved XNIO-236 to WFLY-3834:
----------------------------------------
Project: WildFly (was: XNIO)
Key: WFLY-3834 (was: XNIO-236)
Affects Version/s: (was: 3.2.0.Final)
(was: 3.2.2.Final)
(was: 3.3.0.Beta2)
(was: 3.2.3.Final)
Component/s: Domain Management
(was: nio-impl)
> 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] (SECURITY-845) Classloader leak in JBossCachedAuthenticationManager
by Peter Skopek (JIRA)
[ https://issues.jboss.org/browse/SECURITY-845?page=com.atlassian.jira.plug... ]
Peter Skopek resolved SECURITY-845.
-----------------------------------
Fix Version/s: PicketBox_4_0_21.Beta4
Resolution: Done
> Classloader leak in JBossCachedAuthenticationManager
> ----------------------------------------------------
>
> Key: SECURITY-845
> URL: https://issues.jboss.org/browse/SECURITY-845
> Project: PicketBox
> Issue Type: Bug
> Components: PicketBox
> Affects Versions: PicketBox_4_0_21.Beta2
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Fix For: PicketBox_4_0_21.Beta4
>
>
> The problematic piece of code is the domainCache member variable which in the DomainInfo value holds a LoginContext instance. This LoginContext has member contextClassLoader which causes the leak. (It points to the ModuleClassLoader of the deployment).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (SECURITY-851) Base64Utils class cuts leading zeroes from encoded bytes
by Peter Skopek (JIRA)
[ https://issues.jboss.org/browse/SECURITY-851?page=com.atlassian.jira.plug... ]
Peter Skopek updated SECURITY-851:
----------------------------------
Fix Version/s: PicketBox_4_0_21.Beta4
> Base64Utils class cuts leading zeroes from encoded bytes
> --------------------------------------------------------
>
> Key: SECURITY-851
> URL: https://issues.jboss.org/browse/SECURITY-851
> Project: PicketBox
> Issue Type: Bug
> Affects Versions: PicketBox_4_0_21.Beta2
> Reporter: Josef Cacek
> Assignee: Josef Cacek
> Priority: Blocker
> Fix For: PicketBox_4_0_21.Beta4
>
>
> Vault util is failing for some password/salt/iteration combinations because Base64Utils class strips zeroes from provided byte array.
> So if a user encodes a key with length 8 and the leading byte of the key is zero, then after decoding he only gets 7 (or less) bytes.
> For instance:
> {code}
> encode ( { 0, 81, 121, -37, 46, -64, 20, 114 } ) -> "1HUTikm1Ho"
> decode ("1HUTikm1Ho") -> { 81, 121, -37, 46, -64, 20, 114 }
> {code}
> As a result the PBEUtil will fail with javax.crypto.IllegalBlockSizeException.
> IMHO the same problem can occur on other places where the Base64Utils class is used (not only the Vault).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-838) Can't get implementing classname for JSR77 MBean
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-838?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-838:
----------------------------------------------
Mustafa Musaji <mmusaji(a)redhat.com> changed the Status of [bug 1138649|https://bugzilla.redhat.com/show_bug.cgi?id=1138649] from ASSIGNED to MODIFIED
> Can't get implementing classname for JSR77 MBean
> ------------------------------------------------
>
> Key: WFLY-838
> URL: https://issues.jboss.org/browse/WFLY-838
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Reporter: Anders Welen
> Priority: Minor
> Fix For: Awaiting Volunteers
>
>
> The following exception are thrown when asking the MBean server for the classname implementing "jboss.jsr77:j2eeType=WebModule,name=MyWar.war,J2EEServer=default".
> It should be a legal call. Why are the code clearly states it's illegal?
>
> java.lang.IllegalStateException: JBAS019905: Should not get called
> at org.jboss.as.jsr77.managedobject.J2EEDeployedObjectHandlers$J2EEModuleHandler.queryObjectNames(J2EEDeployedObjectHandlers.java:245)
> at org.jboss.as.jsr77.managedobject.BaseHandler.getMBeanInfo(BaseHandler.java:64)
> at org.jboss.as.jsr77.managedobject.J2EEDeployedObjectHandlers.getMBeanInfo(J2EEDeployedObjectHandlers.java:147)
> at org.jboss.as.jsr77.managedobject.ManagedObjectHandlerRegistry.getMBeanInfo(ManagedObjectHandlerRegistry.java:112)
> at org.jboss.as.jsr77.subsystem.JSR77ManagementMBeanServer.getMBeanInfo(JSR77ManagementMBeanServer.java:179)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanInfo(PluggableMBeanServerImpl.java:212)
>
> The error can easily be triggered by using JConsole to browse the same MBean.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3266:
-----------------------------------------------
Panagiotis Sotiropoulos <psotirop(a)redhat.com> changed the Status of [bug 1088463|https://bugzilla.redhat.com/show_bug.cgi?id=1088463] from ASSIGNED to POST
> Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3266
> URL: https://issues.jboss.org/browse/WFLY-3266
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
>
> In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
> The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.
> java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
> at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month