From: Gary P. <gar...@as...> - 2006-09-07 17:16:19
|
Hello all, I've searched through all the past mailing list archives & scoured the web looking for an idea as to what's going on. Sorry this is so long, just trying to cover all my bases. First, the setup: CentOS release 4.3 (Final) running Apache 2.0.52 in front of Webware 0.9.1 via mod_webkit(2). Standard httpd configuration, with: LoadModule webkit_module modules/mod_webkit.so <Location /dyn> WKServer 127.0.0.1 8086 SetHandler webkit-handler </Location> All the other WebKit apps run as expected. Here's my problem, and I hope you can help. I have two pages to be served *almost simultaneously* by WebKit: one of them is a large-file upload form processor which--naturally--will take a long time to return (a problem I will try to solve later), the second is a status page that lists the contents of a directory which self-refreshes once every three seconds. While the first is waiting for all the form-data to upload, the second simply does not respond, and eventually throws an Apache Internal Server Error (500). Apache error logs report ten of these: [Wed Sep 06 17:38:36 2006] [error] Can not open socket connection to WebKit AppServer [Wed Sep 06 17:38:36 2006] [error] Couldn't connect to AppServer, attempt 10 of 10, sleeping 1 second(s) ... and finally: [Wed Sep 06 17:38:37 2006] [error] timed out trying to connect to appserver -- giving up. I have WebKit's AppServer running threaded (default AppServer.config): StartServerThreads = 10 MaxServerThreads = 20 MinServerThreads = 5 Someone with greater knowledge of Apache stated: "The default mode for Apache 2 is pre-forking, aka, 1.3 compatibility." ... which I take to mean it forks child processes from the main control (root) process - and this is not the same thing as threading... am I mistaken in this assumption? Finally, is apache's inability to connect to the AppServer an inherent limitation and/or problem with the AppServer, *or* is it caused by running apache in pre-forking mode versus enabling threads there? If so, do you think that running both in threaded mode will resolve the problem? Thanks in advance for any light you can shed on this problem. -Gary |
From: sophana <so...@zi...> - 2006-09-08 12:34:57
|
Gary Perez a =E9crit : > Hello all, > > I've searched through all the past mailing list archives & scoured =20 > the web looking for an idea as to what's going on. Sorry this is so =20 > long, just trying to cover all my bases. > > First, the setup: CentOS release 4.3 (Final) running Apache 2.0.52 in =20 > front of Webware 0.9.1 via mod_webkit(2). Standard httpd =20 > configuration, with: > > LoadModule webkit_module modules/mod_webkit.so > <Location /dyn> > WKServer 127.0.0.1 8086 > SetHandler webkit-handler > </Location> > > All the other WebKit apps run as expected. > > Here's my problem, and I hope you can help. > > I have two pages to be served *almost simultaneously* by WebKit: one =20 > of them is a large-file upload form processor which--naturally--will =20 > take a long time to return (a problem I will try to solve later), the =20 > second is a status page that lists the contents of a directory which =20 > self-refreshes once every three seconds. > > While the first is waiting for all the form-data to upload, the =20 > second simply does not respond, and eventually throws an Apache =20 > Internal Server Error (500). > > Apache error logs report ten of these: > [Wed Sep 06 17:38:36 2006] [error] Can not open socket connection to =20 > WebKit AppServer > [Wed Sep 06 17:38:36 2006] [error] Couldn't connect to AppServer, =20 > attempt 10 of 10, sleeping 1 second(s) > ... and finally: > [Wed Sep 06 17:38:37 2006] [error] timed out trying to connect to =20 > appserver -- giving up. > > I have WebKit's AppServer running threaded (default AppServer.config): > StartServerThreads =3D 10 > MaxServerThreads =3D 20 > MinServerThreads =3D 5 > > Someone with greater knowledge of Apache stated: "The default mode =20 > for Apache 2 is pre-forking, aka, 1.3 compatibility." ... which I =20 > take to mean it forks child processes from the main control (root) =20 > process - and this is not the same thing as threading... am I =20 > mistaken in this assumption? > > Finally, is apache's inability to connect to the AppServer an =20 > inherent limitation and/or problem with the AppServer, *or* is it =20 > caused by running apache in pre-forking mode versus enabling threads =20 > there? If so, do you think that running both in threaded mode will =20 > resolve the problem? > =20 Looking at the error messages, it seems that it is webware that don't accept the connection. I don't know why, and don't even know if I have the same problem. Are you sure that your second request is not blocked by the first one in webware? |
From: Gary P. <gar...@as...> - 2006-09-12 13:59:40
|
On Sep 8, 2006, at 8:34 AM, sophana wrote: > Looking at the error messages, it seems that it is webware that don't > accept the connection. > I don't know why, and don't even know if I have the same problem. > Are you sure that your second request is not blocked by the first =20 > one in > webware? How would I be able to determine whether the second request is being =20 blocked? If the simple answer is "because the second request doesn't =20 get served", then yeah, it's being blocked... but why, and is there a =20= way around this? I admit I don't know a lot about threads/threading, but I was under =20 the impression that the AppServer (as config'd below) could handle =20 multiple, simultaneous requests. Is there something completely obvious that I'm overlooking? > Gary Perez a =E9crit : >> Hello all, >> >> [snip] >> >> I have two pages to be served *almost simultaneously* by WebKit: one >> of them is a large-file upload form processor which--naturally--will >> take a long time to return (a problem I will try to solve later), the >> second is a status page that lists the contents of a directory which >> self-refreshes once every three seconds. >> >> While the first is waiting for all the form-data to upload, the >> second simply does not respond, and eventually throws an Apache >> Internal Server Error (500). >> >> Apache error logs report ten of these: >> [Wed Sep 06 17:38:36 2006] [error] Can not open socket connection to >> WebKit AppServer >> [Wed Sep 06 17:38:36 2006] [error] Couldn't connect to AppServer, >> attempt 10 of 10, sleeping 1 second(s) >> ... and finally: >> [Wed Sep 06 17:38:37 2006] [error] timed out trying to connect to >> appserver -- giving up. >> >> I have WebKit's AppServer running threaded (default =20 >> AppServer.config): >> StartServerThreads =3D 10 >> MaxServerThreads =3D 20 >> MinServerThreads =3D 5 >> >> Someone with greater knowledge of Apache stated: "The default mode >> for Apache 2 is pre-forking, aka, 1.3 compatibility." ... which I >> take to mean it forks child processes from the main control (root) >> process - and this is not the same thing as threading... am I >> mistaken in this assumption? >> >> Finally, is apache's inability to connect to the AppServer an >> inherent limitation and/or problem with the AppServer, *or* is it >> caused by running apache in pre-forking mode versus enabling threads >> there? If so, do you think that running both in threaded mode will >> resolve the problem? |
From: Chuck E. <chu...@gm...> - 2006-09-12 16:35:14
|
On 9/12/06, Gary Perez <gar...@as...> wrote: > On Sep 8, 2006, at 8:34 AM, sophana wrote: > > > Looking at the error messages, it seems that it is webware that don't > > accept the connection. > > I don't know why, and don't even know if I have the same problem. > > Are you sure that your second request is not blocked by the first > > one in > > webware? > > How would I be able to determine whether the second request is being > blocked? If the simple answer is "because the second request doesn't > get served", then yeah, it's being blocked... but why, and is there a > way around this? > > I admit I don't know a lot about threads/threading, but I was under > the impression that the AppServer (as config'd below) could handle > multiple, simultaneous requests. > > Is there something completely obvious that I'm overlooking? Does anyone think this could be Python's GIL kicking in? Perhaps the first thread has acquired the GIL and is not letting it go? Is the first thread using any extension modules (Python modules written in C instead of Python)? What does it do with all the form data being uploaded? -Chuck |
From: Gary P. <gar...@as...> - 2006-09-12 18:06:12
|
On Sep 12, 2006, at 12:35 PM, Chuck Esterbrook wrote: > On 9/12/06, Gary Perez <gar...@as...> wrote: >> On Sep 8, 2006, at 8:34 AM, sophana wrote: >> >>> Looking at the error messages, it seems that it is webware that >>> don't >>> accept the connection. >>> I don't know why, and don't even know if I have the same problem. >>> Are you sure that your second request is not blocked by the first >>> one in >>> webware? >> >> How would I be able to determine whether the second request is being >> blocked? If the simple answer is "because the second request doesn't >> get served", then yeah, it's being blocked... but why, and is there a >> way around this? >> >> I admit I don't know a lot about threads/threading, but I was under >> the impression that the AppServer (as config'd below) could handle >> multiple, simultaneous requests. >> >> Is there something completely obvious that I'm overlooking? > > Does anyone think this could be Python's GIL kicking in? Perhaps the > first thread has acquired the GIL and is not letting it go? GIL (global interpreter lock) - I'm *very* unqualified to address this. > Is the first thread using any extension modules (Python modules > written in C instead of Python)? No sir. From the first thread (form processor): from Template import Template import vtools, os.path ... where "vtools" is an external .py module that's written entirely in Python (no C). The 2nd request is also a python-only module that simply does a glob.glob('*') on the pwd. > What does it do with all the form > data being uploaded? > -Chuck At the moment, it simply does a bit of form checking (e.g., did the user select a file to upload), then writes the file.value from the form data, as such: filename, contents = file.filename, file.value open(os.path.join(PROJDIR + pdir, filename), 'wb').write(contents) As I previously stated, I was going to try to figure out a way to write the file data in chunks (?) so I could provide some type of status display to the user doing the uploading, but that's a problem for a later time... -Gary |
From: Gary P. <gar...@as...> - 2006-09-12 18:20:58
|
On Sep 12, 2006, at 2:06 PM, Gary Perez wrote: > > On Sep 12, 2006, at 12:35 PM, Chuck Esterbrook wrote: > >> On 9/12/06, Gary Perez <gar...@as...> wrote: >> >> Does anyone think this could be Python's GIL kicking in? Perhaps the >> first thread has acquired the GIL and is not letting it go? > > GIL (global interpreter lock) - I'm *very* unqualified to address > this. After a bit of research (http://ldp.paradoxical.co.uk/LDP/LGNET/107/ pai.html), I've found: "In order to support multi threaded Python programs the interpreter regularly releases and reacquires the lock, by default every 10 bytecode instructions. This can however be changed using the sys.setcheckinterval() function. The lock is also released and reacquired around potentially blocking I/O operations like reading or writing a file, so that other threads can run while the thread that requests the I/O is waiting for the I/O operation to complete." And, at first, I thought that the "writing a file" part pertained to my situation--which pointed to AppServer's behavior contradicting the above statement. However, the rate-limiting step in the whole thing is the transfer of 1000s of KB worth of data across the ether. In between the moment that the form's submit button is pressed & the actual file write is called, that's all upload time - the form hasn't been fully submitted until all that goes across the wire, right? So now, Chuck, I'm thinking it might very well be a GIL problem. To get around this, should I explicitly spin off a new thread in the status module? I assume I cannot do it on the upload side, since it's a standard HTTP POST? TIA, -Gary |
From: Dan M. <da...@co...> - 2006-09-12 19:23:04
|
I don't have any kind of answer, but I've had a similar thing come up, so I'll pass it on, in case it helps narrow the focus: - In my dev environment (Webware 0.8.1 / Apache 2 / Mac OS X 10.4), when I do large file uploads, it freezes the entire webware process Works fine in the production environment, so I've been lazy about tracking it down, but it's a particularly nasty freeze. I have to kill -9 the process to get it to die. Which does have the flavor of some sort of GIL issue. "Large" seems to be "large enough that the browser doesn't send it as a single POST" (which it seems to do for small files) Also, you're not going to be able to get a meaningful progress check the way you're trying to. The file upload lifecycle works as follows: - Apache gets the beginning of the huge request - It starts forwarding it to the Webware process - The webware proc uses the cgi library to parse out the values - The cgi library creates a temp file for the upload and fills it as the rest of the request is pulled from Apache - Once it's done getting *all* the data from Apache, Webware then hands control over to your servlet - At that point, when you do things like file.value, it gets read out of that temp file The slow part is happening in the cgi.py library, before your servlet is called. Your servlet is just copying from the temp file, which is fast. You *can* subclass cgi.py and play some games to get a progress check as the temp file is filled (cgi.py is designed to let you override the temp file creation, so you can instrument that, basically). -Dan On Sep 12, 2006, at 2:06 PM, Gary Perez wrote: > > On Sep 12, 2006, at 12:35 PM, Chuck Esterbrook wrote: > >> On 9/12/06, Gary Perez <gar...@as...> wrote: >>> On Sep 8, 2006, at 8:34 AM, sophana wrote: >>> >>>> Looking at the error messages, it seems that it is webware that >>>> don't >>>> accept the connection. >>>> I don't know why, and don't even know if I have the same problem. >>>> Are you sure that your second request is not blocked by the first >>>> one in >>>> webware? >>> >>> How would I be able to determine whether the second request is being >>> blocked? If the simple answer is "because the second request doesn't >>> get served", then yeah, it's being blocked... but why, and is >>> there a >>> way around this? >>> >>> I admit I don't know a lot about threads/threading, but I was under >>> the impression that the AppServer (as config'd below) could handle >>> multiple, simultaneous requests. >>> >>> Is there something completely obvious that I'm overlooking? >> >> Does anyone think this could be Python's GIL kicking in? Perhaps the >> first thread has acquired the GIL and is not letting it go? > > GIL (global interpreter lock) - I'm *very* unqualified to address > this. > >> Is the first thread using any extension modules (Python modules >> written in C instead of Python)? > > No sir. From the first thread (form processor): > > from Template import Template > import vtools, os.path > > ... where "vtools" is an external .py module that's written entirely > in Python (no C). > > The 2nd request is also a python-only module that simply does a > glob.glob('*') on the pwd. > >> What does it do with all the form >> data being uploaded? >> -Chuck > > > At the moment, it simply does a bit of form checking (e.g., did the > user select a file to upload), then writes the file.value from the > form data, as such: > > filename, contents = file.filename, file.value > open(os.path.join(PROJDIR + pdir, filename), 'wb').write(contents) > > As I previously stated, I was going to try to figure out a way to > write the file data in chunks (?) so I could provide some type of > status display to the user doing the uploading, but that's a problem > for a later time... > > -Gary > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss |
From: Chuck E. <chu...@gm...> - 2006-09-12 20:12:56
|
On 9/12/06, Dan Milstein <da...@co...> wrote: > I don't have any kind of answer, but I've had a similar thing come > up, so I'll pass it on, in case it helps narrow the focus: > > - In my dev environment (Webware 0.8.1 / Apache 2 / Mac OS X 10.4), > when I do large file uploads, it freezes the entire webware process > > Works fine in the production environment, so I've been lazy about > tracking it down, but it's a particularly nasty freeze. I have to > kill -9 the process to get it to die. Which does have the flavor of > some sort of GIL issue. Can you tell us what's different between your production and dev environment? That would include how the process is launched as well. And is there a difference in what modules get imported? Also, even if you tapped into the cgi module, would you really be able to give the user a progress bar? It seems that their window would be tied up by the upload task being performed by the browser. Gary, I'm sorry I don't have an answer. I guess I've been lucky enough not to have this problem on production or development. -Chuck |
From: dtillman <dti...@te...> - 2006-09-12 20:29:18
|
Dan Milstein wrote: >> Can you tell us what's different between your production and dev >> environment? That would include how the process is launched as well. >> And is there a difference in what modules get imported? >> > > Let me do some detective work -- I've got a bit of time now, so let > me see what I can find. If I come up blank, I'll pass on everything > I've got. > > >> Also, even if you tapped into the cgi module, would you really be able >> to give the user a progress bar? It seems that their window would be >> tied up by the upload task being performed by the browser. >> > > It works by way of a Javascript function which polls the server every > few seconds and updates the progress bar. The tricky part is getting > some sort of identifier to the Javascript function so that it can > tell the server which upload it's asking about. When I generate the > page, I put in a new unique id which goes both into the URL of the > form action and into the Javascript code. The tapped cgi module then > gets that id from the URL and, as it fills the temp file, updates a > globally-accessible dict with info about the progress. The JS > function hits a servlet which just grabs the progress info from that > dict. > > It's a surprisingly small amount of code, actually -- it just touches > on a lot of stages in subtle ways. > > -D > > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > I'm sorry if I missed the definition of a *large* file - could you provide a figure in bytes please that seems to be the threshhold for causing problems? Thanks. - Doug |
From: Gary P. <gar...@as...> - 2006-09-12 21:03:09
|
On Sep 12, 2006, at 4:29 PM, dtillman wrote: > I'm sorry if I missed the definition of a *large* file - could you > provide a figure in bytes please that seems to be the threshhold for > causing problems? Thanks. > > - Doug Hi Doug, Really "large file" is anything that takes a noticeable time to upload. In my specific case, it's anything that takes longer than three seconds, as that's the refresh rate I've set for the status page that pops up once, then clocks. I suppose it'll depend on the pipe between here and there. I've seen it happen with as little as a 700kb file. The types of files that my application is *supposed* to handle are from a few K up to 10MB each. -Gary |
From: Dan M. <da...@co...> - 2006-09-13 18:54:56
|
Okay, I've done my detective work, and don't have any answers. I'm about to upgrade from Webware 0.8.1 to 0.9.2, so I'll see if that mysteriously fixes things. In the meantime, for those interested, here are the details on the behavior / the environments / etc: - On my dev server, large file uploads stall and lock up a thread. On production, they work fine. The thread which is handling the upload freezes -- the rest of the app is responsive, but that thread gets totally stuck (I had said yesterday that the entire app freezes, but I was wrong). To get the system to shutdown, I have to kill -9 it (a normal restart hangs up in the "ThreadedAppServer: shutting down" stage). - I'm not sure where 'large' kicks in, but around a couple hundred K, I think. I definitely see it for > 1 M files. - Environments: Dev: - Mac OS X 10.4.3 - Apache 2 - Webware 0.8.1 - mod_webkit (from that 0.8.1 version) - python 2.3.5 - launching via WebKit/AppServer start (which runs ThreadedAppServer, I believe) Production: - Linux (2.4.21, sayeth uname -a) - Apache 2 - Webware 0.8.1 - mod_webkit (could be from a more recent webware build -- 0.9.x, possibly) - python 2.3.5 - launching via WebKit/AppServer start I drilled down into the guts of the cgi module and ThreadedAppServer. The place where it's locking up is in a loop in cgi.FileStorage.read_lines_to_outerboundary, in a call to self.fp.readline() (where fp is a file-like object derived from the socket carrying data from Apache). It makes a long series of successful reads from that socket, and then, after getting about 130K of data, it just hangs up. After 5 minutes, the browser cancels the request. At that point, the hung fp.readline() call returns a little more data, and the whole thing completes (in an error state, but the thread is no longer hung). That's what I've got... I'll let you know if the 0.9.2 move helps or not. -Dan On Sep 12, 2006, at 4:12 PM, Chuck Esterbrook wrote: > On 9/12/06, Dan Milstein <da...@co...> wrote: >> I don't have any kind of answer, but I've had a similar thing come >> up, so I'll pass it on, in case it helps narrow the focus: >> >> - In my dev environment (Webware 0.8.1 / Apache 2 / Mac OS X 10.4), >> when I do large file uploads, it freezes the entire webware process >> >> Works fine in the production environment, so I've been lazy about >> tracking it down, but it's a particularly nasty freeze. I have to >> kill -9 the process to get it to die. Which does have the flavor of >> some sort of GIL issue. > > Can you tell us what's different between your production and dev > environment? That would include how the process is launched as well. > And is there a difference in what modules get imported? > > Also, even if you tapped into the cgi module, would you really be able > to give the user a progress bar? It seems that their window would be > tied up by the upload task being performed by the browser. > > Gary, I'm sorry I don't have an answer. I guess I've been lucky enough > not to have this problem on production or development. > > -Chuck > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss |
From: Oliver B. <ol...@g7...> - 2006-09-13 23:50:45
|
> - mod_webkit (from that 0.8.1 version) > Warning: there is a bug in the mod_webkit that was in 0.8.1, which will cause corruption in large transfers. I cannot remember whether it was in the version for Apache or for Apache2. Oliver |
From: Christoph Z. <ci...@on...> - 2006-09-10 07:51:49
|
Gary Perez wrote: > I have two pages to be served *almost simultaneously* by WebKit: one > of them is a large-file upload form processor which--naturally--will > take a long time to return (a problem I will try to solve later), the > second is a status page that lists the contents of a directory which > self-refreshes once every three seconds. Hi Gary, if you send me the two servlets I will try to have a look at it end of next week before releasing 0.9.2. -- Chris |
From: Dan M. <da...@co...> - 2006-09-12 20:22:11
|
> Can you tell us what's different between your production and dev > environment? That would include how the process is launched as well. > And is there a difference in what modules get imported? Let me do some detective work -- I've got a bit of time now, so let me see what I can find. If I come up blank, I'll pass on everything I've got. > Also, even if you tapped into the cgi module, would you really be able > to give the user a progress bar? It seems that their window would be > tied up by the upload task being performed by the browser. It works by way of a Javascript function which polls the server every few seconds and updates the progress bar. The tricky part is getting some sort of identifier to the Javascript function so that it can tell the server which upload it's asking about. When I generate the page, I put in a new unique id which goes both into the URL of the form action and into the Javascript code. The tapped cgi module then gets that id from the URL and, as it fills the temp file, updates a globally-accessible dict with info about the progress. The JS function hits a servlet which just grabs the progress info from that dict. It's a surprisingly small amount of code, actually -- it just touches on a lot of stages in subtle ways. -D |
From: Chuck E. <chu...@gm...> - 2006-09-12 20:31:32
|
On 9/12/06, Dan Milstein <da...@co...> wrote: > > Can you tell us what's different between your production and dev > > environment? That would include how the process is launched as well. > > And is there a difference in what modules get imported? > > Let me do some detective work -- I've got a bit of time now, so let > me see what I can find. If I come up blank, I'll pass on everything > I've got. > > > Also, even if you tapped into the cgi module, would you really be able > > to give the user a progress bar? It seems that their window would be > > tied up by the upload task being performed by the browser. > > It works by way of a Javascript function which polls the server every > few seconds and updates the progress bar. The tricky part is getting > some sort of identifier to the Javascript function so that it can > tell the server which upload it's asking about. When I generate the > page, I put in a new unique id which goes both into the URL of the > form action and into the Javascript code. The tapped cgi module then > gets that id from the URL and, as it fills the temp file, updates a > globally-accessible dict with info about the progress. The JS > function hits a servlet which just grabs the progress info from that > dict. That's neat. I should have presumed it was a Javascript technique. Oops. I better say "AJAX" or I might not be employable. :-) -Chuck |
From: Gary P. <gar...@as...> - 2006-09-13 17:16:44
|
Hello all, Thanks to everyone for your suggestions, investigations, etc. especially to Christoph Zwerschke, who discovered what turned out to be the cause of the problem. Don't use os.chdir() in a threaded environment. I apologize to everyone if this is common knowledge, but it's news to me. At Chris' suggestion, removing the chdir calls in the two modules fixes the problem, and everything works as expected. Thanks again, -Gary On Sep 7, 2006, at 1:16 PM, Gary Perez wrote: > Hello all, > > I've searched through all the past mailing list archives & scoured > the web looking for an idea as to what's going on. Sorry this is so > long, just trying to cover all my bases. > > First, the setup: CentOS release 4.3 (Final) running Apache 2.0.52 in > front of Webware 0.9.1 via mod_webkit(2). Standard httpd > configuration, with: > > LoadModule webkit_module modules/mod_webkit.so > <Location /dyn> > WKServer 127.0.0.1 8086 > SetHandler webkit-handler > </Location> > > All the other WebKit apps run as expected. > > Here's my problem, and I hope you can help. > > I have two pages to be served *almost simultaneously* by WebKit: one > of them is a large-file upload form processor which--naturally--will > take a long time to return (a problem I will try to solve later), the > second is a status page that lists the contents of a directory which > self-refreshes once every three seconds. > > While the first is waiting for all the form-data to upload, the > second simply does not respond, and eventually throws an Apache > Internal Server Error (500). > > Apache error logs report ten of these: > [Wed Sep 06 17:38:36 2006] [error] Can not open socket connection to > WebKit AppServer > [Wed Sep 06 17:38:36 2006] [error] Couldn't connect to AppServer, > attempt 10 of 10, sleeping 1 second(s) > ... and finally: > [Wed Sep 06 17:38:37 2006] [error] timed out trying to connect to > appserver -- giving up. > > I have WebKit's AppServer running threaded (default AppServer.config): > StartServerThreads = 10 > MaxServerThreads = 20 > MinServerThreads = 5 > > Someone with greater knowledge of Apache stated: "The default mode > for Apache 2 is pre-forking, aka, 1.3 compatibility." ... which I > take to mean it forks child processes from the main control (root) > process - and this is not the same thing as threading... am I > mistaken in this assumption? > > Finally, is apache's inability to connect to the AppServer an > inherent limitation and/or problem with the AppServer, *or* is it > caused by running apache in pre-forking mode versus enabling threads > there? If so, do you think that running both in threaded mode will > resolve the problem? > > Thanks in advance for any light you can shed on this problem. |
From: Chuck E. <chu...@gm...> - 2006-09-14 00:13:06
|
On 9/13/06, Gary Perez <gar...@as...> wrote: > Hello all, > > Thanks to everyone for your suggestions, investigations, etc. > especially to Christoph Zwerschke, who discovered what turned out to > be the cause of the problem. > > Don't use os.chdir() in a threaded environment. > > I apologize to everyone if this is common knowledge, but it's news to > me. At Chris' suggestion, removing the chdir calls in the two modules > fixes the problem, and everything works as expected. After launching, should the WebKit app server do something like this: def bad_chdir(path): raise Exception('You cannot reliably use os.chdir() in a threaded environment.') os.chdir = bad_chdir ? Seems like this would catch this kind of error early on and save people some time. -Chuck |
From: John D. <jdi...@te...> - 2006-09-14 18:24:48
|
Maybe I'm a little dense here, but I'm not seeing why os.chdir is such a bad thing in a threaded environment. I did a little google-ing, but I did not find anything the was talking about problems in a threaded environment. I would guess that maybe the issue is that module references could get a little wonky if two threads reference the same module and one uses os.chdir. Then maybe that thread's module reference is off and it messes up any object that may be common to both threads. But that's just a guess, and I really don't know a lot about the specifics of imports or module references. Could you explain the issue, please? --John Gary Perez wrote: > > > Don't use os.chdir() in a threaded environment. > > I apologize to everyone if this is common knowledge, but it's news to > me. At Chris' suggestion, removing the chdir calls in the two modules > fixes the problem, and everything works as expected. > |
From: Chuck E. <chu...@gm...> - 2006-09-14 18:49:34
|
Threads execute in parallel, or at least they alternate back and forth very quickly. So imagine thread t1 does: chdir to B write file C and thread t2 does chdir to D write file E But in reality the threads are going at the same time so things can get mixed up like so: t1 - chdir to B t2 - chdir to D t1 - write file C <-- woops. landed in the wrong directory The easiest solution is to just use full paths and skip the chdir as Gary pointed out. Another solution would be to put locks around the mutually exclusive code, but I wouldn't go that route for something that is so easy to fix. To sum up, you only get one current directory per process, not per thread. HTH, -Chuck On 9/14/06, John Dickinson <jdi...@te...> wrote: > Maybe I'm a little dense here, but I'm not seeing why os.chdir is such a > bad thing in a threaded environment. I did a little google-ing, but I > did not find anything the was talking about problems in a threaded > environment. > > I would guess that maybe the issue is that module references could get a > little wonky if two threads reference the same module and one uses > os.chdir. Then maybe that thread's module reference is off and it messes > up any object that may be common to both threads. But that's just a > guess, and I really don't know a lot about the specifics of imports or > module references. > > Could you explain the issue, please? > > --John > > Gary Perez wrote: > > > > > > Don't use os.chdir() in a threaded environment. > > > > I apologize to everyone if this is common knowledge, but it's news to > > me. At Chris' suggestion, removing the chdir calls in the two modules > > fixes the problem, and everything works as expected. > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Christoph Z. <ci...@on...> - 2006-09-14 18:59:47
|
John Dickinson wrote: > Maybe I'm a little dense here, but I'm not seeing why os.chdir is such a > bad thing in a threaded environment. I did a little google-ing, but I > did not find anything the was talking about problems in a threaded > environment. The following program shows the problem quite clearly: ---------------------------- from os import mkdir, chdir from time import sleep from threading import Thread try: # make test dirs mkdir('dir1') mkdir('dir1/dir2') open('dir1/test', 'w').write('inside dir1') open('dir1/dir2/test', 'w').write('inside dir2') except: pass def thread1(): chdir('dir1') sleep(0.2) print "test file in dir1:", open('test').read() def thread2(): sleep(0.1) chdir('dir2') Thread(target=thread1).start() Thread(target=thread2).start() ---------------------------- From looking at the thread1 function, you would expect "inside dir1" as output, but because thread2 is interfering, it prints "inside dir2". I have added the sleep calls to make the behavior predictable. In a real threaded environment, the output would be unpredictable. -- Chris |
From: Christoph Z. <ci...@on...> - 2006-09-14 08:27:09
|
> os.chdir = bad_chdir I think that is not a bad idea. Maybe we can also add a note that it is ok to use chdir in your own subprocesses. Any other dangerous functions that we could mask that way? -- Chris |
From: Chuck E. <chu...@gm...> - 2006-09-14 16:46:16
|
On 9/14/06, Christoph Zwerschke <ci...@on...> wrote: > > os.chdir = bad_chdir > > I think that is not a bad idea. Maybe we can also add a note that it is > ok to use chdir in your own subprocesses. Any other dangerous functions > that we could mask that way? > > -- Chris Not that I can think of. -Chuck |
From: Mark P. <ma...@mo...> - 2006-09-14 17:54:02
|
On Sep 13, 2006, at 10:16 AM, Gary Perez wrote: > At Chris' suggestion, removing the chdir calls in the two modules > fixes the problem, and everything works as expected. What did you do? or where did you move it to? Mark Phillips |
From: Gary P. <gar...@as...> - 2006-09-14 18:02:20
|
On Sep 14, 2006, at 1:53 PM, Mark Phillips wrote: > On Sep 13, 2006, at 10:16 AM, Gary Perez wrote: > >> At Chris' suggestion, removing the chdir calls in the two modules >> fixes the problem, and everything works as expected. > > What did you do? or where did you move it to? Parts of my file upload modules were using os.chdir() to switch to a directory and create a new directory inside where the files would ultimately be copied. So instead of: os.chdir(PARENT_DIR) os.mkdir(NEW_DIR) ... I replaced it with: os.mkdir(os.path.join(PARENT_DIR, NEW_DIR)) To actually write a file inside the new directory, instead of: os.chdir(NEW_DIR ) file = open('index', 'wb') ... I replaced it with: file = open(os.path.join(PARENT_DIR, NEW_DIR, filename), 'wb') Basically, I took out any and all calls to os.chdir() - and that was the magic bullet. HTH, -Gary |
From: Mark P. <ma...@mo...> - 2006-09-14 18:11:46
|
On Sep 14, 2006, at 11:02 AM, Gary Perez wrote: > On Sep 14, 2006, at 1:53 PM, Mark Phillips wrote: > >> On Sep 13, 2006, at 10:16 AM, Gary Perez wrote: >> >>> At Chris' suggestion, removing the chdir calls in the two modules >>> fixes the problem, and everything works as expected. >> >> What did you do? or where did you move it to? > > Parts of my file upload modules were using os.chdir() to switch to a > directory and create a new directory inside where the files would > ultimately be copied. > > So instead of: > > os.chdir(PARENT_DIR) > os.mkdir(NEW_DIR) > > ... I replaced it with: > > os.mkdir(os.path.join(PARENT_DIR, NEW_DIR)) > > To actually write a file inside the new directory, instead of: > > os.chdir(NEW_DIR ) > file = open('index', 'wb') > > ... I replaced it with: > > file = open(os.path.join(PARENT_DIR, NEW_DIR, filename), 'wb') > > Basically, I took out any and all calls to os.chdir() - and that was > the magic bullet. > > HTH, > -Gary Nice. Thanks. - Mark |