January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1801) DuplicateTest fails when testing OOB multicast to all three senders

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.... ] Bela Ban closed JGRP-1801. -------------------------- Resolution: Done If you think this is a real bug, and not just a transient error, feel free to reopen in 3.6.8. Closing for now. > DuplicateTest fails when testing OOB multicast to all three senders > ------------------------------------------------------------------- > > Key: JGRP-1801 > URL: https://issues.jboss.org/browse/JGRP-1801 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.14 > > > DuplicateTest does the following: > - creates three channels containing the DUPL layer called c1, c2, c3 > - DUPL is used to duplicate messages sent > - channel receiver for channel each keeps a map of messages received from each sender > - channels send messages: regular, OOB, or mixed > - the test checks that the messages received by each channel are correct in number and in order > The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure: > {noformat} > Error Message > expected size=3, msgs: [C2, C1] > Stacktrace > java.lang.AssertionError > at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) > at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1801) DuplicateTest fails when testing OOB multicast to all three senders

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.... ] Bela Ban reopened JGRP-1801: ---------------------------- > DuplicateTest fails when testing OOB multicast to all three senders > ------------------------------------------------------------------- > > Key: JGRP-1801 > URL: https://issues.jboss.org/browse/JGRP-1801 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.14 > > > DuplicateTest does the following: > - creates three channels containing the DUPL layer called c1, c2, c3 > - DUPL is used to duplicate messages sent > - channel receiver for channel each keeps a map of messages received from each sender > - channels send messages: regular, OOB, or mixed > - the test checks that the messages received by each channel are correct in number and in order > The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure: > {noformat} > Error Message > expected size=3, msgs: [C2, C1] > Stacktrace > java.lang.AssertionError > at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217) > at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1084) Standalone powershell script does't support SECMGR=true environment variable

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1084?page=com.atlassian.jira.plugi... ] Tomaz Cerar reopened WFCORE-1084: --------------------------------- Still has some issues with way env variables are specifed > Standalone powershell script does't support SECMGR=true environment variable > ---------------------------------------------------------------------------- > > Key: WFCORE-1084 > URL: https://issues.jboss.org/browse/WFCORE-1084 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.0.0.CR8 > Reporter: Marek Kopecký > Assignee: Tomaz Cerar > Priority: Minor > Fix For: 2.0.3.Final > > > Standalone powershell script does't support SECMGR=true environment variable. Standalone script should enable security manager with this environment variable. Security manager can be enabled also by using -secmgr (this works correctly in EAP 7.0.0.DR13) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on WFLY-5822: ------------------------------------------- I did create a job (https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...) which ran the stress test using a "fixed" version of DR9, so that when the weak affinity was being calculated, there was no access to the Registry. The job and its diagrams did not complete correctly (although it did pass through all iterations - maybe some debugging code though it off?) but looking at the raw data, it appears there was little change in the aggregate performance. > Clustering performance regression in ejbremote-dist-sync scenario > ------------------------------------------------------------------ > > Key: WFLY-5822 > URL: https://issues.jboss.org/browse/WFLY-5822 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 10.0.0.CR5 > Reporter: Michal Vinkler > Assignee: Richard Achmatowicz > Priority: Critical > > Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why? > Compare these results: > stress-ejbremote-dist-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] > --------------------------------------- > Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand: > stress-ejbremote-repl-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-257) java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0

by Simon Franquet (JIRA)

[ https://issues.jboss.org/browse/JASSIST-257?page=com.atlassian.jira.plugi... ] Simon Franquet commented on JASSIST-257: ---------------------------------------- Thanks for your comment, we use a legacy code that run on Java 1.6, and this version claims to be 1.6 compatible, hope that next releases of javassist will fix this, in order to benefit from various improvements. > java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0 > -------------------------------------------------------------------------------------------------- > > Key: JASSIST-257 > URL: https://issues.jboss.org/browse/JASSIST-257 > Project: Javassist > Issue Type: Release > Environment: Linux Tomcat 7 / JDK 1.6.0.41 / RHEL 5 > Javassist version 3.20.0-GA > Reporter: Simon Franquet > Assignee: Shigeru Chiba > > Sorry, not sure it's the right place to post this, but anyway : during instrumentation, class transformation fails with the this : > Redefinition class failed ! > java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0 > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) > at java.lang.ClassLoader.defineClass(ClassLoader.java:615) > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) > at java.net.URLClassLoader.access$000(URLClassLoader.java:58) > at java.net.URLClassLoader$1.run(URLClassLoader.java:197) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > at com.meilleuregestion.instrumentation.Transformer.transform(Transformer.java:33) > at sun.instrument.TransformerManager.transform(TransformerManager.java:169) > at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365) > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) > at java.lang.ClassLoader.defineClass(ClassLoader.java:615) > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) > at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2895) > at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1173) > at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1681) > at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559) > at org.apache.catalina.util.Introspection.loadClass(Introspection.java:143) > at org.apache.catalina.startup.WebAnnotationSet.loadApplicationServletAnnotations(WebAnnotationSet.java:135) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1202) LDAP authentication/authorization fails due to making unneeded role lookup requests

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1202?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1202: ------------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1196343|https://bugzilla.redhat.com/show_bug.cgi?id=1196343] from POST to MODIFIED > LDAP authentication/authorization fails due to making unneeded role lookup requests > ----------------------------------------------------------------------------------- > > Key: WFCORE-1202 > URL: https://issues.jboss.org/browse/WFCORE-1202 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Brad Maxwell > Assignee: Derek Horton > Fix For: 2.0.5.CR1 > > > LDAP authentication/authorization fails due to making unneeded role lookup requests -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-257) java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/JASSIST-257?page=com.atlassian.jira.plugi... ] Tomaz Cerar commented on JASSIST-257: ------------------------------------- This exception tells you that you are trying to load class compiled for java 8 on JDK6 which is the reason why it fails. upgrade your runtime JDK to 8 or use older version of javaasit > java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0 > -------------------------------------------------------------------------------------------------- > > Key: JASSIST-257 > URL: https://issues.jboss.org/browse/JASSIST-257 > Project: Javassist > Issue Type: Release > Environment: Linux Tomcat 7 / JDK 1.6.0.41 / RHEL 5 > Javassist version 3.20.0-GA > Reporter: Simon Franquet > Assignee: Shigeru Chiba > > Sorry, not sure it's the right place to post this, but anyway : during instrumentation, class transformation fails with the this : > Redefinition class failed ! > java.lang.UnsupportedClassVersionError: javassist/ClassPool : Unsupported major.minor version 52.0 > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) > at java.lang.ClassLoader.defineClass(ClassLoader.java:615) > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) > at java.net.URLClassLoader.access$000(URLClassLoader.java:58) > at java.net.URLClassLoader$1.run(URLClassLoader.java:197) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > at com.meilleuregestion.instrumentation.Transformer.transform(Transformer.java:33) > at sun.instrument.TransformerManager.transform(TransformerManager.java:169) > at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365) > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) > at java.lang.ClassLoader.defineClass(ClassLoader.java:615) > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) > at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2895) > at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1173) > at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1681) > at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559) > at org.apache.catalina.util.Introspection.loadClass(Introspection.java:143) > at org.apache.catalina.startup.WebAnnotationSet.loadApplicationServletAnnotations(WebAnnotationSet.java:135) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1024) Rule engine parallelization

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1024: ----------------------------------- Summary: Rule engine parallelization Key: DROOLS-1024 URL: https://issues.jboss.org/browse/DROOLS-1024 Project: Drools Issue Type: Enhancement Reporter: Mario Fusco Assignee: Mario Fusco Allow rules to be evaluated and fired in parallel -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1980) Improve throughput under contention for FlowControl.Credit

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1980?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1980: -------------------------------- Got you, that was a misunderstanding then. I pushed this into 3.6.8, so I can release 3.6.7 soon... > Improve throughput under contention for FlowControl.Credit > ---------------------------------------------------------- > > Key: JGRP-1980 > URL: https://issues.jboss.org/browse/JGRP-1980 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.6 > Reporter: Sanne Grinovero > Assignee: Bela Ban > Fix For: 3.6.8 > > > The methods {{org.jgroups.protocols.FlowControl.Credit.decrementIfEnoughCredits(long, long)}} and {{org.jgroups.protocols.FlowControl.Credit.decrementAndGet(long)}} are contending the locks on class synchronization when stress testing JGroups. > Wondering if we can think of polishing the implementation, although it looks like challenging. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1980) Improve throughput under contention for FlowControl.Credit

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/JGRP-1980?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on JGRP-1980: --------------------------------------- This was identified by using the JMH test I shared with you. To clarify: I didn't mean to suggest that the two methods _decrementIfEnoughCredits_ and _decrementAndGet_ are contending among each other. Just that both are showing contention. Given your explanation, I guess it's possible that many invocations of _decrementIfEnoughCredits_ are contending among each other. And similarly for the other method. The contention was quite low though, so I wouldn't consider this a priority at this point. It might become more relevant though if we managed to speed-up other areas.. > Improve throughput under contention for FlowControl.Credit > ---------------------------------------------------------- > > Key: JGRP-1980 > URL: https://issues.jboss.org/browse/JGRP-1980 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.6 > Reporter: Sanne Grinovero > Assignee: Bela Ban > Fix For: 3.6.8 > > > The methods {{org.jgroups.protocols.FlowControl.Credit.decrementIfEnoughCredits(long, long)}} and {{org.jgroups.protocols.FlowControl.Credit.decrementAndGet(long)}} are contending the locks on class synchronization when stress testing JGroups. > Wondering if we can think of polishing the implementation, although it looks like challenging. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016