On 26 February 2017 at 12:51, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > On Sun, Feb 26, 2017 at 1:44 PM, sebb <seb...@gmail.com> wrote: > >> On 26 February 2017 at 12:33, Philippe Mouawad >> <philippe.moua...@gmail.com> wrote: >> > On Sun, Feb 26, 2017 at 1:15 PM, sebb <seb...@gmail.com> wrote: >> > >> >> On 26 February 2017 at 09:52, Philippe Mouawad >> >> <philippe.moua...@gmail.com> wrote: >> >> > Hello, >> >> > This element might be more useful if we can make some enhancements to >> it: >> >> > >> >> > - First rename it as its name is far from clear. Something like >> Mail >> >> > Alerter >> >> > - Make it send notifications on richer conditions: >> >> > - Percentile 90 of response time (Excluding Transaction >> Controller) >> >> > reaching a limit >> >> > - Errors percentage reaching a limit >> >> > - Burst in error percentage >> >> > - ... >> >> > - Possibly be able to express a rule in Groovy >> >> > >> >> > Currently it seems to me far from useful as is. >> >> >> >> I suggest you ask on the User list how it is being used. >> >> >> >> Also, I would be wary of adding too much functionality into the >> listener. >> >> It should just be a means to send the email, the same as other >> >> Listeners are a means to displaying results or recording them in a >> >> file or database. >> >> Error checks should be done by Assertions. >> >> >> > In my understanding Assertion applies on every sample. Can it apply to a >> > history of samplers ? >> >> Listeners also apply to each sample, yet the Mailer Visualizer is able >> to look at history, so Assertions can use the same technique. >> >> > Maybe a simple addition would be to allow Mailer Visualizer to send a >> mail >> > based on variable or property value (true/ false). >> > This would make it very flexible. We could this way combine it with >> > GenerateSummary Result or a dedicated "Alert" listener which could set >> this >> > variable or property. >> >> That would be better, but the "Alert" test element should be an >> Assertion not a Listener. >> > Its usage would be confusing . > Assertion are here to mark a sampler in error, so you could randomly get > any sampler marked in error whenever the alert conditions are met.
Depends on how the Alert assertion records the outcome. It would not make sense to change the sample status. > A listener is more "global" as such it seems to me a better place for that. I don't see a Listener that way; it is a test element that processes samples, just as an Assertion processes samples. It is only global if it is in global scope. An assertion analyses sampler responses. A listener records or displays them. Therefore the Alert element should be an Assertion. > >> >> This would allow it to be more general; e.g. one could stop a test if >> the error percentage was too high. >> >> > >> >> As far as possible, each test element should have a single role. >> >> This reduces duplication and allows easier testing. >> >> >> > I agree >> > >> >> >> >> > >> >> > Regards >> >> > >> >> > Philippe >> >> >> > >> > >> > >> > -- >> > Cordialement. >> > Philippe Mouawad. >> > > > > -- > Cordialement. > Philippe Mouawad.
