[JBoss JIRA] (AS7-6256) Problem while accessing local interface using context.lookup
by Gaurav Gupta (JIRA)
Gaurav Gupta created AS7-6256:
---------------------------------
Summary: Problem while accessing local interface using context.lookup
Key: AS7-6256
URL: https://issues.jboss.org/browse/AS7-6256
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.1.Final
Reporter: Gaurav Gupta
Assignee: jaikiran pai
11:31:05,795 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/protectoria]] (MSC service thread 1-1) Exception sending context initialized event to listener instance of class no.messageman.protectoria.core.security.CacheResourceRoleMapping: java.lang.ClassCastException: no.messageman.protectoria.core.security.IRBAC$$$view18 cannot be cast to no.messageman.protectoria.core.security.IRBAC
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6139) ModelTypeValidator is overly lenient about numeric types
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/AS7-6139?page=com.atlassian.jira.plugin.s... ]
Chao Wang updated AS7-6139:
---------------------------
Attachment: AS7-6139.patch
Is the patch file a suitable way to check the numeric type? Comparing two different types are equal in value
> ModelTypeValidator is overly lenient about numeric types
> --------------------------------------------------------
>
> Key: AS7-6139
> URL: https://issues.jboss.org/browse/AS7-6139
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Brian Stansberry
> Priority: Minor
> Attachments: AS7-6139.patch
>
>
> ModelTypeValidator does some conversion checks to see if a passed in ModelNode meets the requirements of the valid type. These checks are overly lenient when it comes to numeric types as they rely only on the ModelNode.asXXX() methods not failing. But those methods don't fail even if the conversion involves a narrowing.
> For example, calling new ModelNode(Long.MAX_LONG).asInt() will not fail, but if the user passed in such a value for use in an attribute of type INT the stored value would not be what was expected.
> Note this is minor as in many, many cases ModelTypeValidator subclasses like IntRangeValidator are used, and those subclasses enforce ranges.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-5842) Upgrade to joda time 2.1
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5842?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-5842:
---------------------------------------
Please send an email about this to the jboss-as7-dev mailing list. This library is a dependency of a number of other AS dependencies, and the leads responsible for integrating those dependencies need to agree to this update. It is not a direct dependency of the AS itself.
Here are the modules that depend on the org.joda.time module:
build/src/main/resources/modules/org/apache/cxf/impl/main/module.xml: <module name="org.joda.time" />
build/src/main/resources/modules/org/apache/ws/security/main/module.xml: <module name="org.joda.time" />
build/src/main/resources/modules/org/codehaus/jackson/jackson-mapper-asl/main/module.xml: <module name="org.joda.time"/>
build/src/main/resources/modules/org/hibernate/validator/main/module.xml: <module name="org.joda.time"/>
build/src/main/resources/modules/org/opensaml/main/module.xml: <module name="org.joda.time"/>
> Upgrade to joda time 2.1
> ------------------------
>
> Key: AS7-5842
> URL: https://issues.jboss.org/browse/AS7-5842
> Project: Application Server 7
> Issue Type: Component Upgrade
> Affects Versions: 7.1.1.Final
> Environment: -
> Reporter: Wouter Oet
>
> JBoss AS 7.1.1 ships with Joda-time 1.6.2, however the newer version 2.1 is available and contains bugfixes and improvements.
--
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
13 years, 4 months
[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
13 years, 4 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
13 years, 4 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
13 years, 4 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
13 years, 4 months