[JBoss JIRA] (WFLY-6863) Excluded contexts which are not specific to a host should be excluded on all hosts
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6863?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reopened WFLY-6863:
----------------------------------
> Excluded contexts which are not specific to a host should be excluded on all hosts
> ----------------------------------------------------------------------------------
>
> Key: WFLY-6863
> URL: https://issues.jboss.org/browse/WFLY-6863
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Tomcat8 (haven't tried elsewhere yet); mod_cluster version 2.0.0.Alpha1-SNAPSHOT
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> With the following configuration:
> {code}
> <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener"
> loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric"
> loadMetricCapacity="1"
> loadHistory="9"
> loadDecayFactor="2"
> stickySession="true"
> stickySessionForce="false"
> stickySessionRemove="true"
> advertise="true"
> advertiseGroupAddress="224.0.1.105"
> advertisePort="23364"
> advertiseInterface="10.40.4.50"
> excludedContexts="ROOT,docs,manager,host-manager,examples"
> />
> {code}
> And these contexts in webapps:
> {code}
> clusterbench docs examples host-manager manager ROOT
> {code}
> One expects this output on Mod_cluster manger console:
> {code}
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> It works, unless you configure additional VirtualHosts:
> {code}
> <Host name="LOCALHOST" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>LOCALHOST</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h %l %u %t "%r" %s %b" />
> </Host>
> <Host name="KARM.BRQ.REDHAT.COM" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>KARM.BRQ.REDHAT.COM</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h %l %u %t "%r" %s %b" />
> </Host>
> {code}
> result:
> {code}
> Node worker1 (ajp://10.40.4.50:8009):
> Enable Contexts Disable Contexts Stop Contexts
> Balancer: mycluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 100
> Virtual Host 2:
> Contexts:
> /docs, Status: ENABLED Request: 0 Disable Stop
> /manager, Status: ENABLED Request: 0 Disable Stop
> /host-manager, Status: ENABLED Request: 0 Disable Stop
> /examples, Status: ENABLED Request: 0 Disable Stop
> /, Status: ENABLED Request: 0 Disable Stop
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> karm.brq.redhat.com
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> I find this bug being of Critical priority, because it could coax users into believing they excluded certain context while in fact they didn't.
> WDYT? Is it possible to tweak with the Listener's configuration somehow?
> THX.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by David Maes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
David Maes commented on WFLY-6173:
----------------------------------
[~mkouba] thank you for the quick reply.
Our memory issue will probably not be caused by the jackson problem. So I think we'll have to do some investigation on our own.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1313:
-------------------------------------
There are 2 distinct things to be considered here:
1. Will this work?
Also looking at what it does internally, yes I believe your approach is ok (for now, see 2.).
2. Is this supported?
Every time you use an internal class (not belonging to public kie api) you are doing something that by definition is not supported. We don't give any guarantee that those internal classes will remain as they are now and their behaviour can change literally at any new commit.
I hope this helps,
Mario
> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
> Key: DROOLS-1313
> URL: https://issues.jboss.org/browse/DROOLS-1313
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SAVE_SimpleTest5.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario. If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> - Create a new ReleaseId
> - Create a new KieFileSystem
> - Generate and write the PomXML for the ReleaseId created above
> - Create a new KieModuleModel
> - Create a new KieBaseModel
> - Write the ModuleModel XML to the KieFileSystem
> - Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> - Create a new KieBuilder
> - Do a buildall() with the KieBuilder
> - Create a new KieContainer
> - Create a new KieSession from the KieContainer
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> - Delete 2 rules from the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Add 2 new rules to the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
> - Rule_120_Triggered_Part_1_ 0 is not there
> - Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> - Delete 1 rule from the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Add 2 new rules to the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
> - Rule_120_Triggered_Part_1_ 0 is STILL not there
> - TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> - Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-6173:
------------------------------------
[~davidmaes] The first problem with {{org.jboss.el.cache.BeanPropertiesCache}} was fixed in 10.1.0 (see also WFLY-6347). But the other issue with {{com.fasterxml.jackson.databind.util.ClassUtil#sCached}} is fixed in 11.0.0.Alpha1 (see also WFLY-7037). Neither of these issues is caused by CDI/Weld.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Tomas Remes commented on WFLY-6173:
-----------------------------------
Hi,
In 10.1.0.Final there is https://issues.jboss.org/browse/WFLY-7037. So maybe this could cause the problem.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by David Maes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
David Maes commented on WFLY-6173:
----------------------------------
Hello [~mkouba],
Our development team is using wildfly 10.1.0 for the moment.
We are having the same issue described here. After multiple deploys/undeploys our server crashes with een OOM exception. The "fix version" field for this issue has not yet been set. But I'm guessing it was fixed in the 10.1.0 release. The changelog of this release did not contain the bug.
If this issue was resolved in the 10.1.0 release then I am guessing we are having another cause for the OOM. If so we will investigate and log an issue here.
Greetings,
David
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1199) Memory leak in KieScanner
by Mrunali Patil (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1199?page=com.atlassian.jira.plugi... ]
Mrunali Patil commented on DROOLS-1199:
---------------------------------------
Hi Joni,
Thanks for the update. We have downgraded the version to 6.2.0 Final.
Thanks,
Mrunali
> Memory leak in KieScanner
> -------------------------
>
> Key: DROOLS-1199
> URL: https://issues.jboss.org/browse/DROOLS-1199
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Viacheslav Krot
> Assignee: Mario Fusco
> Fix For: 7.0.0.Beta1
>
>
> I'm not sure, but it seems there is a memory leak in KieScanner, not in scanner directly, but somewhere in plexus used internally.
> If you start KieScanner with version = LATEST, start it with interval say 1 second and sample memory with visualvm (or any other), you can watch number of instances org.eclipse.sisu.plexus.* growing over time. And they cannot be garbage collected - memory root is timer thread. This happens in drools 6.4.0, in 6.3.0 this issue was absent.
> Eventually application fails with OOM.
> As a workaround we call KieScanner#scan manually in a separate thread pool that is recreated from time to time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7290) Unable to remove elytron ldap-key-store
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7290?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-7290:
-------------------------------
Description:
Once ldap-key-store is added it can't be removed.
{code}
[standalone@localhost:9990 /] /subsystem=elytron/dir-context=b:add(url=ldap://localhost, principal="CN=user,DC=wildfly,DC=org", credential=password)
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=elytron/ldap-key-store=b:add(dir-context=b,search-path="DC=wildfly,DC=org")
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=elytron/ldap-key-store=b:remove()
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext",
"rolled-back" => true
}
{code}
which leads to error in server log
{code}
14:55:41,841 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 12) WFLYCTL0013: Operation ("remove") failed - address: ([
("subsystem" => "elytron"),
("ldap-key-store" => "b")
]): java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
at java.security.KeyStore.size(KeyStore.java:1271)
at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
at java.security.KeyStore.size(KeyStore.java:1271)
at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
at org.jboss.as.controller.AbstractRemoveStepHandler.execute(AbstractRemoveStepHandler.java:66)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]]
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
at javax.naming.InitialContext.init(InitialContext.java:244)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
... 31 more
Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:377)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:365)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
... 43 more
{code}
was:
Once ldap-key-store is added it can't be removed.
{code}
[standalone@localhost:9990 /] /subsystem=elytron/dir-context=b:add(url=ldap://dev156-w2012-x86-64.mw.lab.eng.bos.redhat.com, principal="CN=jbossqa,CN=Users,DC=JBOSS3,DC=test", credential=jboss42)
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=elytron/ldap-key-store=b:add(dir-context=b,search-path="O=eapqe,DC=JBOSS3,DC=test")
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=elytron/ldap-key-store=b:remove()
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext",
"rolled-back" => true
}
{code}
which leads to error in server log
{code}
14:55:41,841 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 12) WFLYCTL0013: Operation ("remove") failed - address: ([
("subsystem" => "elytron"),
("ldap-key-store" => "b")
]): java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
at java.security.KeyStore.size(KeyStore.java:1271)
at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
at java.security.KeyStore.size(KeyStore.java:1271)
at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
at org.jboss.as.controller.AbstractRemoveStepHandler.execute(AbstractRemoveStepHandler.java:66)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]]
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
at javax.naming.InitialContext.init(InitialContext.java:244)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
... 31 more
Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:377)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:365)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
... 43 more
{code}
> Unable to remove elytron ldap-key-store
> ---------------------------------------
>
> Key: WFLY-7290
> URL: https://issues.jboss.org/browse/WFLY-7290
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Priority: Critical
>
> Once ldap-key-store is added it can't be removed.
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/dir-context=b:add(url=ldap://localhost, principal="CN=user,DC=wildfly,DC=org", credential=password)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=elytron/ldap-key-store=b:add(dir-context=b,search-path="DC=wildfly,DC=org")
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=elytron/ldap-key-store=b:remove()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext",
> "rolled-back" => true
> }
> {code}
> which leads to error in server log
> {code}
> 14:55:41,841 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 12) WFLYCTL0013: Operation ("remove") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-key-store" => "b")
> ]): java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
> at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
> at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
> at java.security.KeyStore.size(KeyStore.java:1271)
> at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
> at java.security.KeyStore.size(KeyStore.java:1271)
> at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
> at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
> at org.jboss.as.controller.AbstractRemoveStepHandler.execute(AbstractRemoveStepHandler.java:66)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> ... 31 more
> Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:377)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:365)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> ... 43 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months