[JBoss JIRA] (AS7-6251) SimpleAttributeDefinition BACKGROUNDVALIDATIONMILLIS defined incompatible ModelType and ParameterValidator
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6251?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6251:
---------------------------------------
The xs:nonNegativeInteger type is not limited to the upper range of a Java int.
http://books.xmlschemata.org/relaxng/ch19-77247.html
"The value space of xsd:nonNegativeInteger includes the set of all the integers greater than or equal to zero, with no restriction of range."
> SimpleAttributeDefinition BACKGROUNDVALIDATIONMILLIS defined incompatible ModelType and ParameterValidator
> ----------------------------------------------------------------------------------------------------------
>
> Key: AS7-6251
> URL: https://issues.jboss.org/browse/AS7-6251
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> The SimpleAttributeDefinition BACKGROUNDVALIDATIONMILLIS is defined :
> {code:title=org.jboss.as.connector.subsystems.common.pool.Constants.java|borderStyle=solid}
> public static final SimpleAttributeDefinition BACKGROUNDVALIDATIONMILLIS = new SimpleAttributeDefinition(BACKGROUNDVALIDATIONMILLIS_NAME, Validation.Tag.BACKGROUND_VALIDATION_MILLIS.getLocalName(), new ModelNode(), ModelType.LONG, true, true, MeasurementUnit.MILLISECONDS, new IntRangeValidator(1, true, true));
> {code}
> The ModelType should be an integer value as defined in jboss-as-datasources_1_1.xsd:
> {code:xml}
> <xs:element name="background-validation-millis" type="xs:nonNegativeInteger" minOccurs="0">
> <xs:annotation>
> <xs:documentation>
> <![CDATA[[
> The background-validation-millis element specifies the amount of
> time, in millis, that background validation will run.
> ]]>
> </xs:documentation>
> </xs:annotation>
> </xs:element>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (AS7-6254) Memory leak caused by retained connection ids in RemotingConnectorServer superclass
by Taras Tielkes (JIRA)
[ https://issues.jboss.org/browse/AS7-6254?page=com.atlassian.jira.plugin.s... ]
Taras Tielkes edited comment on AS7-6254 at 1/1/13 8:25 AM:
------------------------------------------------------------
Note that this issue is still present in 7.1.3 EAP.
Steps to reproduce:
# Install clean 7.1.3 JBoss instance
# Add JMX user using the provided admin script
# Run a client that repeatedly creates a JMX connection (using the {{service:jmx:remoting-jmx}} protocol, using the provided {{jboss-client.jar}} library)
After sufficient time, depending on the configured heap size, you'll see the JBoss server JVM run out of memory.
I have an {{hprof}} heap dump that shows the leak reproduced by the steps above. If you're interested in looking at that, let me know where to upload it.
was (Author: taras.tielkes):
Note that this issue is still present in 7.1.3 EAP.
Steps to reproduce:
1) Install clean 7.1.3 JBoss instance
2) Add JMX user using the provided admin script
3) Run a client that repeatedly creates a JMX connection (using the {{service:jmx:remoting-jmx}} protocol, using the provided {{jboss-client.jar}} library)
After sufficient time, depending on the configured heap size, you'll see the JBoss server JVM run out of memory.
I have an {{hprof}} heap dump that shows the leak reproduced by the steps above. If you're interested in looking at that, let me know where to upload it.
> Memory leak caused by retained connection ids in RemotingConnectorServer superclass
> ------------------------------------------------------------------------------------
>
> Key: AS7-6254
> URL: https://issues.jboss.org/browse/AS7-6254
> Project: Application Server 7
> Issue Type: Bug
> Components: JMX
> Affects Versions: 7.1.1.Final
> Reporter: Taras Tielkes
> Assignee: Stuart Douglas
>
> We're running 7.1.1, with a patch applied for REMJMX-45 to limit the worst leaks coming from the JMX subsystem.
> However, even with this patch applied we can only survive for a few days in a production-like scenario.
> It seems that {{org.jboss.remotingjmx.RemotingConnectorServer}} never calls the {{connectionClosed()}}/{{connectionFailed()}} methods in its superclass.
> As such, the connection ids that are stored in the field {{javax.management.remote.JMXConnectorServer#connectionIds}} are never released.
> Given sufficient connections made to a running instance of 7.1.1 (for example, various monitoring tools), an out-of-memory end-state is inevitable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (AS7-6254) Memory leak caused by retained connection ids in RemotingConnectorServer superclass
by Taras Tielkes (JIRA)
[ https://issues.jboss.org/browse/AS7-6254?page=com.atlassian.jira.plugin.s... ]
Taras Tielkes updated AS7-6254:
-------------------------------
Affects Version/s: 7.1.3.Final (EAP)
> Memory leak caused by retained connection ids in RemotingConnectorServer superclass
> ------------------------------------------------------------------------------------
>
> Key: AS7-6254
> URL: https://issues.jboss.org/browse/AS7-6254
> Project: Application Server 7
> Issue Type: Bug
> Components: JMX
> Affects Versions: 7.1.1.Final, 7.1.3.Final (EAP)
> Reporter: Taras Tielkes
> Assignee: Stuart Douglas
>
> We're running 7.1.1, with a patch applied for REMJMX-45 to limit the worst leaks coming from the JMX subsystem.
> However, even with this patch applied we can only survive for a few days in a production-like scenario.
> It seems that {{org.jboss.remotingjmx.RemotingConnectorServer}} never calls the {{connectionClosed()}}/{{connectionFailed()}} methods in its superclass.
> As such, the connection ids that are stored in the field {{javax.management.remote.JMXConnectorServer#connectionIds}} are never released.
> Given sufficient connections made to a running instance of 7.1.1 (for example, various monitoring tools), an out-of-memory end-state is inevitable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (AS7-6254) Memory leak caused by retained connection ids in RemotingConnectorServer superclass
by Taras Tielkes (JIRA)
[ https://issues.jboss.org/browse/AS7-6254?page=com.atlassian.jira.plugin.s... ]
Taras Tielkes commented on AS7-6254:
------------------------------------
Note that this issue is still present in 7.1.3 EAP.
Steps to reproduce:
1) Install clean 7.1.3 JBoss instance
2) Add JMX user using the provided admin script
3) Run a client that repeatedly creates a JMX connection (using the {{service:jmx:remoting-jmx}} protocol, using the provided {{jboss-client.jar}} library)
After sufficient time, depending on the configured heap size, you'll see the JBoss server JVM run out of memory.
I have an {{hprof}} heap dump that shows the leak reproduced by the steps above. If you're interested in looking at that, let me know where to upload it.
> Memory leak caused by retained connection ids in RemotingConnectorServer superclass
> ------------------------------------------------------------------------------------
>
> Key: AS7-6254
> URL: https://issues.jboss.org/browse/AS7-6254
> Project: Application Server 7
> Issue Type: Bug
> Components: JMX
> Affects Versions: 7.1.1.Final
> Reporter: Taras Tielkes
> Assignee: Stuart Douglas
>
> We're running 7.1.1, with a patch applied for REMJMX-45 to limit the worst leaks coming from the JMX subsystem.
> However, even with this patch applied we can only survive for a few days in a production-like scenario.
> It seems that {{org.jboss.remotingjmx.RemotingConnectorServer}} never calls the {{connectionClosed()}}/{{connectionFailed()}} methods in its superclass.
> As such, the connection ids that are stored in the field {{javax.management.remote.JMXConnectorServer#connectionIds}} are never released.
> Given sufficient connections made to a running instance of 7.1.1 (for example, various monitoring tools), an out-of-memory end-state is inevitable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months