Listeners' requestDestoyed() method not called in exception cases

[Pilkington, Simon]

We recently ran into an issue where the requestDestroyed() method of listeners 
were not being called when exceptions were propagated out of our application.

Looking into the code, it seems related to this[1]. Is this the expected 
behavior for listeners and we can’t rely on the requestDestroyed() method 
always being called for a request? 

One option we have considered is migrating to exclusively using filters and 
handling the exceptional use case explicitly there. Is there a recommended 
approach for this use case?

-Simon



[1] 
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat.embed/tomcat-embed-core/7.0.59/org/apache/catalina/core/ApplicationDispatcher.java#486

Re: Listeners' requestDestoyed() method not called in exception cases

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Simon,

On 5/15/15 2:26 PM, Pilkington, Simon wrote:
 We recently ran into an issue where the requestDestroyed() method
 of listeners were not being called when exceptions were propagated
 out of our application.
 
 Looking into the code, it seems related to this[1]. Is this the 
 expected behavior for listeners and we can’t rely on the 
 requestDestroyed() method always being called for a request?

Hmm. Looking at the spec, I don't see any requirement that the
container *must* invoke those event listeners, so I think Tomcat is
in-spec, here.

That being said, I think a reasonable person would expect that the
listener would fire even in the case of an exception condition.

This is something I might want to file with the Servlet EG. At the
very least, they might be able to make a statement about the intent of
the EG, and provide a clarification with the next release of the
Specification. Would you be willing to do that? The Servlet EG's JIRA
instance is dog-slow, but usable.

 One option we have considered is migrating to exclusively using 
 filters and handling the exceptional use case explicitly there. Is 
 there a recommended approach for this use case?

That all depends upon your use case. The Filter interface certainly
allows you to use your own try/catch blocks to make sure you intercept
exceptions that propagate up the stack.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVVjxiAAoJEBzwKT+lPKRYVpIQAJUg37n/jybTxhhKYK/j53dL
nKDK4C/PJDlwewvmeljtSHD9ghqGXR1WMgnfkXDcECVARJqgoEhOhTT+aY8W7b0M
/BDvB48LiCYkaE6/z6gEqDkrz+JWo2y1p2m/3XgwOaYdhvqzlC0Le88tB+scmDdo
LgaJFTrgVyTDdH1cZs3d0TAFCy+5kQR7Zt8UxxRL7xaxohwj5NB8KMVD4TZZysY8
Q3PBAsjI43bJYgLlVFX9lp3aDWKd4Ug549z2BMrFDeRivP6tkwNaCRICuluHClrx
opEpQj7kvpQOUivQfmYxRTHqavoj0rgaOtocvtN/+4TRboTff6fpxSTZJtSVc/gc
OIRGe7t6wr7jqLXvTw7eAV49zMsA23GwSUb1fa62kaLdmW2ohxLGpQud45yUgYSr
gM01UP6gIWuckO1mMAT8kEsujUGC3eCxAUJCV9F8ZNnw4zT5SS2DIPbzvj6I5qIR
q7GGmskfeijKDOHyt111McQbQFYl9liMiKBOORd1wDk9lGP/QzPqpGSvZhwDA0wa
NlBABocrAgsWPjk81jjvaDdpVMVsv3269FTiQhh4D06372tai6E0/cV+uKHrPGOU
BV4R6gS9FuQTc7VRiSmenusvuw5ILD1/YhnU3eU/0V+ovq5Nn0PLTq0Xr1lPnrnZ
3oLXMtc/GwZ0PNOXDDVB
=fFyO
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org