-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Leigh,
On 4/30/14, 10:31 AM, Hayward, Leigh wrote: > My Java EE web application takes in multiple audio inputs and > outputs them as a single wav file via an application/octet stream. Like a mixer? > It seemingly randomly works correctly (i.e. outputting the > correctly manipulated audio file) but sometimes, the file from a > previous run of the program is output and I get one of these > errors: > > SEVERE [http-nio-8084-exec-30] > org.apache.catalina.loader.WebappClassLoader.clearReferencesThreads > The web application [/MyApp] is still processing a request that has > yet to finish. This is very likely to create a memory leak. You can > control the time allowed for requests to finish by using the > unloadDelay attribute of the standard Context implementation. > > and to me seemingly random numbers of these errors: > > "SEVERE [http-nio-8084-exec-87] > org.apache.coyote.http11.AbstractHttp11Processor.process Error > processing request java.lang.IllegalStateException: The resources > may not be accessed if they are not currently started?" These kinds of things are almost always due to storing of a request or response option in some kind of structure that survives past the end of a particular request. Can you explain how you build the response -- specifically involving any non-standard threading you may do? > The files always upload correctly to my filesystem, but something > is going wrong when I try to access them in order to process them. What mechanism do you use for upload? > Also when it is downloading the file it appears to the user to be > several MB long despite the file that is output being only a few > thousand KB. NB a few thousand KiB is the definition of several MiB. Is the response built before you stream any of it to the client? Are you setting a Content-Length before you send any data? Are you using chunked responses? > Sometimes when it doesn't work it does not produce these errors, > but it never produces these errors when it works correctly. Does (increased) load seem to make the situation worse? > I have googled it but there's no reference to the second kind of > error anywhere on the web aside from svn commits by tomcat > developers, so while I am a total newbie to mailing lists, after > exhausting stackoverflow this seemed like the only place to turn > to. I'm developing a java EE web application in Netbeans using > Tomcat 8.0.3.0 on a windows 7 operating system. (You should upgrade to a later Tomcat 8 beta. Nothing should affect what you are seeing here, but it's not a bad idea to get the latest.) > The web application is very basic and allows users to upload files > via a multipart html form. This then posts to a servlet which first > uploads these files to the programs file system and then accesses > them, concatenates them together and saves them back on the file > system. It's better explained by this diagram > http://imgur.com/Oacd4gq The real question is whether you are using non-request-processor threads to do any of this work. Also, where are the various data stored while you are working on them? Not the filesystem -- that seems self-evident -- but where in the program are the String[] objects that represent all the songs that have been uploaded? When you process a "transaction" (upload -> merge -> respond), are you taking care to ensure that the files are placed into different paths for each request? How are you choosing the filename of the merged audio clip? > Could it be that the files are not being uploaded fully before they > are being accessed? I don't believe this is possible when using Tomcat's file-upload implementation. It is certainly possible to do if you are performing the multipart handling yourself. What tool are you using to fetch the multipart data from the request? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTYSujAAoJEBzwKT+lPKRYBaoQALMHlZ44XuEeH0cmGGofOcTE Hc0+T101jNxEpyUTd0dvO2u03n1Fp/a+R3vglq+gp0KwmkFZOHpdhBi0XuMbdBwx btm1zy3c5Lico6BKh0qGWRNSqxL6RwutsLrNmi2z0N9uwHJENPl5tpPYZQXsyYEu IBPaqRCdAJ+aJVe6zyhyOshF1cKP3/Hd8HD3OXARUVAuOaoEiGlHoq/GFx5e/I1b JprF7hZumvc3QSwXH13dseTszVpWwljx1a+2/cPk3tyU+09soFAA2ee6sGF4NBr9 c6uB1S/dYIXGcQrJcj7ICSQNM7QKNxXUbdxBIvd7Yh51ATNcTTZxshNkyYcx1IYw SqoojnVMd6ivXNoW2Lx8pTCSAFId0BIFh5oJdPAUf5kV1fkGQXzrUVlz/OfVhPd/ mZXlYiuczDPz2mI9zxxzY0RTU/pB3ckXYQ7ByQE4m8+YPXo5adw+ZHmH0QeFMVlE khWVte3MKUIWMBPdnYKQXQp+f+Uph6yl2XHyRAZ1l/KrrTTzcuqAzsOIaW5/x85u a3YMDJdcHHZ+k4Uvn6w6tjZxD8TXBNXcvB0ue5rTPeOiqAeSHojwLupDFG+2XyHh SAc4J0FMmDwu9AZKH2mjfYuaFIpy2ncHB7FwCuYz2dBxiTfnLyOBJcSNgSj7f18a rAlcVsS/LEcFyS0wgGrt =YahV -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
