May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5627) Unable to view the infinispan statistics from CLI

by PEANO LUCA (JIRA)

[ https://issues.jboss.org/browse/WFLY-5627?page=com.atlassian.jira.plugin.... ] PEANO LUCA commented on WFLY-5627: ---------------------------------- and witch cash is used? > Unable to view the infinispan statistics from CLI > ------------------------------------------------- > > Key: WFLY-5627 > URL: https://issues.jboss.org/browse/WFLY-5627 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Chao Wang > Assignee: Paul Ferraro > > When I investigated https://bugzilla.redhat.com/show_bug.cgi?id=1276441 and tested its scenario with WildFly as: > {noformat} > Steps to Reproduce: > =================== > 1) Build latest Wildfly master and consider `standalone-ha.xml` file. > 2) Enable the infinispan statistics in the standalone-ha.xml file. > Configuration looks as below: > ----- > <subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default"> > <transport lock-timeout="60000"/> > <replicated-cache name="default" mode="SYNC"> > <transaction mode="BATCH"/> > </replicated-cache> > </cache-container> > <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist" statistics-enabled="true"> > <transport lock-timeout="60000"/> > <distributed-cache name="dist" statistics-enabled="true" mode="ASYNC" l1-lifespan="0" owners="2"> > <locking isolation="REPEATABLE_READ"/> > <transaction mode="BATCH"/> > <file-store/> > </distributed-cache> > </cache-container> > ----- > 3) Start the server with `standalone-ha.xml` file. > 4) Deploy the cluster web application and hit the application. > 5) and check the infinispan statistics by using the below cli command: > ----- > /subsystem=infinispan/cache-container=web/distributed-cache=dist:read-resource(include-runtime=true) > ----- > 6) Values for the runtime parameters(i.e.,number-of-entries, hits, etc.,) never change. > Actual results: > =============== > - Values for the runtime parameters(i.e.,number-of-entries, hits, etc.,) never changed. > Expected results: > ================= > - There should be a change in the runtime parameters values. > Additional info: > ================= > - I can see the expected result from the jconsole statistics. > jconsole -> mbean tab -> jboss.infinispan -> Cache -> $application -> web -> Statistics. > {noformat} > It actually works fine with 10.0.0.CR4, but it breaks in latest master. It seems commit https://github.com/wildfly/wildfly/commit/79b49a3b930fd5c7cc29e9fe1c9a747... makes such difference. Once I revert this commit, I can see dynamic statistics change in CLI operation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2876) runtime-failure-causes-rollback does not seem to have effect when configured in model

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2876?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet commented on WFCORE-2876: ------------------------------------------- Ok, this is due to the fact that the deployment failed on boot. Because of that FileSystemDeploymentService.forcedUndeployScan is executed when boot finishes and undeploy the failed deployments. > runtime-failure-causes-rollback does not seem to have effect when configured in model > ------------------------------------------------------------------------------------- > > Key: WFCORE-2876 > URL: https://issues.jboss.org/browse/WFCORE-2876 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner > Affects Versions: 3.0.0.Beta21 > Reporter: Miroslav Novak > Assignee: ehsavoie Hugonnet > > This is follow up on discussion in WFCORE-1912. There is difference in behavior if deployment is deployed like: > {code}deploy ~/tmp/mdb1.jar --unmanaged --headers={rollback-on-runtime-failure=false}{code} > and if it's deployed by copying to deployments directory and setting {{rollback-on-runtime-failure=false}} in model: > {code} > /subsystem=deployment-scanner/scanner=default:write-attribute(name=runtime-failure-causes-rollback,value=false) > {code} > If it's deployed by the 1st way using CLI {{deploy}} command then If deployment is missing some dependencies (like connection factories, queues/topics) and those are added later then deployment is able recover from it and start working without need to reload/restart server or redeploy. > However if it's deployed the 2nd way then deployment does not recover when missing dependencies are added. It looks like attribute {{runtime-failure-causes-rollback}} does not have the effect in this case. > This is causing problems when Artemis is configured in colocated HA topology with replicated journal where it takes some time for Artemis to activate but deployment which depends on some connection factories and queues has already tried to deploy. We need deployment to recover from this situation automatically. Restart/Reload will not help in this case as it would end up in the same situation. Only manual redeploy will help which is a workaround. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1211) FileAuditEndpoint doesn't allow for file encoding to be overridden

by James Perkins (JIRA)

James Perkins created ELY-1211: ---------------------------------- Summary: FileAuditEndpoint doesn't allow for file encoding to be overridden Key: ELY-1211 URL: https://issues.jboss.org/browse/ELY-1211 Project: WildFly Elytron Issue Type: Enhancement Reporter: James Perkins Assignee: Darran Lofthouse The {{FileAuditEndpoint}} doesn't allow for the file encoding to be overridden. It should likely allow the encoding to be overridden or at the very least specify {{UTF-8}} as the default. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-950) Add local audit log rotation

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/ELY-950?page=com.atlassian.jira.plugin.sy... ] James Perkins commented on ELY-950: ----------------------------------- Will this be solved by the changes in ELY-1206? > Add local audit log rotation > ---------------------------- > > Key: ELY-950 > URL: https://issues.jboss.org/browse/ELY-950 > Project: WildFly Elytron > Issue Type: Task > Components: Audit > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta50 > > > Could be by time, size, rotate on start-up or a combination. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-109) Installation Doc

by Matt Mahoney (JIRA)

Matt Mahoney created HAWKULARQE-109: --------------------------------------- Summary: Installation Doc Key: HAWKULARQE-109 URL: https://issues.jboss.org/browse/HAWKULARQE-109 Project: Hawkular QE Issue Type: Task Reporter: Matt Mahoney Assignee: Michael Foley Review Installation Doc: https://doc-stage.usersys.redhat.com/documentation/en-us/red_hat_middlewa... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1200) Elytron - when security Providers are not configured correctly in AuthenticationConfiguration, remoting connection hangs during SASL authentication

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1200?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1200: ---------------------------------- Fix Version/s: 1.1.0.Beta48 > Elytron - when security Providers are not configured correctly in AuthenticationConfiguration, remoting connection hangs during SASL authentication > --------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1200 > URL: https://issues.jboss.org/browse/ELY-1200 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Reporter: Josef Cacek > Assignee: David Lloyd > Priority: Critical > Fix For: 1.1.0.Beta48 > > > When AuthenticationConfiguration contains wrongly configured security Providers (null used), the management remoting connection hangs during SASL authentication. > {code:java} > AuthenticationConfiguration.useProviders(() -> new Provider[] { null }) > {code} > *Expected behavior:* > Execution should fail immediately. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1203) Elytron AuthenticationConfiguration uses SASL mechanism from incorrect security Provider in some cases

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1203?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1203: ---------------------------------- Fix Version/s: 1.1.0.Beta48 > Elytron AuthenticationConfiguration uses SASL mechanism from incorrect security Provider in some cases > ------------------------------------------------------------------------------------------------------ > > Key: ELY-1203 > URL: https://issues.jboss.org/browse/ELY-1203 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta48 > > > In our tests for PLAIN SASL mechanism in the AS testsuite we realized a wrong SaslClient implementation is used. Instead of the Elytron one, the JDK provided one is used ({{com.sun.security.sasl.PlainClient}}). > The Elytron client builds the AuthenticationContext and runs executed code in this way: > {code:java} > AuthenticationConfiguration authnCfg = AuthenticationConfiguration.EMPTY.allowSaslMechanisms(MECHANISM_PLAIN) > .useName(USERNAME).usePassword("wrongPassword") > .useProviders(() -> new Provider[] { new WildFlyElytronProvider() }); > AuthenticationContext.empty().with(MatchRule.ALL, authnCfg).run(...) > {code} > It seems to be related to what's included on classpath. When we use the same code in [elytron-client-demo|https://github.com/jboss-security-qe/elytron-client-demo] the correct mechanism is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1203) Elytron AuthenticationConfiguration uses SASL mechanism from incorrect security Provider in some cases

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1203?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1203. ----------------------------------- Resolution: Done > Elytron AuthenticationConfiguration uses SASL mechanism from incorrect security Provider in some cases > ------------------------------------------------------------------------------------------------------ > > Key: ELY-1203 > URL: https://issues.jboss.org/browse/ELY-1203 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta48 > > > In our tests for PLAIN SASL mechanism in the AS testsuite we realized a wrong SaslClient implementation is used. Instead of the Elytron one, the JDK provided one is used ({{com.sun.security.sasl.PlainClient}}). > The Elytron client builds the AuthenticationContext and runs executed code in this way: > {code:java} > AuthenticationConfiguration authnCfg = AuthenticationConfiguration.EMPTY.allowSaslMechanisms(MECHANISM_PLAIN) > .useName(USERNAME).usePassword("wrongPassword") > .useProviders(() -> new Provider[] { new WildFlyElytronProvider() }); > AuthenticationContext.empty().with(MatchRule.ALL, authnCfg).run(...) > {code} > It seems to be related to what's included on classpath. When we use the same code in [elytron-client-demo|https://github.com/jboss-security-qe/elytron-client-demo] the correct mechanism is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2060) Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-2060?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-2060: ----------------------------------------------- Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1330729|https://bugzilla.redhat.com/show_bug.cgi?id=1330729] from POST to MODIFIED > Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2060 > URL: https://issues.jboss.org/browse/JGRP-2060 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.9 > Reporter: Brad Maxwell > Assignee: Bela Ban > Fix For: 3.6.10, 4.0 > > > Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2888) Upgrade CLI to use aesh 0.66.18 and jansi 1.16

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2888?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2888: ------------------------------- Issue Type: Component Upgrade (was: Bug) > Upgrade CLI to use aesh 0.66.18 and jansi 1.16 > ---------------------------------------------- > > Key: WFCORE-2888 > URL: https://issues.jboss.org/browse/WFCORE-2888 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > Today jansi 1.11 breaks the rule of being source code 1.6. > jansi 1.16 has been upgraded. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 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 May 2017