From: Love, J. <Jay...@us...> - 2000-12-12 16:07:51
|
Tom- I'll take a fresh look at the extra path info feature. I did the original implementation, based on a request from an early user. It worked fine in most cases, but broke on a couple of things. The biggest problem was that the way the cacheing of servlets works, the News servlet would get cached for each set of extra path info attached. So there would be a cache entry for News/11/2 and News/11/3, etc. That's what got it commented out. There was also a problem with getting it to behave correctly with trailing slashes on URL's. We went through a very difficult process trying to get trailing slashes to work right, and the extra path info code just made it more difficult. I like this feature and I'll take a look at getting it working. But Chuck's right, it can't break anything, and it has a habit of doing that. Jay Love At 11:42 AM 12/12/2000 +0000, Tom Schwaller wrote: >Is this functionality (request.extraPath() )difficult to put into >Webware? >That would be all I really need there, because >it gives all the necessary flexibility As I said before the code can be a little tricky in this area, although the basics are already there. > > Also, the session id could be implemented by request, response and > > application in such a way that it was invisible to servlets. No embedded > > servlet URLs needed. > >interesting, as usual I'm looking for some code :-) > > > I really see these as unrelated issues. > > > > >There is some "if 0:" code in Application.py > > >which implements it (tough code for me :-)), > > >though is is not standard right now and is > > >small a performance-"killer". But I really > > >need this feature.. > > > > It was only disabled because an overhaul of the serverSidePathForRequest() > > code broke it, and it wasn't a high priority at the time. If someone wants > > to put it back in, they can. You're right, it is tricky. If implemented, I > > ask that all the previous test cases work (see the Testing context) and > > that a configuration option can turn it off. > > It would be a nice addition, but it's not on my personal list of > enhancements. > >Is this the same as "request.extraPath()" or is there more in it? Yes. > > >Maybe one could set some variable to mark > > >a directory if this mechanism should apply. > > >I guess the general case would be like > > >the one used right now, but in other cases > > >it is more than useful. > > > > > >e.g. /News/2000/10/index.py > > > > > >to get all News from october 2000. > > > > So News would be a servlet that would get an extra path value of > > '/2000/10/index.py'. > >yep.. > > > First off, you can chop off 'index.py'. It wouldn't seem useful. > > > > Second, in the absence of "extra path URLs" you have 2 options I can > think of: > > > > This is one: > > /News?year=2000&month=10 > > > > News could then be a directory containing something like "index.py", or it > > could be a servlet, as in News.py. If it were a directory, I guess you'd > > want to hand out this URL to avoid the extra redirect: > > > > /News/?year=2000&month=1 > >Is no big deal that way, but for bookmarking >the /News/2000/12 version is better. >It would also be my preferred way for the simple example I >asked for : /News/post, News/overview, News/2000 all handled >by the same servlet, probably using a WEB API from a Can, >which does the real handling of the data.. In my current style, 'post' and 'overview' are individual servlets that communicate with "domain objects", in this case NewsStory objects, to change the data. This is similar to how I used to do GUI programming. I didn't have one view class handling several different views in an application. Each different looking view was his own thing. > > Also, if you were really bent on the /2000/10/ directory structure, you > > could do this: > > * create directories such as 2000/ 2000/01/ 2000/02/ ... > > * in each directory make a link to an index.py somewhere > > * in each directory put your news content files > > * in index.py examine self.serverSideDir() in order to locate > files > > * Now you can do this: <http://host.com/News/2000/10/> > > * (this solutions assumes you have UNIX because it relies on > links) > >It seems tempting to do it that way, but >it is only one simple case I use (with Zope right now). >I have stuff like > >/News/2000/authorname >for all news of the author "authorname" in this year (2000) > >/News/2000/12/authorname >/News/Graphics (all news to related to graphics) >Of course you can organize all this stuff with News?topic=graphics,... > > > > You might also wonder if your content should go in a database instead of on > > the file system, but Webware let's you do either by virtue of the fact that > > it doesn't dictate it. > >That's what I really like about it :-) > > > The first approach (/News?year=2000&month=10) let's you switch back and > > forth between a database and a file system without changing URLs. The > > second approach would only let you switch storage techniques if the > > embedded servlet URL feature were present. > >I hope I can motivate you to put it in somehow, because >it will make some things really very simple (I'd like >to work one level higher with Webware. If do not have >the time, I'll look to make a small project here to implement it >with another guy which does more of this "hardcore stuff" :-)) > >just my 2 cents :-) With open source, authors tend to focus on things that are important to them. Neither session ids nor embedded servlet URLs are on my personal list (which is currently FormKit, MiddleKit and processing Vlk's patches). Your options seem to be: * Hope another one of the Webware developers tackle these 2 features * Hope someone posts a patch for these * Implement these yourself * Pay someone to implement them Again, I think these are good features, but I don't need or have time for them right now. Good luck, -Chuck ---------------------------------------------------------------------------- This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation. ---------------------------------------------------------------------------- |
From: Love, J. <Jay...@us...> - 2001-01-12 21:22:06
|
I think a formalized task manager is a great idea. We had intended to get to something like this when we did the initial session sweeper stuff. I'd like to suggest a slightly different approach, however. It looks like in the code below, you'd spawn a thread for every task. This seems messy and would require each task to, possibly, manage it's own sleep cycle, etc. My alternate suggestion is a more cron like system. We'd have one main task thread that would wake up every 5 seconds or so, and go through a list of Task objects to see if any need to be run. The Task class could specify whether it would like to be run from the TaskManager thread (for quick tasks), in which case we would just call the Run() function of the Task instance, or it could request to be run in a new thread (for longer tasks, like a session sweep), so it won't tie up the TaskManager thread. The Task class would define a function called runTest(currenttime) that would return true to indicate it should be run now, or false to say don't run now. The default implementation might just check to see when it was last run (from an internal variable) and see if it should be run now by comparing the last run time + Task.interval to currenttime. Then more advanced Task classes could just override this function. Does that make more sense? Or was I just missing something in the below implementation? Jay Tom Schwaller wrote: ---------------------------------------------------------------------------- -------------------------- In the last discussions we touched implicitely some task scheduling questions. I looked at the Application.py code to search for a place, where one could plug that in (better than a TaskKit?), because I think this could become important for many things. You can do it with OS mechnism, but to have it crossplattform in the application framework would be really nice and a great plus. ########################################################### One scheduling example is realized for Sessions: in __init__.py you have if useSessionSweeper: self.startSessionSweeper() def startSessionSweeper(self): def sweepSessionsContinuously(self,close): def sweepSessions(self): ########################################################### Let's make this more general (Task seems a good name). Look at the following python code + pseudocode, where I just show what I have in mind, not every detail (sleeping time, ...) Application(self,....,useTasks=1,..) def __init(self,...) if useTasks: self._tasks = get tasklist from Application.config or by a name convention *Task.py self.startTasks() # possible Tasks: # * Session, # * Scheduling of "Webware cronjobs" # * Generate static pages # * update in memory information def startTasks(self): #self._tasks could also be a parameter for task in self._tasks: task.run(app, close) class Task: def run(self, app, close): # for Session this is called # sweepSessionsContinuously: # there you need app.running, app.sessions(), class SessionSweepTask(Task): def run(self, app, close): while self.running: self.sweepSessions() try: close.wait(self.setting('SessionTimeout')*60/10.0) except IOError: pass def sweepSessions(self, app): sessions = app.sessions() ... class CalendarTask(Task): # this is for tasks which run once or # no seldom. use a Task subclass if # your task ha to be scheduled often #(e.g. every Minute..) # use mxDateTime for this kind of stuff def run(self, app, close): class PageWriterTask(Task): def run((self, app, close): #generate staic pages ########################################################### in Application.config use: 'Tasks': ['SessionSweep', 'Calendar', 'PageWriter'], ########################################################### hey, hope you like this proposal. I'm sure I forgot something, but it looks ok afrer reading it several times :-) The amazing thing with Webware ist, that you can go down to the framework, understand and even change it. After 2 years of Zope programming I still have no idea how it works under the hood! -- Tom Schwaller http://www.linux-community.de ---------------------------------------------------------------------------- This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation. ---------------------------------------------------------------------------- |
From: Tom S. <tom...@li...> - 2001-01-12 22:05:26
|
"Love, Jay" wrote: > > I think a formalized task manager is a great idea. We had intended to get thanks... > to something like this when we did the initial session sweeper stuff. Hmm, so you seem the ideal person to code it :-) I'm not shure anymore that I'm able to implement it myself, because there are quite many things to take care of, but I'll try if there's nobody else... > I'd like to suggest a slightly different approach, however. > > It looks like in the code below, you'd spawn a thread for every task. This > seems messy and would require each task to, possibly, manage it's own sleep > cycle, etc. > > My alternate suggestion is a more cron like system. We'd have one main task > thread that would wake up every 5 seconds or so, and go through a list of > Task objects to see if any need to be run. The Task class could specify > whether it would like to be run from the TaskManager thread (for quick > tasks), in which case we would just call the Run() function of the Task > instance, or it could request to be run in a new thread (for longer tasks, > like a session sweep), so it won't tie up the TaskManager thread. > > The Task class would define a function called runTest(currenttime) that > would return true to indicate it should be run now, or false to say don't > run now. The default implementation might just check to see when it was > last run (from an internal variable) and see if it should be run now by > comparing the last run time + Task.interval to currenttime. Then more > advanced Task classes could just override this function. > > Does that make more sense? Or was I just missing something in the below > implementation? No, makes perfect sense. I'm just trying to digest all the positive feedback I got to my proposal. Starting a new thread for each task was the first approach, because I assumed, that there are not many "heavy weight" tasks (the "cronjob task" was supposed to manage the many jobs which are run once or seldom..). I feared that polling many tasks ("do you want to run?"), which in most cases do nothing, would be a bad idea, but your approach mixes both ideas, which is probably the way to go. You have maximal flexibility and can exactly do wat you want. cool ideas from all of you. Let's make the TaskManager happen :-) -- Tom Schwaller http://www.linux-community.de |
From: Jay L. <js...@js...> - 2001-01-12 22:53:54
|
Tom Schwaller wrote: > >> to something like this when we did the initial session sweeper stuff. > > > Hmm, so you seem the ideal person to code it :-) > I'm not shure anymore that I'm able to implement it myself, because > there are quite many things to take care of, but I'll try > if there's nobody else... > > > We'll work on it together. I write the least elegant classes of anyone around here, so I'll focus on the Application integration through a mixin, If you'll think about the Task class, etc. Jay |
From: Tom S. <tom...@li...> - 2001-01-13 01:08:05
|
Jay Love wrote: > > Tom Schwaller wrote: > > > > >> to something like this when we did the initial session sweeper stuff. > > > > > > Hmm, so you seem the ideal person to code it :-) > > I'm not shure anymore that I'm able to implement it myself, because > > there are quite many things to take care of, but I'll try > > if there's nobody else... > > > > > > > We'll work on it together. I write the least elegant classes of anyone > around here, so I'll focus on the Application integration through a > mixin, If you'll think about the Task class, etc. Ok, I'll give it a try then.. -- Tom Schwaller http://www.linux-community.de |
From: Chuck E. <ec...@mi...> - 2001-01-13 14:16:29
|
At 03:12 PM 1/12/2001 -0600, Love, Jay wrote: >I think a formalized task manager is a great idea. We had intended to get >to something like this when we did the initial session sweeper stuff. > >I'd like to suggest a slightly different approach, however. > >It looks like in the code below, you'd spawn a thread for every task. This >seems messy and would require each task to, possibly, manage it's own sleep >cycle, etc. The code to manage the sleep cycle would be captured in Task. e.g., task implementors don't have to write this code because they inherit it. >My alternate suggestion is a more cron like system. We'd have one main task >thread that would wake up every 5 seconds or so, and go through a list of >Task objects to see if any need to be run. The Task class could specify >whether it would like to be run from the TaskManager thread (for quick >tasks), in which case we would just call the Run() function of the Task >instance, or it could request to be run in a new thread (for longer tasks, >like a session sweep), so it won't tie up the TaskManager thread. Polling every X seconds is generally a poor technique (in this case X=5). If you need granularity less than X you are out of luck. Unless you can change X. But be careful not to ever make X bigger; one of your tasks might rely on it and break. My point is that X is going to be "wrong". Polling is always too much or too little, and when you tweak it you have to be very careful that you don't break anything. Also, if your tasks are really running every 5 minutes, then running through the list an extra 59 times is very wasteful. >The Task class would define a function called runTest(currenttime) that >would return true to indicate it should be run now, or false to say don't >run now. The default implementation might just check to see when it was >last run (from an internal variable) and see if it should be run now by >comparing the last run time + Task.interval to currenttime. Then more >advanced Task classes could just override this function. Seems like implementing runTest() to return "self.lastRunTime + self.interval > curTime" is just as messy or more so than "self.waitFor(self.interval)". Both approaches requiring a line of code, but the waitFor() and waitUntil() are plainly readable. >Does that make more sense? Or was I just missing something in the below >implementation? Besides the above, consider that implementing polling in the system I originally described is 4 lines of code: class Poller(Task): def run(self): self.poll() self.waitFor(5) Given polling's disadvantages and the ease of implementing it as a specific type of general purpose task, I believe the earlier proposal is better. -Chuck |
From: Jay L. <js...@js...> - 2001-01-14 04:10:20
|
OK, Chuck, you're probably right. I just don't like the idea of spawning unecessary threads that will sleep mose of the time. Tom, do you have time to do this? Jay Chuck Esterbrook wrote: > At 03:12 PM 1/12/2001 -0600, Love, Jay wrote: > >I think a formalized task manager is a great idea. We had intended to get > >to something like this when we did the initial session sweeper stuff. > > > >I'd like to suggest a slightly different approach, however. > > > >It looks like in the code below, you'd spawn a thread for every task. This > >seems messy and would require each task to, possibly, manage it's own sleep > >cycle, etc. > > The code to manage the sleep cycle would be captured in Task. e.g., task > implementors don't have to write this code because they inherit it. > > >My alternate suggestion is a more cron like system. We'd have one main task > >thread that would wake up every 5 seconds or so, and go through a list of > >Task objects to see if any need to be run. The Task class could specify > >whether it would like to be run from the TaskManager thread (for quick > >tasks), in which case we would just call the Run() function of the Task > >instance, or it could request to be run in a new thread (for longer tasks, > >like a session sweep), so it won't tie up the TaskManager thread. > > Polling every X seconds is generally a poor technique (in this case X=5). > If you need granularity less than X you are out of luck. Unless you can > change X. But be careful not to ever make X bigger; one of your tasks might > rely on it and break. > > My point is that X is going to be "wrong". Polling is always too much or > too little, and when you tweak it you have to be very careful that you > don't break anything. > > Also, if your tasks are really running every 5 minutes, then running > through the list an extra 59 times is very wasteful. > > >The Task class would define a function called runTest(currenttime) that > >would return true to indicate it should be run now, or false to say don't > >run now. The default implementation might just check to see when it was > >last run (from an internal variable) and see if it should be run now by > >comparing the last run time + Task.interval to currenttime. Then more > >advanced Task classes could just override this function. > > Seems like implementing runTest() to return "self.lastRunTime + > self.interval > curTime" is just as messy or more so than > "self.waitFor(self.interval)". Both approaches requiring a line of code, > but the waitFor() and waitUntil() are plainly readable. > > >Does that make more sense? Or was I just missing something in the below > >implementation? > > Besides the above, consider that implementing polling in the system I > originally described is 4 lines of code: > > class Poller(Task): > def run(self): > self.poll() > self.waitFor(5) > > Given polling's disadvantages and the ease of implementing it as a specific > type of general purpose task, I believe the earlier proposal is better. > > -Chuck > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > http://lists.sourceforge.net/lists/listinfo/webware-discuss |
From: Tripp L. <tl...@pe...> - 2001-01-14 07:49:36
|
On Sat, 13 Jan 2001, Jay Love wrote: > OK, Chuck, you're probably right. I just don't like the idea of spawning > unecessary threads that will sleep mose of the time. What about having a single scheduler thread that sleeps until the next event? Basically, when you add a new task to the task manager, it recalculates the "next event", wakes up the presumably sleeping scheduler thread, which puts itself back to sleep with an updated "next event" time. When that timer expires, the thread wakes up and executes all events scheduled for that time slot. Best of both worlds -- only one sleeping thread, and no polling. -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ ------------------------------------------------------------------------------ "East bound and down, loaded up and truckin', - Jerry Reed we're gonna do what they say can't be done." - "East Bound and Down" |
From: Tom S. <tom...@li...> - 2001-01-14 16:02:57
|
Tripp Lilley wrote: > > On Sat, 13 Jan 2001, Jay Love wrote: > > > OK, Chuck, you're probably right. I just don't like the idea of spawning > > unecessary threads that will sleep mose of the time. > > What about having a single scheduler thread that sleeps until the next > event? Basically, when you add a new task to the task manager, it > recalculates the "next event", wakes up the presumably sleeping scheduler > thread, which puts itself back to sleep with an updated "next event" time. > When that timer expires, the thread wakes up and executes all events > scheduled for that time slot. > Best of both worlds -- only one sleeping thread, and no polling. good solution. (can be quite involved to compute the next task time...). I think starting with new threads like I did is a good first start, then we refine it step by step. B.T.W. My first simple tests showed that self._close.wait(seconds) is quite imprecise (self._close =Event()) compared to sleep(interval), but how to stop a "sleep" when shutting down the AppServer? -- Tom Schwaller http://www.linux-community.de |
From: Tripp L. <tl...@pe...> - 2001-01-14 18:39:41
|
On Sun, 14 Jan 2001, Tom Schwaller wrote: > > recalculates the "next event", wakes up the presumably sleeping scheduler > > thread, which puts itself back to sleep with an updated "next event" time. > > When that timer expires, the thread wakes up and executes all events > > scheduled for that time slot. > > good solution. (can be quite involved to compute the next task time...). > I think starting with new threads like I did is a good first > start, then we refine it step by step. Yeah, using a plugin-based scheduler would be good. That way, we can optimize the scheduler over time, and clients can explicitly choose a scheduling method, if they need to (for instance, if they need finer granularity than that offered by any sleep-based solutions). As for keeping track of the next task time, it's actually not that bad. You maintain a min heap of scheduled times so that the next "interesting" time is at the top of the heap (with a list of attached events to run). The actual computation of next task time can be as simple as adding seconds, and as complex as parsing an intricate schedule specification (see, of course, crontab(5), and Perl's Date::Manip library). Of course, if at all possible, we should reuse existing code to do that part, but I'm unaware of any Python module approaching the raw coolness of Date::Manip for such tasks :) -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ ------------------------------------------------------------------------------ "The ability of the Internet to position dog excrement at the center of so many lucrative commercial transactions is one of the most astonishing developments of the new millennium." From <http://www.forbes.com/asap/2000/1127/129.html> |
From: Jay L. <js...@js...> - 2001-01-14 20:56:31
|
Tom Schwaller wrote: > > B.T.W. My first simple tests showed that > > self._close.wait(seconds) > > is quite imprecise (self._close =Event()) > > compared to > > sleep(interval), but how to stop a "sleep" when shutting down > the AppServer? > That's why we're using the close.wait() thing. When you do a ctrl-c, (Keyboard Interrupt), sometimes the sleeping thread will get the interrupt, but the main thread won't see it, and things get messed up. That's where the IOError came from, if memory serves. If the sleeping thread is using close.wait, maybe that throws an IOError? Anyway, don't worry about it for now. Just use sleep, and we'll refine later. Also, we should make that thread daemonic, so if we're exiting we don't have to wait for it to wake up. We'll still call Task.shutdown() or something like that for all the active tasks, but we'll just let that thread die off. Jay |
From: Chuck E. <ec...@mi...> - 2001-01-14 17:17:57
|
At 08:27 AM 1/14/2001 +0000, Tripp Lilley wrote: >On Sat, 13 Jan 2001, Jay Love wrote: > > > OK, Chuck, you're probably right. I just don't like the idea of spawning > > unecessary threads that will sleep mose of the time. > >What about having a single scheduler thread that sleeps until the next >event? Basically, when you add a new task to the task manager, it >recalculates the "next event", wakes up the presumably sleeping scheduler >thread, which puts itself back to sleep with an updated "next event" time. >When that timer expires, the thread wakes up and executes all events >scheduled for that time slot. > >Best of both worlds -- only one sleeping thread, and no polling. You beat me to it. I was going to post this idea today. What are you doing up at 8:27am anyway? I thought you slept form like 5AM to 12PM or something... In any case, the other thing I was going to point out is that WebKit already spawns 10 threads for it's thread pool and Apache 1.3.x on Windows reports having 51 threads on Windows ME (I don't know why, I thought it was forked, not threaded). The point I'm leading up to is that [a] we could easily spare another dozen threads and [b] most applications aren't like to even get up to a dozen tasks anytime soon. I think the one-thread-per-task approach is fine for now. -Chuck |
From: Tripp L. <tl...@pe...> - 2001-01-14 18:48:55
|
On Sun, 14 Jan 2001, Chuck Esterbrook wrote: > What are you doing up at 8:27am anyway? I thought you slept form like 5AM > to 12PM or something... My clock is fscked, and I'm too lazy to fix it. Subtract about six hours, so that message was around 02:30. > The point I'm leading up to is that [a] we could easily spare another dozen > threads and [b] most applications aren't like to even get up to a dozen > tasks anytime soon. Sez you :) I've got plenty of plans for tasks running rampant. However, I can also implement the snazzier scheduler later, after I port Date::Manip to Python :) -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ ------------------------------------------------------------------------------ "The ability of the Internet to position dog excrement at the center of so many lucrative commercial transactions is one of the most astonishing developments of the new millennium." From <http://www.forbes.com/asap/2000/1127/129.html> |
From: Simon K. <ti...@ja...> - 2001-02-01 00:24:47
|
>Currently I have it set up so it unpickles a >file into the session data on >awake() , is this the best way to do it? <jay love wrote> I've been meening to write something like this. I look forward to seeing your code. Like this :) This is the viewing page, GalPage is a version of the included Example page for consistancy. def awake(self, transaction): " generates a session with the pics in it " GalPage.awake(self, transaction) sess = transaction.session() if not sess.hasValue('pics'): list = self.load_list() classes = {} for i in list: if not classes.has_key(i[1]): classes[i[1]]=1 class_list = classes.keys() class_list.append('all') ## add all class sess.setValue('pics', list ) sess.setValue('classes',class_list) sess.setValue('the_class','') ## current class self._error = None def load_list(self): " returns a list of pics " f3 = open(base +'/pic_def','r') u = pickle.Unpickler(f3) pic_list = u.load() f3.close() return pic_list where pics is a pickled list that contains file names, pic type , comments , size etc. the classes dictionary is used to get the unique catagories in the list of files. This also means that _each_ user has a separate copy of the /pic_def file in their session ( this could get big ), however it seems to work. I have got the main browsing page going (sort of), next is the update page that creates the thumbnails. what i have done so far is available in (4k) at http://jacked.ii.net/Gal.tar.gz this is work in progress so if you computer blows up in a big steaming mess of molten plastic bits then don't blame me :) Cheers Simon Kirkby |
From: <in...@as...> - 2001-03-12 12:38:03
|
Idea: Instead of usage OneShot adapters to start Monitor.py from Cgi or FastCgi adapter - if It fails connection with AppServer. |
From: Terrel S. <tsh...@tr...> - 2001-03-12 18:25:27
|
"=3D?koi8-r?Q?=3DE1=CE=C4=D2=3DC5=CA?=3D" wrote: > Idea: > > Instead of usage OneShot adapters to start Monitor.py from Cgi or FastC= gi > adapter - if > It fails connection with AppServer. I was thinking about that myself. I am working with a hosting provider that frowns on long-running processe= s. I do not expect a lot of traffic, but it would be nice to start the appserver when a visitor does come. "LazyStart" could if webware is running: connect to it to handle the request (as WebKit.cgi currently does= ) else: fork and fire up appserver run as OneShot in the parent process Hopefully appserver will be running by the time the next request comes in= , and the response will be that much faster. The running appserver could a= lso kill itself after a specified idle time, to keep the hosting company happ= y. (They have a cron job that does this anyway.) This idea could also be incorporated into mod_webkit for extra robustness/flexibility. Issues: How does the appserver signal when it is ready to serve? How to avoid spawing several appservers if the first one takes a long time to start? How does appserver signal when it is shutting down (while finishing already queued requests)? For high-traffic sites (on an SMP machine) does it make sense to have= a pool of servers? (if so, load-balancing enters in.) (appserver is already threaded, which is the best you can get for Python on a single-processor machine.) |
From: Chuck E. <ec...@mi...> - 2001-03-13 06:29:46
|
Just some quick notes on this topic that you've brought up: Perhaps the status of the app server (INITIALIZING, SERVING, SHUTTING DOWN,= =20 DEAD) can be contained in a "status.text" file that might also contain a=20 time stamp for that message. Also, the app server needs to kill=20 address.text after it shuts down, something that I still don't think it= does. -Chuck At 01:30 PM 3/12/2001 -0500, Terrel Shumway wrote: >"=3D?koi8-r?Q?=3DE1=CE=C4=D2=3DC5=CA?=3D" wrote: > > > Idea: > > > > Instead of usage OneShot adapters to start Monitor.py from Cgi or= FastCgi > > adapter - if > > It fails connection with AppServer. > >I was thinking about that myself. >I am working with a hosting provider that frowns on long-running processes. >I do not expect a lot of traffic, but it would be nice to start the >appserver when a visitor does come. "LazyStart" could > > if webware is running: > connect to it to handle the request (as WebKit.cgi currently does) > else: > fork and fire up appserver > run as OneShot in the parent process > >Hopefully appserver will be running by the time the next request comes in, >and the response will be that much faster. The running appserver could= also >kill itself after a specified idle time, to keep the hosting company happy. >(They have a cron job that does this anyway.) > >This idea could also be incorporated into mod_webkit for extra >robustness/flexibility. > >Issues: > How does the appserver signal when it is ready to serve? > How to avoid spawing several appservers if the first one takes a long >time to start? > How does appserver signal when it is shutting down (while finishing >already queued requests)? > For high-traffic sites (on an SMP machine) does it make sense to have= a >pool of servers? (if so, load-balancing enters in.) > (appserver is already threaded, which is the best you can get for >Python on a single-processor machine.) > > > >_______________________________________________ >Webware-discuss mailing list >Web...@li... >http://lists.sourceforge.net/lists/listinfo/webware-discuss |
From: <in...@as...> - 2001-03-13 11:54:31
|
> > Issues: > How does the appserver signal when it is ready to serve? > How to avoid spawing several appservers if the first one takes a > long > time to start? > How does appserver signal when it is shutting down (while finishing > already queued requests)? > For high-traffic sites (on an SMP machine) does it make sense to > have a > pool of servers? (if so, load-balancing enters in.) > (appserver is already threaded, which is the best you can get > for > Python on a single-processor machine.) It is possible to use the file "appserverpid.txt", but it(he) should be unset At completion of the server. And to fulfil check of real existence of the process with it pid. (Можно использовать файл "appserverpid.txt", но он должен обнуляться при завершении сервера. И выполнить проверку реального существования процесса с этим pid.) |
From: Peter A. <as...@fa...> - 2001-04-22 22:57:12
|
From: Aleksandar K. <kac...@ya...> - 2001-07-06 17:17:29
|
Hi All, Here is the setup that I have. I can not get WebKit to start appserver on my box. Any help appreciated. OpenBSD 2.8 GENERIC#399 i386 Python 2.1 [GCC 2.95.3 19991030 (prerelease)] on openbsd2 Webware-0.5.1rc3 When running python Launch.py AsyncThreadedHTTPServer I get stuck loading plugins: ------------snip -----------snip------------snip----------- WebKit AppServer 0.5.1 part of Webware for Python Copyright 1999-2000 by Chuck Esterbrook. All Rights Reserved. WebKit and Webware are open source. Please visit: http://webware.sourceforge.net Process id is 129 Host = 127.0.0.1 PlugInDirs = ['..'] PlugIns = [] Port = 8086 PrintConfigAtStartUp = 1 ServerThreads = 10 Verbose = 1 ActivityLogColumns = ['request.remoteAddress', 'request.method', 'request.uri', 'response.size', 'servlet.name', 'request.timeStamp', 'transaction.duration', 'transaction.errorOccurred'] ActivityLogFilename = /opt/Webware/Webware/WebKit/Logs/Activity.csv AdminPassword = webware CacheServletClasses = 1 CacheServletInstances = 1 Contexts = {'Examples': 'Examples', 'Testing': 'Testing', 'default': 'Examples', 'Docs': 'Docs', 'Admin': 'Admin'} Debug = {'Sessions': 0} DirectoryFile = ['index', 'Main'] DynamicSessionTimeout = 15 EmailErrors = 0 ErrorEmailHeaders = {'Subject': 'Error', 'Content-type': 'text/html', 'From': '-@-.com', 'Reply-to': '-@-.com', 'To': ['-@-.com']} ErrorEmailServer = mail.-.com ErrorLogFilename = /opt/Webware/Webware/WebKit/Logs/Errors.csv ErrorMessagesDir = /opt/Webware/Webware/WebKit/ErrorMsgs ExtensionsToIgnore = ['.pyc', '.pyo', '.py~', '.psp~', '.html~', '.bak'] ExtraPathInfo = 0 IgnoreInvalidSession = 0 LogActivity = 0 MaxDynamicMemorySessions = 10000 PrintConfigAtStartUp = 1 SaveErrorMessages = 1 SessionStore = Dynamic SessionTimeout = 60 ShowDebugInfoOnErrors = 1 UnknownFileTypes = {'ReuseServlets': 1, 'CacheContent': 1, 'Technique': 'serveContent', 'CheckDate': 1} UserErrorMessage = The site is having technical difficulties with this page. An error has been logged, and the problem will be fixed as soon as possible. Sorry! Loading context: Examples at /opt/Webware/Webware/WebKit/Examples Loading context: Testing at /opt/Webware/Webware/WebKit/Testing Loading context: default at /opt/Webware/Webware/WebKit/Examples Loading context: Docs at /opt/Webware/Webware/WebKit/Docs Loading context: Admin at /opt/Webware/Webware/WebKit/Admin Current directory: /opt/Webware/Webware Session Sweeper started Plug-ins list: /opt/Webware/Webware/COMKit, /opt/Webware/Webware/MiddleKit, /opt/Webware/Webware/MiscUtils, /opt/Webware/Webware/PSP, /opt/Webware/Webware/TaskKit, /opt/Webware/Webware/UserKit, /opt/Webware/Webware/WebUtils Loading plug-in: COMKit at /opt/Webware/Webware/COMKit Plug-in /opt/Webware/Webware/COMKit cannot be loaded because: Required op sys is ['nt'], but actual op sys is posix. Loading plug-in: MiddleKit at /opt/Webware/Webware/MiddleKit Loading context: MKBrowser at /opt/Webware/Webware/MiddleKit/WebBrowser Loading plug-in: MiscUtils at /opt/Webware/Webware/MiscUtils Loading plug-in: PSP at /opt/Webware/Webware/PSP --------snip--------snip--------------snip----------- Process is running (python) but no threads get spawn. thanks /s __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ |
From: <dr...@vg...> - 2001-08-16 02:48:24
|
DQo= |
From: Russell B. <rb...@at...> - 2001-10-01 18:07:22
|
I am trying to optimize my webkit servlets and I was browsing the webware admin pages. In the Servlet Cache by Path, I realized that I do not fully understand the following settings: created 1 (sometimes this is greater than 1) instances Queue: [] lock <lock object at 00CDC738> path C:\Inetpub\WebWare\WebKit\vcmr\select.psp reuseable 0 (sometimes this is one) threadsafe 0 (this is never one) timestamp 1001553935 Can anyone give me a quick explanation on what these settings are and how they affect the web servlets and performance? Additionally, does the performance increase with more threads for the App Server? Does the amount of threads have anything to do with the number of servlet paths (I have noticed that number at 11 when I only have 10 threads). Thanks for any help that can be provided. Russell A. Blank Senior Consultant Atlas Development Corporation 6351 Owensmouth Avenue, #101 Woodland Hills, CA 91367 (818) 340-7080 Phone (818) 340-7079 Fax "May all our hearts go out to the victims of the most recent act of war." |
From: Chuck E. <Chu...@ya...> - 2001-10-04 20:38:23
|
At 11:06 AM 10/1/2001 -0700, Russell Blank wrote: >I am trying to optimize my webkit servlets and I was browsing the webware Why are you specifically trying to optimize them? What kind of performance issue are you having? BTW My number one optimization technique is to cache any information my servlets compute that can be cached. That means either computing in __init__, or storing computations in self.attributes which then get used the second time around. >admin pages. In the Servlet Cache by Path, I realized that I do not fully >understand the following settings: >created 1 (sometimes this is greater than 1) >instances Queue: [] lock <lock object at 00CDC738> >path C:\Inetpub\WebWare\WebKit\vcmr\select.psp >reuseable 0 (sometimes this is one) >threadsafe 0 (this is never one) >timestamp 1001553935 > >Can anyone give me a quick explanation on what these settings are and how >they affect the web servlets and performance? The "settings" are really in WebKit/Application.config. What you are seeing here is a _data structure_ that the app server holds internally. This structure keeps instances of your servlets around so that requests can be responded to more quickly. I think its interesting that this PSPs reusable is set to 0. I wonder if that could be source of slow down. Can you tell me, are your PSPs always 0 for reusable? What about .py's? Are the Queues always empty? >Additionally, does the performance increase with more threads for the App >Server? Does the amount of threads have anything to do with the number of >servlet paths (I have noticed that number at 11 when I only have 10 >threads). The number of threads are determined in AppServer.config. The min is 5 and it grows to 20. If you are actually getting more than 20 _concurrent_ requests at a time, then you may experience a boost by increasing this number. That will depend on multiple factors probably including Webware, your op sys and your servlets. The best way would be to try it and see. Are you already getting more than 20 concurrent users at a time? -Chuck |
From: Ronald H. <ron...@qu...> - 2001-10-19 01:58:49
|
From: Ben P. <be...@th...> - 2001-10-20 01:53:34
|
I'm running Apache 1.3.19 and can't seem to get access to the HTTP_REFERER value. I know my browser is sending the Header, because I can pick it up in PHP, but it doesn't show in Webware or in a Perl CGI script dumping all ENV variables. Anybody ever run into this problem? Thanks, Ben |