"David kerber" <dcker...@verizon.net> wrote in message news:4a0dbf88.6030...@verizon.net... > Christopher Schultz wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> David, >> >> On 5/15/2009 12:22 PM, David kerber wrote: >> >>> But the code works; it just seems to be a little slow. >>> >> >> Gotcha. How slow are we talking, here? I'm not sure whether the >> underlying InputStream, here, is buffering, but you could try: >> > Not noticeably slow from a human watching it viewpoint, but when I do a > thread dump, I see quite a few of the threads waiting on the .read() > statement. "quite a few" in the case of the one I did just now (the > busiest time of day for this app) means 12 out of the total of 75 > http-processorXXX threads. > >> iStream = new BufferedInputStream(req.getInputStream()); >> >> ... to see if that improves things at all. >> > I was wondering about that, too. I couldn't see anything that > specifically said whether the InputStream from an HttpServletRequest was > buffered or not, but the implication from some reading about a 3rd party > BufferedServletInputStream is that TC 4.x and later provide a buffer for > it. >
Yes, the TC implementation of the ImputStream from the Request is buffered (although it doesn't extend BufferedInputStream). It is possible that wrapping it in a BufferedInputStream could even slow the app down (by making it wait until all the data is available). >> >>> At this point, [the data is] still encrypted, and a string may not >>> properly >>> handle some of the bytes. >>> >> >> Oh, right. I forgot you were sending encrypted data. >> >> >>>> I think you may have better luck reading until there is no more input, >>>> >>> What method would you suggest? Create the byte array long enough to >>> handle any possible input and then read without specifying the length? >>> >> >> Something like that. After thinking a bit about it, specifying more >> bytes to read than are available either blocks (waiting for more data >> that will come) or returns after reading fewer bytes (because the stream >> is closed and there's no more to read). Your code should be pretty good >> as-is. >> > > Thanks, > D --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
