On 25 Nov 2009, at 14:08, Pid wrote:
> On 25/11/2009 13:03, geoff...@fileflow.com wrote: >> >> On 25 Nov 2009, at 13:26, Pid wrote: >> >>> On 25/11/2009 12:13, geoff...@fileflow.com wrote: >>>> >>>> On 25 Nov 2009, at 12:53, Pid wrote: >>>> >>>>> On 25/11/2009 11:30, geoff...@fileflow.com wrote: >>>>>> On 25 Nov 2009, at 11:10, Pid wrote: >>>>>> >>>>>>> On 25/11/2009 08:17, geoff...@fileflow.com >>>>>>> <mailto:geoff...@fileflow.com> wrote: >>>>>>>> I changed the size to 4K, 50K and 1 byte without any luck. >>>>>>> >>>>>>> What about adding a byte counter to catch when the exception occurs? >>>>>> >>>>>> It happens totally at random. Sometimes after 200KB sometimes after 250MB >>>>> >>>>> Were you able to compare that amount to the size of the file being sent? >>>>> E.g. is it at occuring at unpredictable percentage of file sent. >>>> >>>> It is totally random. Even on the same file. Sometimes just 1% and other >>>> time almost 95%. I tried with files between 5MB and 285MB. I cannot see >>>> any patterns. >>> >>> Is there anything in your application that could cause another thread to >>> access the response object or it's output stream? >>> >>> Given that we don't see problems like this with any frequency, I'd have to >>> lean towards there being something in your application code that is causing >>> this. >>> >> >> I don't see anything that could do it. I didn't even know it was possible. >> It is servlets that responds to doGet and, as I understand it, they all have >> their own response. I don't create any threads in the code nor do I use >> "synchronized" (maybe I could try?). Do you have any examples of how to do >> this? >> I also need to mention that it works fine on another server. > > Synchronisation won't help. > > If it's working fine on a different server that could give us an angle to > look at. What's different about that server, is it identical? Hardware is different. The one working is a much older machine we use as development server (less memory, older CPU, less disk, etc). OS is the same and apache is 6.0.18 on dev and 6.0.20 on the problem server (but it doesn't work with 6.0.18 here either). >>>>>>>> >>>>>>>> On 25 Nov 2009, at 00:28, Pid wrote: >>>>>>>> >>>>>>>>> On 24/11/2009 20:03, Konstantin Kolinko wrote: >>>>>>>>>> 2009/11/24<geoff...@fileflow.com<mailto:geoff...@fileflow.com>>: >>>>>>>>>>> There is a different amount of data sent each time before it >>>>>>>>>>> crashes. I also tried byte by byte and gets the same error but it >>>>>>>>>>> seems that it is less often. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So it is random... I wonder what can trigger it. >>>>>>>>>> >>>>>>>>>> What connectors are you using? Is it HTTP, or AJP? What is your >>>>>>>>>> configuration as a whole? >>>>>>>>>> >>>>>>>>>> There was the following bugreport recently: >>>>>>>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=48105 >>>>>>>>>> >>>>>>>>>> The reporter of issue 48105 wrote that he saw exceptions in 6.0.18, >>>>>>>>>> .20 as well, but no stack traces were provided, so it is unconfirmed. >>>>>>>>> >>>>>>>>> I don't think we got to the bottom of why that was happening. I was >>>>>>>>> hoping the problem would be in the same method, but it's not in >>>>>>>>> exactly the same location for both. >>>>>>>>> >>>>>>>>> The append(byte[], int, int) method is implicated in both, and in >>>>>>>>> both cases an 8k byte buffer was in use in the app code. >>>>>>>>> >>>>>>>>> @Geoffrey - can you try using a smaller (say 4k) byte buffer >>>>>>>>> instead, and adding some code to count how many bytes have been sent >>>>>>>>> when the error occurs? >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
smime.p7s
Description: S/MIME cryptographic signature
