Hi, I find some time to try to understand why sometimes my tomcat burns the CPU The fact: with long request (for example complex jsp or big dir listing) and if there is more than 1 simultaneous connection (is easy to reproduce the case with many connections); catalina stop responding, java takes all the CPU! I have tested that with default conf (perhaps there are some parameters to tune), I have create many files in a directory and many threads trying to get the directory listing. Tomcat version from 5.5.0 to 5.5.11 included are vulnerable, 5.5.12 seems to be ok. I have not tested older version. Have I missed something in the conf ? cheers David Maciejak
v5.0.28 seems ok
This bug report does not make any sense, sorry.
It does make sense and I have reproduced it.
Cool. Do you have an explanation for: "Tomcat version from 5.5.0 to 5.5.11 included are vulnerable, 5.5.12 seems to be ok." ?
(In reply to comment #4) > Cool. Do you have an explanation for: "Tomcat version from 5.5.0 to 5.5.11 > included are vulnerable, 5.5.12 seems to be ok." ? Looks like his testing of 5.5.12 was bad. I can easily reproduce this using the latest source from SVN and the problem area has remained unchanged. I posted an explanation of what is going on to the dev list.
(In reply to comment #5) > Looks like his testing of 5.5.12 was bad. I can easily reproduce this using the > latest source from SVN and the problem area has remained unchanged. I posted an > explanation of what is going on to the dev list. The abstraction layer will make directory listings expensive (actually, directory listings in Java are going to be expensive regardless), so I don't see how this can be optimized. The fact remains however that this bug report is nonsense.
(In reply to comment #5) > (In reply to comment #4) > > Cool. Do you have an explanation for: "Tomcat version from 5.5.0 to 5.5.11 > > included are vulnerable, 5.5.12 seems to be ok." ? > > Looks like his testing of 5.5.12 was bad. I can easily reproduce this using the > latest source from SVN and the problem area has remained unchanged. I posted an > explanation of what is going on to the dev list. > In fact, I have not been able to reproduce the problem on 5.5.12. The java thread burns the cpu during some time and after waiting enough all goes to a 'normal' state.
This is now fixed. The obvious optimisation has been made in the code but this only has a marginal impact. Given the high cost of generating the listings in Java, this code cannot be optimised to the point where large directory listings will not place a disproportionate load on the server. Therefore, directory listing is now disabled by default and warnings have been added to both the documentation and the file where this is configured. These changes will be included in versions 5.5.13+, 5.0.31+ and 4.1.32+ Note that releases of the 4.1.x and 5.0.x branches are now infrequent and that none are planned at present.