[JBoss JIRA] (WFLY-3889) JMX monitoring is extremely memory inefficient
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3889?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-3889:
----------------------------------
Seems the PR was done by Brian, not Jeff :-)
> JMX monitoring is extremely memory inefficient
> ----------------------------------------------
>
> Key: WFLY-3889
> URL: https://issues.jboss.org/browse/WFLY-3889
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JMX
> Affects Versions: JBoss AS7 7.1.1.Final, 9.0.0.Alpha1
> Reporter: Koen Janssens
> Assignee: Brian Stansberry
>
> When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created.
> A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class.
> More background on associated forum thread
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3889) JMX monitoring is extremely memory inefficient
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3889?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-3889:
-----------------------------
Assignee: Brian Stansberry (was: Jeff Mesnil)
> JMX monitoring is extremely memory inefficient
> ----------------------------------------------
>
> Key: WFLY-3889
> URL: https://issues.jboss.org/browse/WFLY-3889
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JMX
> Affects Versions: JBoss AS7 7.1.1.Final, 9.0.0.Alpha1
> Reporter: Koen Janssens
> Assignee: Brian Stansberry
>
> When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created.
> A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class.
> More background on associated forum thread
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3889) JMX monitoring is extremely memory inefficient
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3889?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-3889:
-----------------------------
Assignee: Jeff Mesnil (was: Brian Stansberry)
> JMX monitoring is extremely memory inefficient
> ----------------------------------------------
>
> Key: WFLY-3889
> URL: https://issues.jboss.org/browse/WFLY-3889
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JMX
> Affects Versions: JBoss AS7 7.1.1.Final, 9.0.0.Alpha1
> Reporter: Koen Janssens
> Assignee: Jeff Mesnil
>
> When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created.
> A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class.
> More background on associated forum thread
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3889) JMX monitoring is extremely memory inefficient
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3889?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-3889:
---------------------------------
Assignee: Brian Stansberry (was: Jeff Mesnil)
> JMX monitoring is extremely memory inefficient
> ----------------------------------------------
>
> Key: WFLY-3889
> URL: https://issues.jboss.org/browse/WFLY-3889
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JMX
> Affects Versions: JBoss AS7 7.1.1.Final, 9.0.0.Alpha1
> Reporter: Koen Janssens
> Assignee: Brian Stansberry
>
> When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created.
> A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class.
> More background on associated forum thread
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3889) JMX monitoring is extremely memory inefficient
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3889?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-3889:
----------------------------------
[~jmesnil] Assigning to you since you already opened a PR :-)
> JMX monitoring is extremely memory inefficient
> ----------------------------------------------
>
> Key: WFLY-3889
> URL: https://issues.jboss.org/browse/WFLY-3889
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JMX
> Affects Versions: JBoss AS7 7.1.1.Final, 9.0.0.Alpha1
> Reporter: Koen Janssens
> Assignee: Jeff Mesnil
>
> When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created.
> A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class.
> More background on associated forum thread
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3889) JMX monitoring is extremely memory inefficient
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3889?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-3889:
-----------------------------
Assignee: Jeff Mesnil (was: Kabir Khan)
> JMX monitoring is extremely memory inefficient
> ----------------------------------------------
>
> Key: WFLY-3889
> URL: https://issues.jboss.org/browse/WFLY-3889
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JMX
> Affects Versions: JBoss AS7 7.1.1.Final, 9.0.0.Alpha1
> Reporter: Koen Janssens
> Assignee: Jeff Mesnil
>
> When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created.
> A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class.
> More background on associated forum thread
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFCORE-128) Nonexistent ldap group causes authentication to fail in security-realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-128?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFCORE-128:
------------------------------------
Fix Version/s: 1.0.0.Alpha9
> Nonexistent ldap group causes authentication to fail in security-realm
> -----------------------------------------------------------------------
>
> Key: WFCORE-128
> URL: https://issues.jboss.org/browse/WFCORE-128
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha8
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha9
>
>
> The LdapGroupSearcher code will fail if it tries to lookup a group that
> does not exist on the local ldap server.
> This can happen when the ldap systems are configured as trusted domains.
> Even though the security-realm is not configured to use the trusted domain
> (it is configured to only look at a single ldap server), the
> user's entry on one ldap server could point at a group that exists on
> the other (trusted) ldap server.
> The LdapGroupSearcher code attempts to lookup this role and it fails. This
> failure is sent back to the http server which results in an HTTP 500 error
> and leaves the user with no way to authenticate/login.
> There is currently not a way to tell the group searcher code to ignore the
> group/role that cannot be found.
> 2014-06-06 12:44:39,819 TRACE [org.jboss.as.domain.management.security] (XNIO-1 task-1) Group found with distinguishedName=cn=TestManagedRole,ou=People,dc=my-ds-domain,dc=com
> 2014-06-06 12:44:39,821 TRACE [org.jboss.as.domain.management.security] (XNIO-1 task-1) Failure supplementing Subject: javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'cn=TestManagedRole,ou=People,dc=my-ds-domain,dc=com'
> at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3112) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1332) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:231) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:139) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:127) [rt.jar:1.7.0_45]
> at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.7.0_45]
> at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.7.0_45]
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:256) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:191) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:223) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroupEntries(LdapSubjectSupplementalService.java:218) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:195) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:188) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:200) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:155) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:120) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:110) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:57) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFCORE-128) Nonexistent ldap group causes authentication to fail in security-realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-128?page=com.atlassian.jira.plugin... ]
Darran Lofthouse moved WFLY-3464 to WFCORE-128:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-128 (was: WFLY-3464)
Affects Version/s: 1.0.0.Alpha8
(was: 8.1.0.Final)
Component/s: Domain Management
(was: Domain Management)
> Nonexistent ldap group causes authentication to fail in security-realm
> -----------------------------------------------------------------------
>
> Key: WFCORE-128
> URL: https://issues.jboss.org/browse/WFCORE-128
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha8
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
>
> The LdapGroupSearcher code will fail if it tries to lookup a group that
> does not exist on the local ldap server.
> This can happen when the ldap systems are configured as trusted domains.
> Even though the security-realm is not configured to use the trusted domain
> (it is configured to only look at a single ldap server), the
> user's entry on one ldap server could point at a group that exists on
> the other (trusted) ldap server.
> The LdapGroupSearcher code attempts to lookup this role and it fails. This
> failure is sent back to the http server which results in an HTTP 500 error
> and leaves the user with no way to authenticate/login.
> There is currently not a way to tell the group searcher code to ignore the
> group/role that cannot be found.
> 2014-06-06 12:44:39,819 TRACE [org.jboss.as.domain.management.security] (XNIO-1 task-1) Group found with distinguishedName=cn=TestManagedRole,ou=People,dc=my-ds-domain,dc=com
> 2014-06-06 12:44:39,821 TRACE [org.jboss.as.domain.management.security] (XNIO-1 task-1) Failure supplementing Subject: javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'cn=TestManagedRole,ou=People,dc=my-ds-domain,dc=com'
> at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3112) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1332) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:231) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:139) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:127) [rt.jar:1.7.0_45]
> at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.7.0_45]
> at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.7.0_45]
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:256) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:191) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:223) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroupEntries(LdapSubjectSupplementalService.java:218) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:195) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:188) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:200) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:155) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:120) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:110) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:57) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFCORE-125) Security realm cache definitions not possible for LDAP prinicipal to group group loading.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-125?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-125:
------------------------------------------------
Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 1146117|https://bugzilla.redhat.com/show_bug.cgi?id=1146117] from ASSIGNED to POST
> Security realm cache definitions not possible for LDAP prinicipal to group group loading.
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-125
> URL: https://issues.jboss.org/browse/WFCORE-125
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 1.0.0.Alpha8
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha9
>
>
> It's not possible to configure LDAP cache in security realms under "authorization=ldap/group-search=principal-to-group"
> Possible reason:
> The LdapCacheResourceDefinition is not registered under the org.jboss.as.domain.management.security.PrincipalToGroupResourceDefinition
> When I try to add the cache configuration manually to standalone.xml, server doesn't start and reports:
> 15:23:44,619 ERROR [org.jboss.as.controller] (Controller Boot Thread) JBAS014629: No resource definition is registered for address [
> ("core-service" => "management"),
> ("security-realm" => "JBossTest"),
> ("authorization" => "ldap"),
> ("group-search" => "principal-to-group"),
> ("cache" => "by-search-time")
> ]
> 15:23:44,621 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years