Scott Eade <[EMAIL PROTECTED]> writes: >Henning P. Schmiedehausen wrote:
>>Hm. This was put in > two years ago. I do remember that I got this >>from load testing one of our applications and that was the >>solution. We were getting spurious ITEs without any real cause in the >>application but out of the invoke() code. It raised no comment on the >>-dev list back then (according to the archives). >> >> >I think this falls into the "the consequences of the change were not >particularly obvious at the time" bucket - after all, if your actions >don't throw any exceptions you may not have noticed it. For my part I >know that the pressure has been to correct the problem (the cause of the >exception being thrown) more than it has been on ensuring that the fact >that something has gone wrong is reported to the user. >>Should we address it in 2.3.2? That code is in there ever since 2.3RC1 >>and the whole 2.3 cycle. Changing it would be actually changing >>behaviour from previous 2.3 releases to 2.3.2. So I'd say cautiously >>"no, not in the default". We might add a property to control this, but >>this feels like a kludge. >> >> >I would say that by not fixing it we are not adhering to our own >specification - see: >http://jakarta.apache.org/turbine/turbine/development/turbine-2.3/fsd.html#Exception_Handling >>I will post the result of the vote today. I will hold the actual >>rolling of the release until tomorrow to see if anyone else pipes >>up. If you have a patch ready for review that would be even better. >> >> >I am curious to know more about your load testing. Could the "ITEs >without real cause" have actually had a cause? Was the testing such The problem were HTTP requests that were sent out by the browser/load testing tool (ab) but aborted before the application/container could actually send out a reply. I don't have the details really handy anymore but we basically used a really simple action class (which was guaranteed to not throw any exceptions) and still ended up with Exceptiones being thrown. These were "class not found" errors, which is pretty scary, considering the fact that the getMethod() call a few nanos earlier had succeeded. >that the behaviour of the processing was confirmed (not necessarily >something that would occur during load testing) - i.e. did it ignore the >fact that the Action code was encountering an exception that was being >swallowed with the processing left incomplete? Was the >Cause/TargetException of the ITEs examined - and if so was there an >underlying cause that could be swallowed rather than the ITE itself >(currently this is the equivalent of swallowing Exception rather than >the specific subclass). >The fact that any action that encounters an exception reports nothing to >the user at all, leaving them totally bewildered as to why they are >stuck on the same page is not good at all. I understand that. >A tested patch is included below. >+ throw (Exception) ite.getTargetException(); [...] >+ throw (Exception) ite.getTargetException(); And I firmly -1 it in that incarnation. Please read my comments to the commit message of r221603. If you simply cast a potential Throwable to Exception, then you are in for CCE's sooner or later and _that_ will leave users bewildered even more. If there really is a need for fixing this, let's fix it correctly. Besides from this, the patch is IMHO ok. Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
