January 2016 - jboss-jira - Jboss List Archives

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

by Ladislav Thon (JIRA)

[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ] Ladislav Thon commented on WFLY-5822: ------------------------------------- [~rachmato] Sorry, I forgot to update you, it's done, all EAP 7 jobs should use it now. > 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)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1040) Kie server on Tomcat with JACCValve fails authorisation

by Karel Suta (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1040?page=com.atlassian.jira.plugi... ] Karel Suta commented on DROOLS-1040: ------------------------------------ fixed and merged into master and 6.4.x > Kie server on Tomcat with JACCValve fails authorisation > ------------------------------------------------------- > > Key: DROOLS-1040 > URL: https://issues.jboss.org/browse/DROOLS-1040 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.4.0.Beta1 > Environment: Tomcat > Kie server 6.4.0-SNAPSHOT > Reporter: Karel Suta > Assignee: Karel Suta > Priority: Minor > Labels: reported-by-qe > Fix For: 6.4.0.CR1 > > > When Kie server is run on Tomcat container with org.kie.integration.tomcat.JACCValve configured then JBPM operations which needs authorisation invoked on Kie server fails with: > "User '[UserImpl:'Roles']' does not have permissions to execute operation...". > Error happens just with JACCValve which is used for Workbench, so this isn't critical issue. > Issue is caused by JACCValve which register PolicyContextHandler with Subject returning 2 principals in HashSet, one principal represents user, second represent its roles. > JACCIdentityProvider in Kie server in method getName() returns first principal from Subject which it finds, in case it is roles principal then is returned "Roles" as user name, which is wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 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: ------------------------------------------- [~lthon] Any progress on the memory plugin update for JDK8? > 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)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1308) Description of suspend and shutdown ops does not include a 'unit'

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1308?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet reassigned WFCORE-1308: ----------------------------------------- Assignee: ehsavoie Hugonnet > Description of suspend and shutdown ops does not include a 'unit' > ----------------------------------------------------------------- > > Key: WFCORE-1308 > URL: https://issues.jboss.org/browse/WFCORE-1308 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Priority: Minor > > See 'unit' in https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Arbit... > It's missing from the description of the 'timeout' param for the root resource 'suspend' and 'shutdown' operations. It's in the text (as seconds) but not in the separate metadata. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1332) Referrals 'throw' does not work correctly for ldap authentication to mgmt console with MS Active Directory

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1332?page=com.atlassian.jira.plugi... ] Brian Stansberry moved JBEAP-3048 to WFCORE-1332: ------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1332 (was: JBEAP-3048) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management Security (was: Domain Management) (was: Security) Target Release: (was: 7.0.0.GA) Affects Version/s: 2.0.7.Final (was: 7.0.0.ER4) > Referrals 'throw' does not work correctly for ldap authentication to mgmt console with MS Active Directory > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1332 > URL: https://issues.jboss.org/browse/WFCORE-1332 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.0.7.Final > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > In case when crossRef object to different domain is configured on MS Active Directory for handling referrals and JBoss EAP 7 uses ldap authentication to mgmt console with configured referrals 'throw' then authentication fails for referral users. It is inconsistent with behavior of EAP with another LDAP providers (e.g. Red Hat Directory Server). In correct behavior authentication should pass. > It seems it is caused by thrown LdapReferralException search method of org.jboss.as.domain.management.security.LdapUserSearcherFactory.LdapUserSearcherImpl before it is handled by try-catch block. Stack trace of thrown LdapReferralException: > com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2975) > com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888) > com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1846) > com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769) > com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1786) > com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:418) > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:396) > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:378) > javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286) > javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286) > org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:125) > org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:66) > org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225) > org.jboss.as.domain.management.security.UserLdapCallbackHandler$LdapCallbackHandler.handle(UserLdapCallbackHandler.java:205) > org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:178) > org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162) > org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141) > io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:118) > org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52) > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) > io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) > io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) > io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) > io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6070) Can not deploy a @ConnectionFactoryDefinition if the RA has more <connection-definitions>

by Lin Gao (JIRA)

Lin Gao created WFLY-6070: ----------------------------- Summary: Can not deploy a @ConnectionFactoryDefinition if the RA has more <connection-definitions> Key: WFLY-6070 URL: https://issues.jboss.org/browse/WFLY-6070 Project: WildFly Issue Type: Bug Components: JCA Affects Versions: 10.0.0.CR5 Reporter: Lin Gao Assignee: Lin Gao Steps to reproduce: * add a 2nd connection-defintion to testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/deployment/ra.xml: {noformat} <connection-definition> <managedconnectionfactory-class>org.jboss.as.test.integration.jca.rar.MultipleManagedConnectionFactory2</managedconnectionfactory-class> <connectionfactory-interface>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2</connectionfactory-interface> <connectionfactory-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2Impl</connectionfactory-impl-class> <connection-interface>org.jboss.as.test.integration.jca.rar.MultipleConnection2</connection-interface> <connection-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnection2Impl</connection-impl-class> </connection-definition> {noformat} * Run the WarServletDeploymentTestCase test => it fails because the ConnectionFactoryDefinition objects are no longer deployed. After debugging, the test fails because the deployed connection definitions are not activated. The code at org/jboss/as/connector/services/resourceadapters/ResourceAdapterActivatorService.java:232 is preventing the activation and looks suspicious. It expects that all the MCF in the RA (raMcfClasses) must *all* be in the activation (ijMcfClasses). With a 2nd <connection-definition> in the RA, it is no longer the case (as the activation only contains a single MCF (MultipleManagedConnectionFactory1). If I change the code so that it checks that all the MCF in the activations are in the RA, the test passes again. This issue is preventing me to reuse the code handling the @ConnectionFactoryDefinition to support the @JMSConnectionFactoryDefinition (my JMS RA defines 3 MCF for generic/queue/topic CFs but my activation only defines a single MCF per @JMSConnectionFactoryDefinition). I've not run it but the same issue is likely for admin objects too (the code in checkActivation is similar) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1037) Parsing of a complex constraint with an || causes a RuntimeException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1037?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1037: ------------------------------------------------- Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1300692|https://bugzilla.redhat.com/show_bug.cgi?id=1300692] from NEW to MODIFIED > Parsing of a complex constraint with an || causes a RuntimeException > -------------------------------------------------------------------- > > Key: DROOLS-1037 > URL: https://issues.jboss.org/browse/DROOLS-1037 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.0.CR1 > > > Trying to compile a rule like the following > {code} > rule R when > $p : Person( name == null || (name in (\"Alice\", \"Charlie\", \"David\"))==false ) > then > list.add($p.getName()); > end > {code} > causes the following RuntimeException: > {code} > java.lang.RuntimeException > at org.drools.compiler.rule.builder.PatternBuilder.rewriteCompositeExpressions(PatternBuilder.java:924) > at org.drools.compiler.rule.builder.PatternBuilder.rewriteCompositeExpressions(PatternBuilder.java:919) > at org.drools.compiler.rule.builder.PatternBuilder.rewriteOrExpressions(PatternBuilder.java:893) > at org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:889) > at org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:860) > at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:715) > at org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:580) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6069) Duplicated jipijapa module

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6069?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-6069: ------------------------------- Description: modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar modules/system/layers/base/org/hibernate/4.3/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar was: modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar modules/system/layers/base/org/hibernate/4.3/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar Refer to this tattletale report: http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Accep... > Duplicated jipijapa module > -------------------------- > > Key: WFLY-6069 > URL: https://issues.jboss.org/browse/WFLY-6069 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 10.0.0.CR5 > Reporter: Jan Martiska > Assignee: Scott Marlow > Priority: Critical > Fix For: 10.0.0.Final > > > modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar > modules/system/layers/base/org/hibernate/4.3/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6069) Duplicated jipijapa module

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6069?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-6069: ------------------------------- Fix Version/s: 10.0.0.Final > Duplicated jipijapa module > -------------------------- > > Key: WFLY-6069 > URL: https://issues.jboss.org/browse/WFLY-6069 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 10.0.0.CR5 > Reporter: Jan Martiska > Assignee: Scott Marlow > Priority: Critical > Fix For: 10.0.0.Final > > > modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar > modules/system/layers/base/org/hibernate/4.3/jipijapa-hibernate4-3-10.0.0.CR6-redhat-1.jar > Refer to this tattletale report: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Accep... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2007) Adapt code to use new Java 8 features

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2007?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2007 at 1/26/16 8:50 AM: --------------------------------------------------------- Also look at * -MessageBatch-: DONE * Table (Visitor) * Use default methods in interfaces * -Condition / CondVar- : DONE was (Author: belaban): Also look at * -MessageBatch-: DONE * Table (Visitor) * Use default methods in interfaces * Replace NotifyingFuture with CompletableFuture * -Condition / CondVar- : DONE > Adapt code to use new Java 8 features > ------------------------------------- > > Key: JGRP-2007 > URL: https://issues.jboss.org/browse/JGRP-2007 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > E.g replace loops for forEach() etc -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016