Menu
▾
▴
naviserver-devel
|
From: Zoran V. <zv...@ar...> - 2006-06-27 11:34:09
|
Hi ! I got the same report from customers: timeout waiting for update: 59331.0.n.childs We never use anything except ns_cache_create, ns_cache_flush and ns_cache_eval commands. This kind of error was happening much more often before and I have tried to fix that bug some days ago. Aparently I found out that due to the bug in cache.c, we always have expired the cached entry and the ns_cache_eval was just re-caching it all the time. This obviously exposed the problem more often than now, as this bug is fixed. But, the "real" bug is still lurking there. This means that if you do not use timed caches, your program might get stucked in the cache code forever. Again: this might not happen to you in million years but it can happen the very next millisecond... I cannot get any decent test to expose this bug, as this is obviously some race condition in the code. I hope to be able to get that working today, by reading the code and trying to understand what it does. Please excuse me if I do some "non-optimal" changes to get it working properly. At the moment, the correct operation is paramount to us whereas speed/performance is not. Cheers, Zoran |
|
From: Zoran V. <zv...@ar...> - 2006-06-27 12:16:27
|
Am 27.06.2006 um 13:33 schrieb Zoran Vasiljevic: > Hi ! > > I got the same report from customers: > > timeout waiting for update: 59331.0.n.childs > > We never use anything except ns_cache_create, ns_cache_flush > and ns_cache_eval commands. This might be if the default value of cacheTimeout of 3 seconds is simply too low for the operation of caching the element in ns_cache_eval. I believe that this default value is too low. I have instructed the customer to increase the value from 3 to 60 secnds and observe the operation. At the same time I'm analyzing the code once more... Soon I will know everything by heart.. Cheers, Zoran |
|
From: Zoran V. <zv...@ar...> - 2006-06-28 17:17:28
|
Am 27.06.2006 um 14:16 schrieb Zoran Vasiljevic: > This might be if the default value of cacheTimeout of 3 seconds > is simply too low for the operation of caching the element in > ns_cache_eval. I think that this was the problem. So after increasing from 3 to 60 secs, the problems went away. I believe we will have to find some consensus about what and how we expect this cache stuff to work. For me, I'm OK with everything, as long as it computes! Stephen, you are the major moving force behind this module. Can you get us the direction you'd like to follow and let us see how we can go there? Cheers Zoran |
|
From: Vlad S. <vl...@cr...> - 2006-06-28 18:23:51
|
> I believe we will have to find some consensus about what and how > we expect this cache stuff to work. > > For me, I'm OK with everything, as long as it computes! > Stephen, you are the major moving force behind this module. > Can you get us the direction you'd like to follow and let > us see how we can go there? And i would like to add that i need this cache implementation includes per-cache timeouts and exists command (i can live with ns_cache_eval -force) -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Stephen D. <sd...@gm...> - 2006-06-27 16:15:03
|
On 6/27/06, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 27.06.2006 um 13:33 schrieb Zoran Vasiljevic:
>
> > Hi !
> >
> > I got the same report from customers:
> >
> > timeout waiting for update: 59331.0.n.childs
> >
> > We never use anything except ns_cache_create, ns_cache_flush
> > and ns_cache_eval commands.
>
> This might be if the default value of cacheTimeout of 3 seconds
> is simply too low for the operation of caching the element in
> ns_cache_eval. I believe that this default value is too low.
> I have instructed the customer to increase the value from 3 to
> 60 secnds and observe the operation. At the same time I'm analyzing
> the code once more... Soon I will know everything by heart..
There's no default timeout in the current code, and the error message should be:
timeout waiting for concurent update: ...
Make sure you're testing code from HEAD.
|
|
From: Zoran V. <zv...@ar...> - 2006-06-27 16:20:49
|
Am 27.06.2006 um 18:15 schrieb Stephen Deasey: > > There's no default timeout in the current code, and the error > message should be: > > timeout waiting for concurent update: ... > > Make sure you're testing code from HEAD. Easier said than done. The HEAD is not usable for testing as the code we have on the customer site is dated prior to your recent changes to ns_cache. Hence I must look in the code before that and try to understand if there is still something wrong OR the timeout of 3 seconds is just to low. We will have to maintain a separate internal branch until all this noise on ns_cache settles down and we are again all confident that it works as wanted/expected. Recent changes made it incompatible with the rest of the code and we can't make changes there for some time. Cheers, Zoran |
|
From: Stephen D. <sd...@gm...> - 2006-06-27 16:52:24
|
On 6/27/06, Zoran Vasiljevic <zv...@ar...> wrote: > > Am 27.06.2006 um 18:15 schrieb Stephen Deasey: > > > > > There's no default timeout in the current code, and the error > > message should be: > > > > timeout waiting for concurent update: ... > > > > Make sure you're testing code from HEAD. > > Easier said than done. The HEAD is not usable for testing > as the code we have on the customer site is dated prior to > your recent changes to ns_cache. Hence I must look in the > code before that and try to understand if there is still > something wrong OR the timeout of 3 seconds is just to low. > > We will have to maintain a separate internal branch until > all this noise on ns_cache settles down and we are again > all confident that it works as wanted/expected. Recent > changes made it incompatible with the rest of the code and > we can't make changes there for some time. > OK. Just checking. |
|
From: Vlad S. <vl...@cr...> - 2006-06-28 18:35:04
|
I also have question what is the meaning of changing -ttl relativeSeconds into -expires absolutetime. Now Tcl code looks bloated with all -expires [expr [ns_time]+3600] lines not counting that this is much slower than doing such incrementing C. May be we can keep both parameters, -ttl as relative and -expires as absolute? Zoran Vasiljevic wrote: > Am 27.06.2006 um 14:16 schrieb Zoran Vasiljevic: > >> This might be if the default value of cacheTimeout of 3 seconds >> is simply too low for the operation of caching the element in >> ns_cache_eval. > > I think that this was the problem. So after increasing from 3 to 60 > secs, the problems went away. > > I believe we will have to find some consensus about what and how > we expect this cache stuff to work. > > For me, I'm OK with everything, as long as it computes! > Stephen, you are the major moving force behind this module. > Can you get us the direction you'd like to follow and let > us see how we can go there? > > Cheers > Zoran > > 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 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Stephen D. <sd...@gm...> - 2006-07-08 22:04:54
|
On 6/28/06, Vlad Seryakov <vl...@cr...> wrote: > I also have question what is the meaning of changing -ttl > relativeSeconds into -expires absolutetime. > > Now Tcl code looks bloated with all -expires [expr [ns_time]+3600] lines > not counting that this is much slower than doing such incrementing C. > > May be we can keep both parameters, -ttl as relative and -expires as > absolute? > I changed it to make -timeout and -expiry regular. But you're right, it's ugly when you just want to specify an offset from now such as +3 seconds. I've changed it in CVS so that small -timeout and -expiry times are treated as offsets from now, and large values are treated as absolute times in the future. |
|
From: Rick C. <rc...@Kn...> - 2006-07-10 15:28:49
|
We do something fairly strange on our commands that might be useful here. We treat the string argument for a duration or timer as having 3 potential signs: "-", "+", and "@". Dash and plus *always* mean relative-to-now. @ always means absolute time. Any given option or argument documents whether its *default sign* is -,+, or @. For expirations, we usually say that the default is "+". So "-expiry 5" is 5 seconds from now, while "-expiry @5" expired a long time ago. And it makes parsing a timer or duration a standard operation throughout our code. Unfortunately, it's in our C++ stuff, so not really suitable for the Naviserver core. Hope this helps -- -- ReC -----Original Message----- From: nav...@li... [mailto:nav...@li...] On Behalf Of Stephen Deasey Sent: Saturday, July 08, 2006 3:05 PM To: nav...@li... Subject: Re: [naviserver-devel] ns_cache is still broken On 6/28/06, Vlad Seryakov <vl...@cr...> wrote: > I also have question what is the meaning of changing -ttl > relativeSeconds into -expires absolutetime. > > Now Tcl code looks bloated with all -expires [expr [ns_time]+3600] lines > not counting that this is much slower than doing such incrementing C. > > May be we can keep both parameters, -ttl as relative and -expires as > absolute? > I changed it to make -timeout and -expiry regular. But you're right, it's ugly when you just want to specify an offset from now such as +3 seconds. I've changed it in CVS so that small -timeout and -expiry times are treated as offsets from now, and large values are treated as absolute times in the future. ------------------------------------------------------------------------ - 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=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ naviserver-devel mailing list nav...@li... https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Stephen D. <sd...@gm...> - 2006-07-10 18:34:04
|
On 7/10/06, Rick Cobb <rc...@kn...> wrote: > We do something fairly strange on our commands that might be useful > here. We treat the string argument for a duration or timer as having 3 > potential signs: "-", "+", and "@". Dash and plus *always* mean > relative-to-now. @ always means absolute time. > > Any given option or argument documents whether its *default sign* is > -,+, or @. For expirations, we usually say that the default is "+". So > "-expiry 5" is 5 seconds from now, while "-expiry @5" expired a long > time ago. > > And it makes parsing a timer or duration a standard operation throughout > our code. Unfortunately, it's in our C++ stuff, so not really suitable > for the Naviserver core. > > Hope this helps -- > -- ReC Yeah, I was wondering about this. Using straight numbers the underlying Tcl obj has it's internal rep shimmered to Long or Ns_Time, which seems like an advantage. What swung it for me was the recent roll over of Unix time to an extra digit. Trying to add a number that large to the current time is clearly an error as the time will overflow, so that seemed like a good place to put the cutoff point. Maybe the signs are more readable in code? I'm hoping you wont have to manually set this much. Limits will save the day, and cure world hunger... |
|
From: Zoran V. <zv...@ar...> - 2006-07-10 21:04:42
|
Am 10.07.2006 um 20:34 schrieb Stephen Deasey: > Limits will save the day, and cure world > hunger... ... and win the next world football cup in South Africa in four years :-) Cheers, Zoran |
|
From: Stephen D. <sd...@gm...> - 2006-07-11 16:16:54
|
On 7/10/06, Zoran Vasiljevic <zv...@ar...> wrote: > > Am 10.07.2006 um 20:34 schrieb Stephen Deasey: > > > Limits will save the day, and cure world > > hunger... > > ... and win the next world football cup in South Africa > in four years :-) > ...unless it comes to penalties. |
|
From: Zoran V. <zv...@ar...> - 2006-06-29 20:36:42
|
Am 27.06.2006 um 18:52 schrieb Stephen Deasey: > > OK. Just checking. > According to our customer, the increase from 3 to 60 secs did the trick. Now we get no timeouts any more. So, the fix I did was OK and the default timeout should be increased If somebody asks me. But as Stephen says, the timeout is removed from the last checkin which leads =FAs to: WHERE? I believe we should slowly start defining what and how we are going to handle this (cache) params so we can slowly move on. Cheers, Zoran= |
|
From: Stephen D. <sd...@gm...> - 2006-07-08 22:06:55
|
On 6/29/06, Zoran Vasiljevic <zv...@ar...> wrote: > > Am 27.06.2006 um 18:52 schrieb Stephen Deasey: > > > > > OK. Just checking. > > > > According to our customer, the increase from 3 to 60 secs > did the trick. Now we get no timeouts any more. So, the fix > I did was OK and the default timeout should be increased > If somebody asks me. > > But as Stephen says, the timeout is removed from the last > checkin which leads =FAs to: WHERE? > Limits! When the limits are added, that will be the way to set timeout defaults for all API calls such as caches, db handles, http get etc. You can now set per-cache defaults manually when you first create them. |
×
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