Prettyfaces causes wep app to hang

Splash Forums PrettyFaces Users Prettyfaces causes wep app to hang

This topic contains 21 replies, has 6 voices, and was last updated by  Christian Kaltepoth 2 years, 2 months ago.

Viewing 15 posts - 1 through 15 (of 22 total)
  • Author
    Posts
  • #18005

    zee
    Participant

    I’m using Prettyfaces 3.3, with Richfaces 4, and Seam 3 on jboss AS 7.

    I only use one simple rule for prettyfaces to see how it works. Whenever prettyFaces jar is included in my app, the home.xhtml pages takes over 20s to load in a browser (both firefox and chrome). If I remove prettyFaces jar everything loads in under a second.

    I enabled debug level in jboss, I see many messages from com.ocpsoft.shade.org.apache.commons.digester package, hundred of thousands of lines about trying to parse rules from under faces-config.

    I use @ViewConfig for Seam security, but no urlRewrite beside below simple rule. For all of my navigation I use faces-config.xml navigation rules.

    Also, during start up Prettyfaces take few seconds to start as you can see bootstrap log:

    14:37:51,608 INFO [com.ocpsoft.pretty.PrettyFilter] (MSC service thread 1-7) PrettyFilter starting up…

    14:38:02,408 INFO [com.ocpsoft.pretty.PrettyFilter] (MSC service thread 1-7) PrettyFilter initialized.

    pretty-config.xml

    <?xml version="1.0" encoding="UTF-8"?>
    <pretty-config xmlns="http://ocpsoft.com/prettyfaces/3.3.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://ocpsoft.com/prettyfaces/3.3.0 http://ocpsoft.com/xml/ns/prettyfaces/ocpsoft-pretty-faces-3.3.0.xsd">
    <url-mapping id="home">
    <pattern value="/" />
    <view-id value="/home.xhtml" />
    </url-mapping>

    </pretty-config>

    My dependencies from pom.xml:

    <dependency>
    <groupId>org.jboss.spec</groupId>
    <artifactId>jboss-javaee-6.0</artifactId>
    <version>1.0.0.Final</version>
    <type>pom</type>
    <scope>provided</scope>
    </dependency>
    <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>4.1.0.Final</version>
    <scope>provided</scope>
    <exclusions>
    <exclusion>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    </exclusion>
    </exclusions>
    </dependency>
    <dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <scope>test</scope>
    <version>6.1.1</version>
    </dependency>

    <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-search</artifactId>
    <version>4.0.0-SNAPSHOT</version>
    <exclusions>
    <exclusion>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-core</artifactId>
    </exclusion>
    <exclusion>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    </exclusion>
    <exclusion>
    <groupId>org.apache.solr</groupId>
    <artifactId>solr-analysis-extras</artifactId>
    </exclusion>
    <exclusion>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-commons-annotations</artifactId>
    </exclusion>
    </exclusions>
    </dependency>
    <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-core</artifactId>
    <version>4.0.0.Beta1</version>
    <scope>provided</scope>
    </dependency>
    <dependency>
    <groupId>joda-time</groupId>
    <artifactId>joda-time</artifactId>
    <version>1.6.2</version>
    </dependency>
    <dependency>
    <groupId>org.jadira.usertype</groupId>
    <artifactId>usertype.jodatime</artifactId>
    <version>2.0</version>
    </dependency>
    <dependency>
    <groupId>commons-codec</groupId>
    <artifactId>commons-codec</artifactId>
    <version>1.4</version>
    <scope>provided</scope>
    </dependency>

    <!-- seam dependencies go below -->
    <dependency>
    <groupId>org.jboss.seam.security</groupId>
    <artifactId>seam-security</artifactId>
    <version>${seam-version}</version>
    </dependency>
    <dependency>
    <groupId>org.jboss.seam.catch</groupId>
    <artifactId>seam-catch</artifactId>
    <version>${seam-version}</version>
    </dependency>
    <dependency>
    <groupId>org.jboss.seam.solder</groupId>
    <artifactId>seam-solder</artifactId>
    <version>${seam-version}</version>
    </dependency>
    <dependency>
    <groupId>org.jboss.seam.persistence</groupId>
    <artifactId>seam-persistence</artifactId>
    <version>3.0.1-SNAPSHOT</version>
    </dependency>
    <dependency>
    <groupId>org.jboss.seam.international</groupId>
    <artifactId>seam-international</artifactId>
    <version>${seam-version}</version>
    </dependency>
    <dependency>
    <groupId>org.jboss.seam.servlet</groupId>
    <artifactId>seam-servlet</artifactId>
    <version>${seam-version}</version>
    </dependency>
    <dependency>
    <groupId>com.ocpsoft</groupId>
    <artifactId>prettyfaces-jsf2</artifactId>
    <version>3.3.0</version>
    <scope>runtime</scope>
    </dependency>
    <!-- Seam cron and async dependencies -->
    <dependency>
    <groupId>org.jboss.seam.cron</groupId>
    <artifactId>seam-cron-api</artifactId>
    <version>3.0.0.Alpha1</version>
    <scope>compile</scope>
    </dependency>
    <dependency>
    <groupId>org.jboss.seam.cron</groupId>
    <artifactId>seam-cron-scheduling-quartz</artifactId>
    <version>3.0.0.Alpha1</version>
    <scope>runtime</scope>
    </dependency>
    <dependency>
    <groupId>org.jboss.seam.cron</groupId>
    <artifactId>seam-cron-asynchronous-quartz</artifactId>
    <version>3.0.0.Alpha1</version>
    <scope>runtime</scope>
    </dependency>
    <dependency>
    <groupId>org.jboss.seam.faces</groupId>
    <artifactId>seam-faces</artifactId>
    <version>3.0.2.Final</version>
    </dependency>
    <dependency>
    <groupId>org.richfaces.ui</groupId>
    <artifactId>richfaces-components-ui</artifactId>
    </dependency>
    <dependency>
    <groupId>org.richfaces.core</groupId>
    <artifactId>richfaces-core-impl</artifactId>
    </dependency>

    #21221

    That’s a very strange performance issue. Do you happen to be running in javax.faces.PROJECT_STAGE = Development?

    If so, how does it behave in “Production” ?

    #21222

    zee
    Participant

    Yes, I use javax.faces.PROJECT_STAGE = Development. Changing it to Production does not make any difference.

    The only way I can get the page to load normally is to either exclude prettyFace jar or set log levels to WARN in jboss.

    The log files gets huge so I cannot post parts of them here, but there seems to be a bug in Pretty faces, it keeps trying to validate against rules (it says rules are under faces-config) and no rules were found.

    If you want to reproduce this, you can simply use DEBUG or INFO modes for jboss root and file loggers. Make a simple a war that uses prettyConfig jar with one xhtml page. You should see how prettyFaces keeps validating against rules and processes rules XML elements multiple times.

    #21223

    Hey zee,

    thanks for bringing this issue up. We’ll definitively try to reproduce this as this would be a major issue of PrettyFaces. But I’ve already run PrettyFaces applications on AS7, so I’m a bit surprised about the behavior you are describing.

    I’ll give some feedback as soon as I find some time to dig into this issue.

    Thanks

    Christian

    #21224

    zee
    Participant

    Hi Christian,

    Just to be sure to have the issue reproduced be sure to set the debug level of root and file loggers in jboss AS7 to DEBUG. Of course having a simple WAR would help, for example just a home.xhtml, a facesConfig Enum (from Seam), and a simple prettyConfig rule as the one I posted.

    This is pretty serious, I excluded prettyFaces from my project until there is a fix for this.

    Thanks! Zee.

    #21225

    Sure! I’ll come back to you as soon as I know more about this issue…

    #21226

    zee
    Participant

    Any updates guys? I cannot debug my app (using debug mode for jboss logs) when prettyfaces jar is in the war. Thanks!

    #21227

    Hey there! Sorry! Had had a few busy weeks so I didn’t find time to look into this up until now.

    I just tried to reproduce this with JBoss AS 7.0.0 but everything seems to work fine. The startup time looks good:

    13:10:55,454 INFO  [com.ocpsoft.pretty.PrettyFilter] (MSC service thread 1-4) PrettyFilter starting up...
    13:10:55,553 INFO [com.ocpsoft.pretty.PrettyFilter] (MSC service thread 1-4) PrettyFilter initialized.

    And accessing a page mapped via PrettyFaces loads very fast.

    I can confirm that PrettyFaces rebuild its configuration on every request (with a minimum time span between reload of 2 seconds) when in development mode. So don’t worry if you see many Digester log messages on DEBUG level. This is OK.

    The strange issue here is that something during the initialization procedure seems to be very slow in you app. I doubt that it is caused by the parsing. Parsing a few smaller XML files cannot take soooo long. In theory another suspect would be the annotation scanning. You could try to disable this an check if the situation gets better. Just add this to your web.xml:

    <context-param>
    <param-name>com.ocpsoft.pretty.BASE_PACKAGES</param-name>
    <param-value>none</param-value>
    </context-param>

    Could you perhaps also post your web.xml? Perhaps we find any clue here.

    Another option for you would be to do a few thread dumps during the 10 seconds that the PrettyFilter needs to start up. This way we could see what is happening during this time. You could either use jstack for this or perhaps JConsole.

    #21228

    zee
    Participant

    Christian, thanks for your help.

    I don’t know if I can get a thread dump, the app is unusable in debug mode or when prettyfaces is on the classpath.

    web.xml:

    <?xml version="1.0" encoding="UTF-8" standalone="no"?>
    <web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    version="3.0"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">

    <session-config>
    <session-timeout>30</session-timeout>
    </session-config>

    <listener>
    <listener-class>base.ServletLoaderListner</listener-class>
    </listener>

    <context-param>
    <param-name>javax.faces.PROJECT_STAGE</param-name>
    <param-value>Development</param-value>
    </context-param>

    <!-- File upload settings -->
    <context-param>
    <param-name>org.richfaces.fileUpload.createTempFiles</param-name>
    <param-value>false</param-value>
    </context-param>

    <context-param>
    <param-name>org.richfaces.fileUpload.maxRequestSizes</param-name>
    <param-value>2147483648</param-value>
    </context-param>

    <context-param>
    <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
    <param-value>.xhtml</param-value>
    </context-param>

    <servlet>
    <servlet-name>Faces Servlet</servlet-name>
    <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
    <servlet-name>Faces Servlet</servlet-name>
    <url-pattern>*.xhtml</url-pattern>
    </servlet-mapping>

    <welcome-file-list>
    <welcome-file>/index.html</welcome-file>
    </welcome-file-list>
    </web-app>

    #21229

    Hey Zee,

    thanks for sending your web.xml. It looks good. I see now reason why something could be problematic here.

    It would be great if you could try to create the thread dumps on your system. Unfortunately its impossible for me to help with this issue if I cannot reproduce it. :(

    Please let me know if you need any help in creating the thread dump. On with OS are you developing? How do you start AS7? From the console? From Eclipse?

    Thanks

    Christian

    #21230

    zee
    Participant

    Hey Christian, I use Ubuntu 10.10. I start AS7 from console using standalone.sh.

    Thread dump is tricky as the system is unstable/very slow in debug mode.

    I’ll try again and hopefully I’ll be able to get a thread dump.

    #21231

    With Linux you should be able to do:

    $ ps aux | grep jboss
    $ kill -3 $JAVA_PROCESS_ID

    This will create a thread dump and write it to stdout!

    #21232

    Any news on this one? It would be really helpful for us to see a thread dump when this happens. I tried to reproduce this but everything works fine.

    Could you have a look at this post and check if the solution this user writes about helps in your case:

    http://ocpsoft.com/support/topic/dont-forget-to-add-web-infpretty-configxml-and-a-question

    http://code.google.com/p/prettyfaces/issues/detail?id=124

    Christian

    #21233

    zee
    Participant

    No news, I do have a /pretty-config.xml. But I do see a warning about missing log4j property file for Prettyfaces. What log property file is needed to make this warning go away?

    Like I said it only hangs (it works very slowly due to large number of log messages) in DEBGU mode. You’re right, it’s all from digester library.

    #21234

    What do you mean with “in DEBUG mode”? What is run in DEBUG mode? Do you mean the JSF project stage?

    PrettyFaces uses Commons Logging for its logging. Commons Logging automatically detects logging libraries on the classpath (like Log4J) and delegates the log events to them.

    If you see a warning regarding a missing Log4J configuration then it seems like there is Log4J on the classpath and not completely configured. If you don’t use Log4J you should remove it from the classpath.

    However PrettyFaces and Commons Logging have no influence on how the underlying logging library is configured. If your logging library is configured to emit DEBUG messages for Digester, then it seems like your logging library is not configured correctly. What do you use for your logging?

    As far as I can tell you can configure the logging of AS7 in the standalone.xml configuration file. Could you post the relevant parts of this file? Everything inside:

    <subsystem xmlns="urn:jboss:domain:logging:1.1">
    ..
    </subsystem>

Viewing 15 posts - 1 through 15 (of 22 total)

You must be logged in to reply to this topic.

Comments are closed.