On 10 December 2015 at 06:42, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > On Wednesday, December 9, 2015, sebb <seb...@gmail.com > <javascript:_e(%7B%7D,'cvml','seb...@gmail.com');>> wrote: > >> On 9 December 2015 at 22:17, Philippe Mouawad >> <philippe.moua...@gmail.com> wrote: >> > Hello, >> > We have a quite rich version now I think (more than 50 >> bugs/enhancements+ 2 >> > major features) , what about releasing a new version ? >> >> Potentially, but there is still a lot to do to tidy up the recent >> additions. >> >> * tabs/indentation issues, which don't affect behaviour, but are >> tedious to fix, and cause maintenance issues >> * implicit boxing/unboxing - I'm sure there are some NPEs lurking >> here, not just the one I already reported > > I will have a look > >> >> Plus: >> * were the HC4 issues sorted? Is the code using the current HC release? > > I sent a detailed mail on this. > There are existing failing tests with2.13 and hc4.2.3 > When you upgrade to 4.5.1 2 additional failures appear even after migrating > CookieHandler. > I suspect hc4.5 bug plus but we will also have to abandon existing cookie > policies which are nearly all deprected. > > Oleg wants a pure hc Unit test to investigate issues. > > * there's the code I worked on earlier to support SampleTimeouts. I >> think that's ready to be merged, but it has been waiting a while so it >> may require some work. > > It is ok for me to merge it, but as I said we should avoid creating 1 > additional thread per thread for this feature. It would be better to
As I already explained, it does not create an extra thread per thread in normal running. There is one shared extra thread to handle the timeouts. And there is an option to use CALL instead of a new Runnable when the timeout occurs. With the Runnable option, extra threads are only created when a timeout occurs, and of course only last for as long as necessary to interrupt the sampler. Even with lots of hung threads, it's very unlikely that they will all timeout at the exactly the same time. > register a timeouter using something like hashweeltimer and a timeout > manager. No idea what a hashweeltimer is, but I think this is effectively what it does. > The current implementation reduces JMeter scalability per machine. It shouldn't make a material difference. Though of course any additional code that is loaded will use memory and may have some effect. > But as it is not mandatory to use it is ok for me. OK, I will have a look at merging it. >> >> > Regards >> > Philippe M. >> > >> > >> > >> > -- >> > Cordialement. >> > Philippe Mouawad. >> > > > -- > Cordialement. > Philippe Mouawad.
