You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Apache Wiki <wi...@apache.org> on 2017/10/02 14:31:47 UTC

[Tomcat Wiki] Update of "FAQ/KnownIssues" by KonstantinKolinko

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.

The "FAQ/KnownIssues" page has been changed by KonstantinKolinko:
https://wiki.apache.org/tomcat/FAQ/KnownIssues?action=diff&rev1=14&rev2=15

Comment:
Minor formatting corrections. Split paragraphs.

  
  '''Are there any other corresponding cases of this bug?'''
  
- The third party PDF generating software module PD4ML has had a corresponding problem when calling the render() methods in class org.zefer.pd4ml.PD4ML with response.getOutputStream() as argument. That causes the response stream to be closed from a finalizer() method of a class called PD4Device. When using an Apache/Tomcat connector, this unexpected stream close from the finalizer thread has occationally caused responses to be sent to wrong requestor (request/response mix up). The workarounds described above for ImageIO works perfectly in this case too. A general way to protect the response output streams from misbehaving web applications is to set the system property org.apache.catalina.connector.RECYCLE_FACADES=true, since that makes Tomcat create new stream instances for each request (of course at the cost of performance).
+ The third party PDF generating software module PD4ML has had a corresponding problem when calling the render() methods in class org.zefer.pd4ml.PD4ML with response.getOutputStream() as argument. That causes the response stream to be closed from a finalizer() method of a class called PD4Device. When using an Apache/Tomcat connector, this unexpected stream close from the finalizer thread has occationally caused responses to be sent to wrong requestor (request/response mix up). The workarounds described above for ImageIO works perfectly in this case too.
- <<BR>>
- <<BR>>
- PD4ML has fixed this bug in their latest releases, but sites using older versions of the library can still be affected. PD4ML version 3.2.3 definitely has this flaw, but the currently latest version 3.8.0 is fixed. The release notes gives no clues where in between the problem was fixed and the vendor was not able to tell either in [[http://pd4ml.com/support/pdf-generation-troubleshooting-f4/pd4device-finalize-closes-output-stream-and-causes-mixup-t543.html|this bug report]].
  
+ A general way to protect the response output streams from misbehaving web applications is to set the system property org.apache.catalina.connector.RECYCLE_FACADES=true, since that makes Tomcat create new stream instances for each request (of course at the cost of performance).
+ 
+ PD4ML has fixed this bug in their latest releases, but sites using older versions of the library can still be affected. PD4ML version 3.2.3 definitely has this flaw, but the currently latest version 3.8.0 is fixed. The release notes document gives no clues where in between the problem was fixed, and the vendor was not able to tell either in [[http://pd4ml.com/support/pdf-generation-troubleshooting-f4/pd4device-finalize-closes-output-stream-and-causes-mixup-t543.html|this bug report]].
+ 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org