Hello Graham, I have some (good) news for you. I didn't kept you promptly updated because I wanted to test something in this Monday morning in another environment.
The MPM settings I posted before are obviously low. These are the settings we use in a controlled testing/pilot environment and until know every application we served didn't show any problems using these low settings. This is the first application we deployed in this server that required very long lived connections (large media streaming). As soon as we raised the Apache MPM settings up (we tried with the settings you provided as a starting reference) everything worked flawlessly. I wanted to ask you something since your Apache HTTP knowledge is for sure far greater that ours: Why is this phenomenon happening? Maybe because our settings were so low that when Apache needed to create new child processes - and there was no available process - it would terminate an existing one "randomly" (ex: the long running process that was serving the media streaming)? Thank you On Monday, July 22, 2013 1:52:02 AM UTC+1, Graham Dumpleton wrote: > > Can you clarify one point? > > In the instances where this is occurring, is the client always within your > own network, ie., during testing, or is out on the wider Internet. Also, is > the connection coming over HTTPS or a plain HTTP connection. > > That you said that this occurs in embedded mode, still suggests to me that > is an issue occurring between the server and the client. > > Graham > > On 20/07/2013, at 8:50 AM, Tera Byte <[email protected]<javascript:>> > wrote: > > We are in a kind of pilot / tech. evaluation phase so the settings are > somewhat kind of low: > > <IfModule mpm_worker_module> > StartServers 1 > MinSpareThreads 5 > MaxSpareThreads 10 > ThreadsPerChild 10 > MaxRequestWorkers 40 > MaxConnectionsPerChild 0 > </IfModule> > > On Friday, July 19, 2013 11:45:44 PM UTC+1, Graham Dumpleton wrote: >> >> What do you have for the MPM settings in Apache for worker MPM? >> >> <IfModule mpm_worker_module> >> StartServers 2 >> MaxClients 150 >> MinSpareThreads 25 >> MaxSpareThreads 75 >> ThreadsPerChild 25 >> MaxRequestsPerChild 0 >> </IfModule> >> >> Graham >> >> On 20/07/2013, at 8:25 AM, Tera Byte <[email protected]> wrote: >> >> Another detail: >> We are also running mod_jk as our load balancer to Java based application >> servers. plus mod_ssl. >> >> >> On Friday, July 19, 2013 11:19:37 PM UTC+1, Tera Byte wrote: >>> >>> Hello Graham, >>> >>> Completely forgot to mention those important details. Sorry about that. >>> >>> We are running worker MPM (multi-threaded). We also tried refining the >>> apache log level since we read about that recommendation in other posts. We >>> set the level to trace and observed no additional details about the error. >>> Only the "IOError: failed to write data" message and nothing more. >>> >>> Thank you >>> >>> On Friday, July 19, 2013 10:44:18 PM UTC+1, Graham Dumpleton wrote: >>>> >>>> What Apache MPM are you using and what are the MPM settings? >>>> >>>> What else are you running on this Apache server. >>>> >>>> When using daemon mode this error can also be due to the Apache child >>>> worker processes that are proxying requests to the daemon processes being >>>> killed off. >>>> >>>> Make sure you have LogLevel set to info in Apache and see what messages >>>> Apache/mod_wsgi is producing when it occurs beyond just the IOError >>>> details. >>>> >>>> Graham >>>> >>>> On 20/07/2013, at 5:26 AM, Tera Byte <[email protected]> wrote: >>>> >>>> Hello, >>>> >>>> I have seen this question asked at least another time here at modwsgi >>>> group but it looks like there is no concrete answer until now (?). >>>> >>>> I'm streaming quite large media files from django + mod_wsgi but the >>>> streaming terminates abruptly in an almost randomly fashion. The file in >>>> question is about 600MB and the streaming usually terminates between 150 >>>> or >>>> 200MB streaming progress. >>>> >>>> The error message that is written into the log files is the famous >>>> "IOError: failed to write data". Nothing more is written even if I refine >>>> the log level. >>>> >>>> The django application when deployed in the development server works >>>> flawlessly. But when deployed in Apache together with mod_wsgi causes the >>>> problem. >>>> >>>> I'm running mod_wsgi in "daemon process mode". The server has 4GB of >>>> total RAM, being 3GB available during the test scenario I have isolated. >>>> >>>> The django application is returning an iterator like the following, >>>> where data is a urllib2 data stream: >>>> >>>> class FileIterWrapper(object): >>>> def __init__(self, data): >>>> self.data = data >>>> self.chunk_size = 4096 >>>> >>>> def next(self): >>>> data_block = self.data.read(self.chunk_size) >>>> if len(data_block) == 0: >>>> raise StopIteration >>>> else: >>>> return data_block >>>> >>>> def __iter__(self): >>>> return self >>>> >>>> >>>> I really need help with this one. The streaming component of the >>>> overall application could be easily migrated to another technology / >>>> application server but the goal is to stick all with django and mod_wsgi. >>>> >>>> Any pointers? >>>> >>>> Thank you >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "modwsgi" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/modwsgi. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >>>> >>>> >>>> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/modwsgi. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/groups/opt_out.
