Menu
▾
▴
naviserver-devel
|
From: Brett S. <bre...@ya...> - 2008-08-20 03:30:23
|
Wow, I am amazed at the different reactions to this issue between this list and the aolserver list. Makes me want to switch to naviserver even more now... ----- Original Message ---- From: Vlad Seryakov <vl...@cr...> To: nav...@li... Sent: Tuesday, August 19, 2008 5:12:44 PM Subject: Re: [naviserver-devel] Bug in fastpath cache causes info leak I agree with this assessment. Nobody's fault in particular but unfortunate circumstances. Still the fix is good and naviserver has fastpath cache disabled as oppose to aolserver. Stephen Deasey wrote: > fyi, there's talk of a bug in the fastpath cache on the aolserver > list. I agree with the reporter, John: it's totally busted. I > committed a fix last night, but if you're not on the commits list you > won't have seen it. Heads up. > > The fix was to lookup objects in the cache using the file name, as the > windows code did, and not use the two-stage file name to inode, inode > to object lookups. > > The only down side might be that if you have files known by more than > one name, eg symlinks, the cache will hold duplicates and be less > efficient. But that may not be a great idea anyway: with symlinks, > user-agents will use different URLs to request the same file, so HTTP > caching can't be used. > > Also, it seems to me that the problem has nothing to do with dynamic > content or temp files or the programmer doing anything wrong. You > could be unlucky with your timing and have random content appear > instead of the file you expected. For example, two programmers could > log in to one machine and edit two html documents live. If they happen > to save at the same time, and there happens to be requests for those > files which cause them to be cached, and the OS chooses to recycle > inodes unfavourably, then the contents of either of the files might > appear to be any other file that has previously been cached by > fastpath. Ouch. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ naviserver-devel mailing list nav...@li... https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Jeff R. <dv...@di...> - 2008-08-20 05:17:08
|
Brett Schwarz wrote: > Wow, I am amazed at the different reactions to this issue between > this list and the aolserver list. Makes me want to switch to > naviserver even more now... 90% of the difference is that the issue was introduced here by someone saying "I contributed a patch." That in itself gets a better reaction than hyperbole and insisting that everyone else doesn't know what they're talking about. On the flipside, some of the reactions were overly harsh and dismissive. BTW, the solution in the patch of adding the filename to the hash key was rejected by the OP. After all the discussion there, I am generally in agreement that there is no real problem other than insufficient documentation, caveats, and examples. But some options to make the cache less aggressive when necessary can be a good thing. Other than adding in the filename (which causes more memory to be used) a way to avoid the caching in the first place could be good; either a -nocache flag to ns_returnfile or a different command (to still get the performance of mmap-ing) or my other suggestion of skipping caching for files matching certain patterns (e.g., under a particular directory like /tmp, /var/tmp, or whatever) would avoid uselessly using up the cache memory in the first place. As far as the performance impact (of mmap or fastpath in the first place) numbers speak louder than speculation, and testing it isn't that hard. -J |
|
From: Vlad S. <vl...@cr...> - 2008-08-21 16:26:05
|
I think many issues or questions also are result of defaults in Aolserver and Naviserver still being set according to past AOL setup and requirements. It can be considered as an extreme case and because a lot of functionality was implemented for AOL high-performance requirements and setup, everybody else has to know that deeply, change config and/or know C code good enough to make knowledgeable decisions. For example, one of such things is threaded allocator which is default in Tcl, nowadays default allocators a good enough, return memory to the system, zippy is needed only in very high performance cases and even in such cases it needs carefull testing to make sure the application does not consume more and more different pieces of memory which will lead to even wore fragmentation. I always recompile Tcl with default memory allocator: it has 2 benefits, 1) not-ever-growing, 2) i can use vtmalloc easily for example if default one does not work like i need We know the code and we assume everybody else should and many questions and problems reported seem like dumb or idiotic but they are not in all cases. I think all functionality AOL developed is very valuable but enabling it by default is making everybody else to follow AOL's way of doing things with AS/NS. Jeff Rogers wrote: > Brett Schwarz wrote: >> Wow, I am amazed at the different reactions to this issue between >> this list and the aolserver list. Makes me want to switch to >> naviserver even more now... > > 90% of the difference is that the issue was introduced here by someone > saying "I contributed a patch." That in itself gets a better reaction > than hyperbole and insisting that everyone else doesn't know what > they're talking about. On the flipside, some of the reactions were > overly harsh and dismissive. > > BTW, the solution in the patch of adding the filename to the hash key > was rejected by the OP. > > After all the discussion there, I am generally in agreement that there > is no real problem other than insufficient documentation, caveats, and > examples. But some options to make the cache less aggressive when > necessary can be a good thing. Other than adding in the filename (which > causes more memory to be used) a way to avoid the caching in the first > place could be good; either a -nocache flag to ns_returnfile or a > different command (to still get the performance of mmap-ing) or my other > suggestion of skipping caching for files matching certain patterns > (e.g., under a particular directory like /tmp, /var/tmp, or whatever) > would avoid uselessly using up the cache memory in the first place. > > As far as the performance impact (of mmap or fastpath in the first > place) numbers speak louder than speculation, and testing it isn't that > hard. > > > -J > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Vasiljevic Z. <zv...@ar...> - 2008-08-21 18:49:41
|
On 21.08.2008, at 18:26, Vlad Seryakov wrote: > I always recompile Tcl with default memory > allocator: it has 2 benefits, 1) not-ever-growing, 2) i can use > vtmalloc > easily for example if default one does not work like i need yep. me too. |
|
From: Stephen D. <sd...@gm...> - 2008-08-21 19:06:27
|
On Thu, Aug 21, 2008 at 7:49 PM, Vasiljevic Zoran <zv...@ar...> wrote: > > On 21.08.2008, at 18:26, Vlad Seryakov wrote: > >> I always recompile Tcl with default memory >> allocator: it has 2 benefits, 1) not-ever-growing, 2) i can use >> vtmalloc >> easily for example if default one does not work like i need > > yep. me too. > You used to have to manually edit the makefile to disable zippy. Is this still the case? Perhaps the Tcl default should be to use the system allocator even on threaded builds, and to provide a configure switch to enable zippy. Zoran, you have Tcl cvs access right? |
|
From: Vlad S. <vl...@cr...> - 2008-08-22 02:34:10
|
> > You used to have to manually edit the makefile to disable zippy. Is > this still the case? > What i do i use sed to replace zippy define after i ran configure, there is no easy way to disable it currently |
|
From: Bernd E. <eid...@we...> - 2008-08-22 06:44:03
|
> > You used to have to manually edit the makefile to disable zippy. Is > > this still the case? > > What i do i use sed to replace zippy define after i ran configure, there > is no easy way to disable it currently Hi Vlad! Can you share the way you do it? Thanks! Bernd. |
|
From: Vlad S. <vl...@cr...> - 2008-08-22 14:58:47
|
I mainly use Archlinux so i created package file but basically i added just 2 lines to it and overall it looks like it: ./configure --prefix=/usr --enable-threads --disable-64bit sed -i -e 's/-DUSE_THREAD_ALLOC=1//g' tclConfig.sh sed -i -e 's/-DUSE_THREAD_ALLOC=1//g' Makefile make install Bernd Eidenschink wrote: >>> You used to have to manually edit the makefile to disable zippy. Is >>> this still the case? >> What i do i use sed to replace zippy define after i ran configure, there >> is no easy way to disable it currently > > Hi Vlad! > > Can you share the way you do it? Thanks! > > Bernd. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Bernd E. <eid...@we...> - 2008-08-22 15:28:32
|
Thanks! > ./configure --prefix=/usr --enable-threads --disable-64bit > > sed -i -e 's/-DUSE_THREAD_ALLOC=1//g' tclConfig.sh > sed -i -e 's/-DUSE_THREAD_ALLOC=1//g' Makefile |
|
From: Vasiljevic Z. <zv...@ar...> - 2008-08-28 20:52:31
|
On 21.08.2008, at 21:06, Stephen Deasey wrote: > You used to have to manually edit the makefile to disable zippy. Is > this still the case? > > Perhaps the Tcl default should be to use the system allocator even on > threaded builds, and to provide a configure switch to enable zippy. > Zoran, you have Tcl cvs access right? Yes. I just discussed this with Vlad. Here is the consensus: There is Tcl single-threaded allocator and zippy allocator. If you turn on Tcl allocator it should use single-threaded allocator for non-thread builds zippy allocator for thread builds If you turn off Tcl allocator it should use system-level malloc regardless of the thread/nonthread builds This is most "logical" setup. So, either you have custom Tcl memory allocator or not. If you dont, then system malloc is used. If you do, then it depends on the threaded build. To aid this, there is (confugure-wise unused) USE_TCLALLOC define. Control which (simple one-lock Tcl allocator or AOL's zippy allocator) is selected, is done over USE_THREAD_ALLOC. By allowing the USE_TCLALLOC to be confugured "from the outside" one can decide wether TCL allocator (singlethreaded or zippy) or system/OS malloc us used. The USE_THREAD_ALLOC is implicitly set (reset) when threaded build is configured (or not). This way we would have one "knob" (the USE_TCLALLOC) which we can toggle over --enable-tclalloc (default us true). By --disable-tclalloc we would default to system level alloc, thread build or not. This is the path of least resistence and would not change any defaults. I could go to the Tcl core list with this suggestion, yes. Vlad suggested to raise the queston of disabling the zippy even for thread builds, per default. I can only second that. But then again, we would change the default behaviour from as-is now and that is a chance to get some oposition which I do not have time to deal with. What do you think? |
|
From: Stephen D. <sd...@gm...> - 2008-08-28 21:05:59
|
On Thu, Aug 28, 2008 at 9:52 PM, Vasiljevic Zoran <zv...@ar...> wrote: > > On 21.08.2008, at 21:06, Stephen Deasey wrote: > >> You used to have to manually edit the makefile to disable zippy. Is >> this still the case? >> >> Perhaps the Tcl default should be to use the system allocator even on >> threaded builds, and to provide a configure switch to enable zippy. >> Zoran, you have Tcl cvs access right? > > Yes. I just discussed this with Vlad. > Here is the consensus: > > There is Tcl single-threaded allocator and zippy allocator. > > If you turn on Tcl allocator it should use > single-threaded allocator for non-thread builds > zippy allocator for thread builds > > If you turn off Tcl allocator it should use > system-level malloc regardless of the thread/nonthread builds > > This is most "logical" setup. So, either you have custom Tcl > memory allocator or not. If you dont, then system malloc is used. > If you do, then it depends on the threaded build. > > To aid this, there is (confugure-wise unused) USE_TCLALLOC define. > Control which (simple one-lock Tcl allocator or AOL's zippy allocator) > is selected, is done over USE_THREAD_ALLOC. > > By allowing the USE_TCLALLOC to be confugured "from the outside" > one can decide wether TCL allocator (singlethreaded or zippy) > or system/OS malloc us used. > > The USE_THREAD_ALLOC is implicitly set (reset) when threaded build > is configured (or not). > > This way we would have one "knob" (the USE_TCLALLOC) which we can > toggle over --enable-tclalloc (default us true). By --disable-tclalloc > we would default to system level alloc, thread build or not. > > This is the path of least resistence and would not change any defaults. > I could go to the Tcl core list with this suggestion, yes. > > Vlad suggested to raise the queston of disabling the zippy even for > thread builds, per default. I can only second that. But then again, > we would change the default behaviour from as-is now and that is a > chance to get some oposition which I do not have time to deal with. > > What do you think? Sounds sensible. Configuration knob first, change defaults later, possibly. To change the default is going to require proof that one way is better than another anyway. There's a Tcl performance test suite somewhere, right? Some work for somebody... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X