sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Sedding (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SLING-7813) SlingHttpServletResponseImpl should log when setStatus is called after it is committed
Date Wed, 08 Aug 2018 09:41:00 GMT

     [ https://issues.apache.org/jira/browse/SLING-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Julian Sedding updated SLING-7813:
----------------------------------
    Fix Version/s:     (was: Engine 2.6.12)
                   Engine 2.6.14

> SlingHttpServletResponseImpl should log when setStatus is called after it is committed
> --------------------------------------------------------------------------------------
>
>                 Key: SLING-7813
>                 URL: https://issues.apache.org/jira/browse/SLING-7813
>             Project: Sling
>          Issue Type: Improvement
>          Components: Engine
>    Affects Versions: Engine 2.6.12
>            Reporter: Julian Sedding
>            Assignee: Julian Sedding
>            Priority: Minor
>             Fix For: Engine 2.6.14
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I have been debugging a scenario, where a response did not have the (in this case) expected
status code {{500}} set by an error handling script, but instead the status code was {{200}}.
> It turns out that a rendering script calls {{#flushBuffer()}} on the response early on
in order to optimize user experience. Later in the rendering chain a JSP causes a {{NullPointerException}},
triggering an error handler which calls {{#setStatus(500)}}. The {{#setStatus}} call is silently
ignored.
> "Fixing" this problem would require buffering the entire response and ignoring any flush
calls (be it {{#flushBuffer()}}, {{#getWriter().flush()}} or {{#getOutputStream().flush()}}).
This would be a change in behaviour, a violation of the Servlet spec and performance issues
waiting to happen. Thus I am ruling out this option.
> However, it would be helpful to improve "debuggability" of the problem. I propose to
log a warning when {{#setStatus()}} is called. Additionally, if debug logging is enabled,
I propose to log a stack trace to identify where the flush call originated (unless the flush
was due to too many bytes written, which is not very helpful information).
> cc [~rombert]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message