From: Geoffrey T. <gta...@na...> - 2003-07-28 20:08:56
|
Ian Bicking wrote: > On Mon, 2003-07-28 at 10:32, Aaron Held wrote: >> In the CVS version it looks like the the servlets are created for >> each request. > > I'm not sure if this was ever the behavior, though I always thought it > was too. ServletFactory.py:181 is where the caching is done. The > servlet *class* is cached, but the instances seem to be recreated > each time. > > Hmmm... maybe it used to be that caching was done in Application. I > didn't notice that, but there was such a bundle of code I may have > missed it, and then perhaps took that code out without noticing it. Yes, it was in Application. The cache (could also call it a pool) is just a list that starts out empty. When you want an instance you call list.pop() and if it raises an IndexError than you know all servlets are in use and you actually create a new instance. When done with the instance you use list.append() to return it to the pool. list.append() and list.pop() are atomic operations and therefore thread-safe with no need for locks. Note that this code used to use a non-blocking Queue instead of a list, but that caused a _very_ subtle timing-related bug. The list code is faster, and more importantly, works :-) Basically, Queues are not really reliable when used in non-blocking mode. I can dig up more information if anyone is interested. > > If caching wasn't done in the factory, I think it should be. I think > that just means we have to have a method to return the servlet to the > factory, and then the factory can keep a pool of servlets. I agree -- the caching belongs in the factory, not in Application. - Geoff |
From: <pau...@em...> - 2003-07-29 09:36:13
|
Geoffrey Talvola [mailto:gta...@na...] wrote: >=20 > Ian Bicking wrote: > >=20 > > If caching wasn't done in the factory, I think it should be. I = think > > that just means we have to have a method to return the servlet to = the > > factory, and then the factory can keep a pool of servlets. >=20 > I agree -- the caching belongs in the factory, not in Application. I know that this is "done and dusted" already, but I also think that = this is a great idea. You may have seen a patch I submitted which attempts to = allow Webware contexts to have "virtual resources" in much the same way that mod_python doesn't care what the requested resource is called as long as = the extension is the one mapped to the specified mod_python handler. My = patch does an inelegant workaround with respect to caching, and it also has to suppress the insistence that real files exist for every requested = resource - something which certainly is useful in many situations (eg. checking modified times against active servlets), but is obstructive or = unnecessary in other situations (eg. "virtual resources"). Especially in the light of the PyWeb stuff that Ian is particularly = involved with, I believe that generalising/simplifying/refactoring the caching = and servlet "discovery" code is important. Certainly, making Webware and mod_python's behaviour similar (and to the benefit of Webware) is a good thing. Anyway, Webware 0.9 (or 1.0?) is looking promising, especially if my = dodgy patches no longer need applying. Paul |
From: Ian B. <ia...@co...> - 2003-07-29 20:35:24
|
On Tue, 2003-07-29 at 04:36, pau...@em... wrote: > I know that this is "done and dusted" already, but I also think that this is > a great idea. You may have seen a patch I submitted which attempts to allow > Webware contexts to have "virtual resources" in much the same way that > mod_python doesn't care what the requested resource is called as long as the > extension is the one mapped to the specified mod_python handler. My patch > does an inelegant workaround with respect to caching, and it also has to > suppress the insistence that real files exist for every requested resource - > something which certainly is useful in many situations (eg. checking > modified times against active servlets), but is obstructive or unnecessary > in other situations (eg. "virtual resources"). This actually doesn't handle virtual resources. Unlike mod_python, URLParser adds the extension itself, so it has to have a filesystem to search. The assumption of a file is carried on into ServletFactory, at least into the caching that is performed. If you want to use virtual resources you'd have to put a sub-parser in the path somewhere (probably in an __init__.py file), like: class SubParser(URLParser): def __init__(self, rootObj): self.rootObj = rootObj def parse(self, trans, requestPath): # URLParser needs a helper function here... splitted = requestPath[1:].split('/', 1) first = splitted[0] if splitted[1:]: rest = '/' + splitted[1:] else: rest = '' # now we get to do interesting things... if first.startswith('_'): # More access controls are probably called for raise HTTPForbidden dest = getattr(self.rootObj, first) if rest: return SubParser(dest).parse(self, trans, rest) else: return dest Hmm... that's assuming you are traversing a bunch of threadsafe servlet-like objects, which is an unlikely scenario. The factory only comes in indirectly, by changing that last line -- in a more likely case you'd probably be wrapping the final object in a servlet class. Which is what a factory does... I don't know, it's not all thought out yet. Ian |
From: <pau...@em...> - 2003-07-30 11:01:57
|
Ian Bicking [mailto:ia...@co...] wrote: >=20 [My patch to Application with respect to virtual resources.] > This actually doesn't handle virtual resources. Unlike mod_python, > URLParser adds the extension itself, so it has to have a filesystem to > search. The assumption of a file is carried on into ServletFactory, = at > least into the caching that is performed. Perhaps I should really look at Webware CVS rather than Webware 0.8, = which is where my patch can be applied. Aside from the exact implementation, however, it seems that the URL = mapping issue is something which, as you probably noticed in the PyWeb = discussions, no-one can agree on very easily. The nice thing about mod_python's = mapping is that one just declares an extension (very similar to Webware servlet factories claiming extensions) and the handler picks up all resources = with such extensions. In effect, the Apache "Location" directive describes something = comparable to a Webware context and the "PythonHandler" directive (if that's what it's called) nominates something comparable to a servlet factory. What = Webware could do well to emulate here is the absence of any kind of direct = reference to on-the-filesystem servlet resources until the servlet factory (cf. mod_python handler) is in control and can decide whether the requested resources really do map to physical resources. Add in the simplicity of specifying all this in mod_python (and I don't believe Webware is far = off from this as it is) and Webware gains both new capabilities and = increased compatibility (at least conceptually) with mod_python. Paul |
From: Chuck E. <Chu...@ya...> - 2003-07-29 03:16:40
|
On Mon, 28 Jul 2003 15:34:04 -0400, Geoffrey Talvola wrote: >>=A0If caching wasn't done in the factory, I think it should be. =A0I >>=A0think =A0that just means we have to have a method to return the >>=A0servlet to the =A0factory, and then the factory can keep a pool of >>=A0servlets. >> >=A0I agree -- the caching belongs in the factory, not in Application. I believe I originally put it in the Application so that each servlet= factory would not have to reinvent caching. For example, I often add a servlet factory for HTML fragment files (.htmlf).= Do I now I have to reimplement/copy the code for caching of servlets in= this factory? Or can I inherit it from some MixIn util class? I didn't make the change from the original approach so I'm not familiar with= it. I still prefer caching to be implemented and enabled by default for all= servlet factories. Feedback? -Chuck -- http://ChuckEsterbrook.com/ |
From: Ian B. <ia...@co...> - 2003-07-29 03:53:03
|
On Mon, 2003-07-28 at 22:17, Chuck Esterbrook wrote: > On Mon, 28 Jul 2003 15:34:04 -0400, Geoffrey Talvola wrote: > >> If caching wasn't done in the factory, I think it should be. I > >> think that just means we have to have a method to return the > >> servlet to the factory, and then the factory can keep a pool of > >> servlets. > >> > > I agree -- the caching belongs in the factory, not in Application. > > I believe I originally put it in the Application so that each servlet > factory would not have to reinvent caching. > > For example, I often add a servlet factory for HTML fragment files > (.htmlf). Do I now I have to reimplement/copy the code for caching of > servlets in this factory? Or can I inherit it from some MixIn util > class? > > I didn't make the change from the original approach so I'm not > familiar with it. I still prefer caching to be implemented and enabled > by default for all servlet factories. Well, I was just about to check in some changes, but that's not the final word or anything. Really, if caching will be generally implemented I think it still belongs in servlet factories. I think the right way to do that would be to move some of what I've put in PythonServletFactory into ServletFactory, and use a different method in subclasses (something besides servletForTransaction). Maybe something similar to the new PythonServletFactory.loadClass, cleaned up a little. I'll check in a second version that's structured like that. Ian |
From: Ian B. <ia...@co...> - 2003-07-29 04:34:17
|
On Mon, 2003-07-28 at 22:54, Ian Bicking wrote: > Really, if caching will be generally implemented I think it still > belongs in servlet factories. I think the right way to do that would be > to move some of what I've put in PythonServletFactory into > ServletFactory, and use a different method in subclasses (something > besides servletForTransaction). Maybe something similar to the new > PythonServletFactory.loadClass, cleaned up a little. Alrighty, it's generalized a bit, and PSPServletFactory uses that caching as well. Should make servlet factories much quicker to implement. Ian |
From: Chuck E. <Chu...@ya...> - 2003-07-29 05:10:15
|
On 28 Jul 2003 23:35:39 -0500, Ian Bicking wrote: >=A0On Mon, 2003-07-28 at 22:54, Ian Bicking wrote: > >>=A0Really, if caching will be generally implemented I think it still >>=A0belongs in servlet factories. =A0I think the right way to do that >>=A0would be to move some of what I've put in PythonServletFactory >>=A0into ServletFactory, and use a different method in subclasses >>=A0(something besides servletForTransaction). =A0Maybe something >>=A0similar to the new PythonServletFactory.loadClass, cleaned up a >>=A0little. >> >=A0Alrighty, it's generalized a bit, and PSPServletFactory uses that >=A0caching as well. =A0Should make servlet factories much quicker to >=A0implement. Thanks. -Chuck -- http://ChuckEsterbrook.com/ |