[ https://issues.jboss.org/browse/WFCORE-2171?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2171: ------------------------------------- Description: I wrote an integration test that allows you to set a system prop and based on the value X it repeatedly calls full-replace-deployment X times (see https://github.com/wildfly/wildfly-core/pull/2062). When I try and run it 30K times I get: 2017-01-09 22:28:40,431 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]): java.lang.StackOverflowError at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030) at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030) at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030) .... repeat over and over I think this is due to BasicResource.clone()'s handling of orderedChildResources. It takes the internal set, wraps it in Collections.unmodifiableSet and passes it in to the clone, which in turn will do the same thing if cloned. So for each management write op, the same underlying set gets wrapped in another layer. Hence the overflow of size calls. was: I wrote an integration test that allows you to set a system prop and repeatedly call full-replace-deployment (see https://github.com/wildfly/wildfly-core/pull/2062). When I try and run it 30K times I get: 2017-01-09 22:28:40,431 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]): java.lang.StackOverflowError at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030) at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030) at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030) .... repeat over and over I think this is due to BasicResource.clone()'s handling of orderedChildResources. It takes the internal set, wraps it in Collections.unmodifiableSet and passes it in to the clone, which in turn will do the same thing if cloned. So for each management write op, the same underlying set gets wrapped in another layer. Hence the overflow of size calls. -- This message was sent by Atlassian JIRA (v7.2.3#72005)