[ 
http://jira.dspace.org/jira/browse/DS-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11690#action_11690
 ] 

Sands Fish commented on DS-605:
-------------------------------

All, I have determined the source of this, what we've been calling the "White 
Screen Of Death (WSOD)" issue.  We have been seeing this at least 3 times a 
day, have been running a script to detect it and automatically restart Tomcat, 
and it has been the source of some grief for us.

I was able to reproduce it by stressing one of our test servers with a 
malformed packager URL.  (I'm not clear on whether stressing a URL that throws 
an exception is a contributor to the cause, or if any heavy concurrent access 
to DSpace URLs would cause it.)  Once I had the condition reproducible, I was 
able to put a debugger on the instance and dig deeper.  

The cause, as it turns out, is an issue we already knew about.  The Cocoon NPE 
Error:  [ 
http://jira.dspace.org/jira/browse/DS-253?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel
 ]

This was just another manifestation of this same issue, but the root cause was 
masked because of poor (non-existant) logging in the DSpaceCocoonServletFilter 
class.  The code that handles exceptions during invocation of the doFilter 
method of this class was swallowing any exceptions and not reporting anything...

                // Send the real request or the resumed request off to
                // cocoon....
        
                // if force ssl is on and the user has authenticated and the 
request is not secure redirect to https
                if 
((ConfigurationManager.getBooleanProperty("xmlui.force.ssl")) && 
(realRequest.getSession().getAttribute("dspace.current.user.id")!=null) && 
(!realRequest.isSecure())) {
                        StringBuffer location = new StringBuffer("https://";);
                        
location.append(ConfigurationManager.getProperty("dspace.hostname")).append(realRequest.getContextPath()).append(realRequest.getServletPath()).append(
                                realRequest.getQueryString() == null ? ""
                                        : ("?" + realRequest.getQueryString()));
                        realResponse.sendRedirect(location.toString());
                }
        
                arg2.doFilter(realRequest, realResponse);
                } catch (Throwable t) {
                    ContextUtil.abortContext(realRequest);                      
                //  <-- here's where we lost the evidence
                } finally {
                    // Close out the DSpace context no matter what.
                    ContextUtil.completeContext(realRequest);
                }

Once in the debugger, I could halt execution and dig out the stack trace, which 
is exactly the same one listed in the Cocoon issue.  

I will note that any critical Cocoon exception would be lost to us at this 
point, but due to the fact that the webapp has to be restarted to recover once 
this state is reached, I feel fairly certain that this is the issue that has 
been causing persistent WSOD issues in 1.6.  

After reproducing this issue multiple times with the same method on our test 
system, I am currently stressing the same server with the modified Cocoon 
dependency referenced in the Cocoon ticket and have not yet seen the condition 
recur.  (crossing my fingers)

I'm also developing a patched DSpaceCocoonServletFilter that will better report 
and handle error conditions.  I identified a number of other bugs during my 
research of this issue and will be submitting them as separate issues.

Let me know if there are any questions.

> Blank screen on XMLUI Dspace 1.6.0
> ----------------------------------
>
>                 Key: DS-605
>                 URL: http://jira.dspace.org/jira/browse/DS-605
>             Project: DSpace 1.x
>          Issue Type: Bug
>          Components: XMLUI
>    Affects Versions: 1.6.0
>         Environment: apache-tomcat-6.0.18
> jdk1.6.0_13
> Debian GNU Linux 5.0
>            Reporter: Antero Neto
>            Priority: Critical
>             Fix For: 1.7.0
>
>
> The interface of Dspce XMLUI shows a blank screen and I need to reboot Tomcat.
> JSPUI The interface is not affected by the issue. It happens sporadically. 
> I'm using version 1.6.0 of DSpace. I use a theme based on the theme 
> "Reference" which comes in DSpace.
> Below, some log information that may be related.
> 2010-06-09 00:07:00,741 ERROR cocoon.handled  - Could not read resource 
> cocoon://DRI/2/handle/xxxx/xxx/workflow
>         at <map:serialize type="xml"> - 
> resource://aspects/Statistics/sitemap.xmap:70:31
>         at <map:transform type="Navigation"> - 
> resource://aspects/Statistics/sitemap.xmap:38:55
>         at <map:generate> - resource://aspects/Statistics/sitemap.xmap:33:19
> ...
> org.apache.cocoon.ProcessingException: Could not read resource 
> cocoon://DRI/2/handle/xxxx/xxx/workflow
>         at <map:serialize type="xml"> - 
> resource://aspects/Statistics/sitemap.xmap:70:31
>         at <map:transform type="Navigation"> - 
> resource://aspects/Statistics/sitemap.xmap:38:55
>         at <map:generate> - resource://aspects/Statistics/sitemap.xmap:33:19
> ...
> Caused by: java.lang.NullPointerException
>         at 
> org.apache.cocoon.components.source.impl.SitemapSource.init(SitemapSource.java:292)
>         at 
> org.apache.cocoon.components.source.impl.SitemapSource.<init>(SitemapSource.java:148)
>         at 
> org.apache.cocoon.components.source.impl.SitemapSourceFactory.getSource(SitemapSourceFactory.java:62)
>         at 
> org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(CocoonSourceResolver.java:153)
>         at 
> org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(CocoonSourceResolver.java:183)
>         at 
> org.apache.cocoon.generation.FileGenerator.setup(FileGenerator.java:99)
>         at 
> org.dspace.app.xmlui.cocoon.AspectGenerator.setup(AspectGenerator.java:112)
>         at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source)
>         at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)

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

        

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to