[jboss-jira] [JBoss JIRA] Resolved: (JBAS-6310) Failure in loading classes due to thread stack overflow should be logged as an error.

[Dennis Reed (JIRA)]

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

Dennis Reed resolved JBAS-6310.
-------------------------------

    Resolution: Done
      Assignee: Dennis Reed  (was: Scott M Stark)


> Failure in loading classes due to thread stack overflow should be logged as an error.
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-6310
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6310
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: JBossAS-4.2.3.GA, JBossAS-5.0.1.GA, JBossAS-5.1.0.CR1
>            Reporter: Jay Howell
>            Assignee: Dennis Reed
>             Fix For: JBossAS-5.1.0.GA
>
>
> in org.jboss.mx.loading.LoadMgr3, there is an error message that is a trace statement and probably should be an error statement.
> catch(Throwable e)
>       {
>          boolean retry = e instanceof ClassCircularityError
>             || e.getClass().equals(LinkageError.class);
>          int numCCE = loadTask.incNumCCE();
>          if( retry && numCCE <= 10 )
>          {
>             /* Reschedule this task after all existing tasks to allow the
>             current load tasks which are conflicting to complete.
>             */
>             try
>             {
>                if( trace )
>                   log.trace("Run failed with exception", e);
>                // Reschedule and update the loadTask.threadTaskCount
>                scheduleTask(loadTask, ucl3, Integer.MAX_VALUE, true, trace);
>             }
> The problem that we ran into is that we have a customer that is using an IBM application.  It seems that this IBM application has lots of logic in static initializers and it causes the Stack to blow up at 128 k.  The task is retried and eventually succeeds, but this causes a race condition where things are not loaded when they should be and they get class not found exceptions.
> This was not easy to find, but the customer enabled trace and saw the message where the stack overflowed.    The fix is to increase thread stack, but it was difficult to find since it was a trace statement and not an error.  I would suggest the following fix...
>               if( trace )
>                   log.error("Retrying a failed loader task that failed with exception", e);
>                // Reschedule and update the loadTask.threadTaskCount
> The trace statement was 
> 2008-12-04 13:29:12,404 TRACE [org.jboss.mx.loading.LoadMgr3] Run failed with exception
> java.lang.StackOverflowError
>        at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
>        at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228)
>        at java.io.File.exists(File.java:702)
>        at sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:893)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira