December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4211) MBean implementation lifecycle methods in MSC threads

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-4211?page=com.atlassian.jira.plugin.... ] Eduardo Martins updated WFLY-4211: ---------------------------------- Component/s: JMX > MBean implementation lifecycle methods in MSC threads > ----------------------------------------------------- > > Key: WFLY-4211 > URL: https://issues.jboss.org/browse/WFLY-4211 > Project: WildFly > Issue Type: Bug > Components: JMX > Reporter: Eduardo Martins > Assignee: Jason Greene > > MBean lifecycle methods should not be invoked from MSC threads, the implementation of these may block the thread, for instance due to a JNDI bind. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4211) MBean implementation lifecycle methods in MSC threads

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-4211?page=com.atlassian.jira.plugin.... ] Eduardo Martins reassigned WFLY-4211: ------------------------------------- Assignee: Kabir Khan (was: Jason Greene) > MBean implementation lifecycle methods in MSC threads > ----------------------------------------------------- > > Key: WFLY-4211 > URL: https://issues.jboss.org/browse/WFLY-4211 > Project: WildFly > Issue Type: Bug > Components: JMX > Reporter: Eduardo Martins > Assignee: Kabir Khan > > MBean lifecycle methods should not be invoked from MSC threads, the implementation of these may block the thread, for instance due to a JNDI bind. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4211) MBean implementation lifecycle methods in MSC threads

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-4211?page=com.atlassian.jira.plugin.... ] Eduardo Martins reassigned WFLY-4211: ------------------------------------- Assignee: Eduardo Martins (was: Kabir Khan) > MBean implementation lifecycle methods in MSC threads > ----------------------------------------------------- > > Key: WFLY-4211 > URL: https://issues.jboss.org/browse/WFLY-4211 > Project: WildFly > Issue Type: Bug > Components: JMX > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > MBean lifecycle methods should not be invoked from MSC threads, the implementation of these may block the thread, for instance due to a JNDI bind. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-490) ModelControllerImpl uses SecureRandom per requet for no obvious reason

by James Livingston (JIRA)

James Livingston created WFCORE-490: --------------------------------------- Summary: ModelControllerImpl uses SecureRandom per requet for no obvious reason Key: WFCORE-490 URL: https://issues.jboss.org/browse/WFCORE-490 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Affects Versions: 1.0.0.Alpha15 Reporter: James Livingston Assignee: Brian Stansberry https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... and https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... create a new SecureRandom which is used to seed a normal Random, and that is thrown away after one use. That causes it to use entropy from the OS pool, which if done at a sufficiently high rate on servers can cause stalls. I can't think of any reason why the operation ID would need to be a secure random number rather than a normal one, so unless there is one it may be better to use a normal Random and not drain the entropy pool. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-490) ModelControllerImpl uses SecureRandom per request for no obvious reason

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/WFCORE-490?page=com.atlassian.jira.plugin... ] James Livingston updated WFCORE-490: ------------------------------------ Summary: ModelControllerImpl uses SecureRandom per request for no obvious reason (was: ModelControllerImpl uses SecureRandom per requet for no obvious reason) > ModelControllerImpl uses SecureRandom per request for no obvious reason > ----------------------------------------------------------------------- > > Key: WFCORE-490 > URL: https://issues.jboss.org/browse/WFCORE-490 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha15 > Reporter: James Livingston > Assignee: Brian Stansberry > > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... and https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... create a new SecureRandom which is used to seed a normal Random, and that is thrown away after one use. That causes it to use entropy from the OS pool, which if done at a sufficiently high rate on servers can cause stalls. > I can't think of any reason why the operation ID would need to be a secure random number rather than a normal one, so unless there is one it may be better to use a normal Random and not drain the entropy pool. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-490) ModelControllerImpl uses SecureRandom per request

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/WFCORE-490?page=com.atlassian.jira.plugin... ] James Livingston updated WFCORE-490: ------------------------------------ Summary: ModelControllerImpl uses SecureRandom per request (was: ModelControllerImpl uses SecureRandom per request for no obvious reason) > ModelControllerImpl uses SecureRandom per request > ------------------------------------------------- > > Key: WFCORE-490 > URL: https://issues.jboss.org/browse/WFCORE-490 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha15 > Reporter: James Livingston > Assignee: Brian Stansberry > > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... and https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... create a new SecureRandom which is used to seed a normal Random, and that is thrown away after one use. That causes it to use entropy from the OS pool, which if done at a sufficiently high rate on servers can cause stalls. > I can't think of any reason why the operation ID would need to be a secure random number rather than a normal one, so unless there is one it may be better to use a normal Random and not drain the entropy pool. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4210) Very Slow performance for larger JSF 2 pages.

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/WFLY-4210?page=com.atlassian.jira.plugin.... ] jaikiran pai updated WFLY-4210: ------------------------------- Fix Version/s: (was: JBoss AS7 7.1.1.Final) > Very Slow performance for larger JSF 2 pages. > --------------------------------------------- > > Key: WFLY-4210 > URL: https://issues.jboss.org/browse/WFLY-4210 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web) > Affects Versions: 8.2.0.Final > Environment: Windows 7 64 bit, Oracle JDK 1.7.0-67 64 bit, Wildfly 8.2.0, Tomcat and JBoss 7.1.1. > Reporter: Rodney Kite > Assignee: Remy Maucherat > Attachments: AjaxTest.xhtml, PageAjaxTest.java, testAppWar.ear, testAppWeb.war > > > Very slow page performance using JSF 2 and Wildfly 8.2.0 for larger pages. I am migrating a large application from JBoss AS 7.1.1 to Wildfly 8.2.0 and page performance on loads and posts is very slow. I created a large JSF 2 test page and took timings for JBoss 7.1.1, Wildfly 8.2.0 and Tomcat 7.x using the same Mojarra 2.2.8 implementation as Wildfly. > The attached war file contains mojarra 2.2.8 jars for tomcat. The attached ear file is for JBoss deployments and does not contain mojarra jars. > Example test URL for attached ear and war. > http://localhost:8080/testAppWeb/jsp/AjaxTest.jsf > JBoss 7.1.1 Timings > Page Load: 4.0 Seconds > Post: 4.5 Seconds > Ajax: 4.0 Seconds > Wildfly 8.2.0 Timings > Page Load: 66.0 Seconds > Post: 60 Seconds > Ajax: 55 Seconds > Tomcat 7.x with 2.2.8 Mojarra > Page Load 1.0 Seconds > Post: 0.75 Seconds > Ajax: 0.3 Seconds > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4210) Very Slow performance for larger JSF 2 pages.

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/WFLY-4210?page=com.atlassian.jira.plugin.... ] jaikiran pai updated WFLY-4210: ------------------------------- Component/s: Web (Undertow) (was: Web (JBoss Web)) > Very Slow performance for larger JSF 2 pages. > --------------------------------------------- > > Key: WFLY-4210 > URL: https://issues.jboss.org/browse/WFLY-4210 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Environment: Windows 7 64 bit, Oracle JDK 1.7.0-67 64 bit, Wildfly 8.2.0, Tomcat and JBoss 7.1.1. > Reporter: Rodney Kite > Assignee: Remy Maucherat > Attachments: AjaxTest.xhtml, PageAjaxTest.java, testAppWar.ear, testAppWeb.war > > > Very slow page performance using JSF 2 and Wildfly 8.2.0 for larger pages. I am migrating a large application from JBoss AS 7.1.1 to Wildfly 8.2.0 and page performance on loads and posts is very slow. I created a large JSF 2 test page and took timings for JBoss 7.1.1, Wildfly 8.2.0 and Tomcat 7.x using the same Mojarra 2.2.8 implementation as Wildfly. > The attached war file contains mojarra 2.2.8 jars for tomcat. The attached ear file is for JBoss deployments and does not contain mojarra jars. > Example test URL for attached ear and war. > http://localhost:8080/testAppWeb/jsp/AjaxTest.jsf > JBoss 7.1.1 Timings > Page Load: 4.0 Seconds > Post: 4.5 Seconds > Ajax: 4.0 Seconds > Wildfly 8.2.0 Timings > Page Load: 66.0 Seconds > Post: 60 Seconds > Ajax: 55 Seconds > Tomcat 7.x with 2.2.8 Mojarra > Page Load 1.0 Seconds > Post: 0.75 Seconds > Ajax: 0.3 Seconds > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1160) Adding config files to AS7 is inconvenient.

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/WFLY-1160?page=com.atlassian.jira.plugin.... ] James Livingston commented on WFLY-1160: ---------------------------------------- To have "common libraries" directory would require deciding what modules were visible to it, since unlike earlier versions where there was a main classloader for the server, there is not any more. Regardless of the choice of dependencies, I suspect many people would want to be able to configure it. At that point, it doesn't seem to me that it would be any different from a normal module added to the EE subsystem global modules, apart from the "include all jars in the directory" part, which could be done if MODULES-99 was implemented. > Adding config files to AS7 is inconvenient. > ------------------------------------------- > > Key: WFLY-1160 > URL: https://issues.jboss.org/browse/WFLY-1160 > Project: WildFly > Issue Type: Feature Request > Components: Class Loading > Environment: All > Reporter: Paul Hinds > Assignee: David Lloyd > Priority: Minor > Labels: regression > > This page https://community.jboss.org/wiki/HowToPutAnExternalFileInTheClasspath details how to put a directory on the AS7 classpath which is inconvenient and could easily be done by default. > If AS7 out of the box came with /standalone/classes or /standalone/conf (conf would introduce a bit of backwards compatability) and perhaps /standalone/lib/*.jar added to the classpath it would be as good as previous JBoss versions. > This could be implemented as a module as in the above documents and automatically added to classpaths if the dirs exists in the same way other modules are automatically added to the CP if certain criteria are met. > Ideally is should be possible to make these symlinks on win7 and nix. Since it is natural to put config in /etc per Linux file system standards. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4210) Very Slow performance for larger JSF 2 pages.

by Rodney Kite (JIRA)

[ https://issues.jboss.org/browse/WFLY-4210?page=com.atlassian.jira.plugin.... ] Rodney Kite updated WFLY-4210: ------------------------------ Description: Very slow page performance using JSF 2 and Wildfly 8.2.0 for larger pages. I am migrating a large application from JBoss AS 7.1.1 to Wildfly 8.2.0 and page performance on loads and posts is very slow. I created a large JSF 2 test page and took timings for JBoss 7.1.1, Wildfly 8.2.0 and Tomcat 7.x using the same Mojarra 2.2.8 implementation as Wildfly. The attached war file contains mojarra 2.2.8 jars for tomcat. The attached ear file is for JBoss deployments and does not contain mojarra jars. Example test URL for attached ear and war. http://localhost:8080/testAppWeb/jsp/AjaxTest.jsf JBoss 7.1.1 Timings Page Load: 4.0 Seconds Post: 4.5 Seconds Ajax: 4.0 Seconds Wildfly 8.2.0 Timings Page Load: 66.0 Seconds Post: 60 Seconds Ajax: 55 Seconds Tomcat 7.x with 2.2.8 Mojarra Page Load 1.0 Seconds Post: 0.75 Seconds Ajax: 0.3 Seconds was: Very slow page performance using JSF 2 and Wildfly 8.2.0 for larger pages. I am migrating a large application from JBoss AS 7.1.1 to Wildfly 8.2.0 and page performance on loads and posts is very slow. I created a large JSF 2 test page and took timings for JBoss 7.1.1, Wildfly 8.2.0 and Tomcat 7.x using the same Mojarra 2.2.8 implementation jars. The attached war file contains mojarra 2.2.8 jars for tomcat. The attached ear file is for JBoss deployments and does not contain mojarra jars. Test URL for attached ear and war. http://localhost:8080/testAppWeb/jsp/AjaxTest.jsf JBoss 7.1.1 Timings Page Load: 4.0 Seconds Post: 4.5 Seconds Ajax: 4.0 Seconds Wildfly 8.2.0 Timings Page Load: 66.0 Seconds Post: 60 Seconds Ajax: 55 Seconds Tomcat 7.x with 2.2.8 Mojarra Page Load 1.0 Seconds Post: 0.75 Seconds Ajax: 0.3 Seconds > Very Slow performance for larger JSF 2 pages. > --------------------------------------------- > > Key: WFLY-4210 > URL: https://issues.jboss.org/browse/WFLY-4210 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web) > Affects Versions: 8.2.0.Final > Environment: Windows 7 64 bit, Oracle JDK 1.7.0-67 64 bit, Wildfly 8.2.0, Tomcat and JBoss 7.1.1. > Reporter: Rodney Kite > Assignee: Remy Maucherat > Fix For: JBoss AS7 7.1.1.Final > > Attachments: AjaxTest.xhtml, PageAjaxTest.java, testAppWar.ear, testAppWeb.war > > > Very slow page performance using JSF 2 and Wildfly 8.2.0 for larger pages. I am migrating a large application from JBoss AS 7.1.1 to Wildfly 8.2.0 and page performance on loads and posts is very slow. I created a large JSF 2 test page and took timings for JBoss 7.1.1, Wildfly 8.2.0 and Tomcat 7.x using the same Mojarra 2.2.8 implementation as Wildfly. > The attached war file contains mojarra 2.2.8 jars for tomcat. The attached ear file is for JBoss deployments and does not contain mojarra jars. > Example test URL for attached ear and war. > http://localhost:8080/testAppWeb/jsp/AjaxTest.jsf > JBoss 7.1.1 Timings > Page Load: 4.0 Seconds > Post: 4.5 Seconds > Ajax: 4.0 Seconds > Wildfly 8.2.0 Timings > Page Load: 66.0 Seconds > Post: 60 Seconds > Ajax: 55 Seconds > Tomcat 7.x with 2.2.8 Mojarra > Page Load 1.0 Seconds > Post: 0.75 Seconds > Ajax: 0.3 Seconds > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2014