Hi Chris,
Thank you so much for the speedy response .
I have no idea what i'm doing formatting wise. Pretty much
just wrapping and indenting all by hand so forgive me if
it's a mess!
>________________________________________
>From: Christopher Schultz <ch...@christopherschultz.net>
>Sent: 30 April 2014 17:58
>To: Tomcat Users List
>Subject: Re: Tomcat 8.0.3.0 getting never before seen by google Illegal State
>Exception. Sevlets outputting the >audio output from the previous runs of the
>program instead of the current run.
>-----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?
Like a concatenator, adds songs one after the other into one
long song. It then overlays (mixes) another file into it containing
audio cues on top of the concatenated music. But the issue is
definitely arising at the concatenation phase.
I have the audio writing to a file after each song is added in the
concatenation phase so that i can audibly debug and the
concatenator is definitely struggling to find the uploaded files.
>> 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 response is built in a method called finish which is called in
doPost like this :
finish(req, res);
In finish I make a printwriter
I set response content type to "application/octet-stream",
set the header "Content-Disposition" to
"attachment; filename=finished.wav"
I make a FileInputStream of the finished filepath
Then I set the header content length to the length of the finished file.
then I while loop the fileInputStream into the printwriter
Then I close the FIS.
I have not touched threading since it looks terrifying.
I did experiment with making the servlet singlethreaded
since I thought it could have something to do with threads
(bad practice I know) but that did nothing to help.
>> 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?
My servlet has a location set in the @multipartconfig tag
that is where all files are saved to and retrieved from.
I am getting the Parts from the request then iterating through them,
for each part that is a file upload I use
part.write("uploadedfile" + count + ".wav");
>> 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.
I am possibly just an idiot on that one.
I think the deadline sleep deprivation is getting to me
>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?
I call a finish(req, res) method in my doPost which is where all my
response building is done.
I am setting a content length before I send the data because I wanted
to be able to see how long it was going to take to download since the
program is fairly slow.
>> 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?
Definitely. Always happens with long audio files and only sometimes
with shorter test ones.
>> 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.)
I'm just a little nervous about moving or touching anything since i'm
not 100% confident it wont just break everything. Still new at this.
I wanted the most stable version, to balance out my intellectual
instability.
>> 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?
C:\Users\Leigh\Documents\NetBeansProjects\MyApp\src\java\sound
All audio files get stored in and are accessed from there.
This is purely a dissertation project so I have no intention of making it
work for multiple users or in fact be functional anywhere outside of
my laptop. All files are being uploaded to the file system of the project
itself since that was the only way I knew how to make it work.
>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?
all uploads are called uploadedfile1, uploadedfile2, uploadedfile3 etc
depending on how many files are uploaded.
When these files don't exist already on my file system I sometimes get
null pointer errors and an empty output. Overwriting works better than
creating new.
The filename of the finished file is just called finished.wav. Always. It
just gets overwritten each time I run it. Or not as it seems.
>> 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?
As I said above I just get the parts from the request, for loop through
them and write any audio files to the locations specified in my
MultipartConfig.
>- -chris
Thanks 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
