https://bz.apache.org/bugzilla/show_bug.cgi?id=62626
--- Comment #7 from jan.pfei...@centrum.cz --- (In reply to Christopher Schultz from comment #6) > That's kind of par for the course, isn't it? Any IO operation can fail for > any reason. If you don't catch it and handle it, Tomcat will (eventually) > log it. What else did you expect to happen? I was only surprised by number of different IO exceptions. For some (Stream is not writable) it is not very clear what do they mean. > A "client abort" exception happens when the client makes a request and then > hangs-up the phone before you complete the response. It's fairly common and > I wouldn't really expect tcnative to crash under that circumstance, but it's > certainly possible. > > In general, ClientAbortExceptions can safely be completely ignored, so don't > worry too much about the fact that they are happening. On a busy site with > large responses (e.g. images) I'd expect lots of them. I undestand that. As I stated above it was only mix of different IOException types and quantity what confused me. > Can you try one more thing for me? Downgrade to Java 1.8.0_whatever and > revert your configuration to use APR+tcnative again and let us know if the > crashes (actual segfaults that kill the JVM) continue. I managed the downgrade. Alas lots of traffic ceased at the moment and server seems stable. I removed HTTP/2 upgrade as I understand it needs Java 9. Or am I wrong? > But let's take your ClientAbortException stuff onto the user list to see if > we can't find maybe some more efficient ways to get your images generated. > That synchronized block looks suspicious to me, and creating new threads all > the time is likely to lead to instability. In first version i wasnt using threads at all. It seemed unlikely to get several concurrent request for one image. If it would happened the later one could simply overwrite image or respond with error. But since the crashes started i suspected thread concurency to be a problem. New threads are only spawned when images is requested for the first time. Images is downloaded from different machine, resized and webp version is created. WebP is now created with an external program. I was using native lib and imageio before. I use threads and ConcurentHashMap<String, Thread> only to ensure that incoming requests will wait until image processing is finished. This only applies for requests for the same image. Others are free to get cached image or to start new resizing thread. Other option would be to allow only one image process at time, but it would have negative performance impact i guess. Another strange thing i got into was out of memory error (4GB) yesterday evening. No obvious reason of the problem. I have deleted image cache, so they are recreated now. Everything runs well. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
