Share Log Settings - Error downloading (some) log files #99
Comments
|
The problem appears to be related to the Surf extension module processing on web scripts. Since the Repository-tier does not have this capability by default it might not be affected. Essentially, after the web script has already streamed the log file via the web script response output stream, the web script runtime container attempts to close the extensibility model. This entails getting a writer to the web script response, which fails because the output stream has already been accessed. |
|
What "gems" one can find in the Surf source code. There is actually a way to suppress processing of the extensibility model, but it is neither exposed in a way that would allow it to be used for custom web scripts nor is it thread-safe. It is currently used in the FreeMarker "ProcessJsonModelDirective" when building "constants" for a Surf page (building the aggregated Dojo & AIkau JS / CSS dependencies and messages bootstrap). The following implementation is called in the LocalWebScriptRuntimeContainer: boolean extensibilitySuppressed = false;
public void suppressExtensibility()
{
this.extensibilitySuppressed = true;
}
public void unsuppressExtensibility()
{
this.extensibilitySuppressed = false;
}
public boolean isExtensibilitySuppressed()
{
return this.extensibilitySuppressed;
}Should any web script request be processed while a page is being loaded in a different thread, this would prevent any extensions from working on that web script. The core problem is that the LocalWebScriptRuntimeContainer will always process the extensibility model and access the writer, even if no extension was actually applied to the current request. This in effect prevents any AbstractWebScript to work that uses the output stream on the web script response to stream a response. Interestingly, I already identified and solved a similar issue with my Acosix Utility module that adds an extensible web script container on the Repository-tier, so this problem does not occur there even though my Repository has extensibility enabled much like Share has by default. While we should file an issue with Alfresco for the conflict between extension module support and compatibility with generic AbstractWebScript implementations, a quick work-around would be possible by writing the response to the extensibility model instead of the web script response. The only problem is that this workaround only supports text-based content, and this issue could thus not be addressed for the ZIP-based download of multiple log files. |
|
Even better - there already are the classes ExtensibilityHttpResponse / ExtensibilityServletOutputStream that are designed to facade the actual response and output stream, and transparently support writing to the extensibility model. Unfortunately though, those are only used for processing JSP-based web scripts and rendering the template header of a Surf template instance. |
|
Reported as ALF-21949 |
|
It is yet unclear why downloading of log files works in 10-20 % of tests. Maybe the lack of thread-safety with extension handling has something to do with it. |
- refactor file + streaming handling into shared utilities - abstract differences between servlet / web script via facade interface - adjust Aikau service to handle additional URL type - update / correct some copyright notes - add explicit Surf dependency as transitive dependency was missing - move dependency management information into appropriate section
- refactor file + streaming handling into shared utilities - abstract differences between servlet / web script via facade interface - adjust Aikau service to handle additional URL type - update / correct some copyright notes - add explicit Surf dependency as transitive dependency was missing - move dependency management information into appropriate section
Expected behavior
When opening the "Share Log Files" / "Repository Log Files" dialogs, all log files can be individually downloaded.
Actual behavior
When opening the "Share Log files" dialog, only some of the log files could be downloaded, and in some cases only once. For most log files, no action was apparent to the end user. The log file of Share showed exceptions like:
Steps to reproduce the behavior
Additional details (analysis so far, log statements, references, etc.)
Tell us about your environment
Windows 10 64-bit, JDK 1.8.0_112, Alfresco Share 5.2.e, Alfresco Repository 5.2.f
The text was updated successfully, but these errors were encountered: