[jboss-jira] [JBoss JIRA] (WFCORE-2171) StackOverflowError after repeated management write ops

Brian Stansberry (JIRA) issues at jboss.org
Thu Jan 12 20:41:00 EST 2017


     [ https://issues.jboss.org/browse/WFCORE-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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.



> StackOverflowError after repeated management write ops
> ------------------------------------------------------
>
>                 Key: WFCORE-2171
>                 URL: https://issues.jboss.org/browse/WFCORE-2171
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Alpha18
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


More information about the jboss-jira mailing list