Dear Maksym,
On 24.08.21 02:39, Maksym Zinchenko wrote:
But lately, user logs in start working and randomly redirected back to
the login screen because data in db is not the same as in cache,
when you have values from the DB cached, then whenever the DB changes,
you have to flush the cache v
Hello, I have some question about ns_cache. Im creating cache with
command: ns_cache_create -timeout 1800 -expires 1800 max 5MB When I do
ns_cache_exists max right away, it shows 1 If i wait a little bit, lets say
5 min, not 30 min as difined (1800 are seconds right?) it shows 0, cache
doesnt exis
On 1/20/07, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
Am 19.01.2007 um 17:38 schrieb Stephen Deasey:
> For Tcl, add a new switch to ns_cache_create, -expireflush (or
> whatever). Keep the -expire and -expireflush times distinct. Tcl
> caches live forever IIRC so that's all there is to it, n
Am 19.01.2007 um 17:38 schrieb Stephen Deasey:
I don't think it's 100% accurate to say memory just bloats and bloats!
All caches have an upper bound. A 10MB cache will not grow beyond
10MB.
Yes. It is not 100% accurate.
Looks like you have a different situation though. Your cache is si
On 1/19/07, Jeff Rogers <[EMAIL PROTECTED]> wrote:
A second situation is where there is an expired entry and multiple
threads access it at the same time. It is probably handled as above, as
if there was no entry. But it might be desirable in certain situations
to return a stale entry immediate
On 1/19/07, Jeff Rogers <[EMAIL PROTECTED]> wrote:
Stephen Deasey wrote:
> Hit rate is not necessarily the best measure of effectiveness. Perhaps
> it's more expensive to fill one cache than it is to fill another? A
> single, shared LRU seemed like the simplest solution. Ideas
> appreciated.
Stephen Deasey wrote:
Hit rate is not necessarily the best measure of effectiveness. Perhaps
it's more expensive to fill one cache than it is to fill another? A
single, shared LRU seemed like the simplest solution. Ideas
appreciated.
What if 'ns_cache eval' stored with the cached value an es
On 1/19/07, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
Hi!
I have observed a ns_cache behaviour that I'd like to change.
In ns_cache, it is possible to create timestamped elements
that would expire after some time. But, they will never
expire on their own. If you fill the cache with thousands
You can make it similar to DB driver where each pool has its own
schedule proc for periodic checks
Ns_ScheduleProc(CheckPool, poolPtr, 0,
Ns_ConfigIntRange(path, "checkinterval", 600, 0,
INT_MAX));
Zoran Vasiljevic wrote:
Hi!
I have observed a ns_cache behaviour that I'd
Hi!
I have observed a ns_cache behaviour that I'd like to change.
In ns_cache, it is possible to create timestamped elements
that would expire after some time. But, they will never
expire on their own. If you fill the cache with thousands
of elements and never visit any of those any more, they w
On 7/10/06, Zoran Vasiljevic <[EMAIL PROTECTED]> 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.
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
On 7/10/06, Rick Cobb <[EMAIL PROTECTED]> 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 t
n 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Stephen Deasey
Sent: Saturday, July 08, 2006 3:05 PM
To: navi
On 6/29/06, Zoran Vasiljevic <[EMAIL PROTECTED]> 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
On 6/28/06, Vlad Seryakov <[EMAIL PROTECTED]> 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
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 ti
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 rela
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 t
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 be
On 6/27/06, Zoran Vasiljevic <[EMAIL PROTECTED]> 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 sa
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
On 6/27/06, Zoran Vasiljevic <[EMAIL PROTECTED]> 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 comm
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 secon
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
Yes, dynamic caches are very useful, i checked my code and i use them as
well
Zoran Vasiljevic wrote:
Am 22.10.2005 um 15:51 schrieb Stephen Deasey:
On 10/22/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
Am 21.10.2005 um 15:19 schrieb Vlad Seryakov:
Looks okay, API has changed but if
Am 22.10.2005 um 15:51 schrieb Stephen Deasey:
On 10/22/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
Am 21.10.2005 um 15:19 schrieb Vlad Seryakov:
Looks okay, API has changed but if we accept it, i suppose onetime
code change is acceptable
What about timed cache? I miss this (for us
On 10/22/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 21.10.2005 um 15:19 schrieb Vlad Seryakov:
>
> > Looks okay, API has changed but if we accept it, i suppose onetime
> > code change is acceptable
> >
>
> What about timed cache? I miss this (for us) important feature.
The existing im
Am 21.10.2005 um 15:19 schrieb Vlad Seryakov:
Looks okay, API has changed but if we accept it, i suppose onetime
code change is acceptable
What about timed cache? I miss this (for us) important feature.
Why passing the cacheTable over ClientData?
Why not creating caches during server lifeti
Looks okay, API has changed but if we accept it, i suppose onetime code
change is acceptable
Stephen Deasey wrote:
On 10/19/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
Stephen,
How is this going? Did you have any time to do some
work on your improvements to the caching code?
I did, b
On 10/19/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
> Stephen,
>
> How is this going? Did you have any time to do some
> work on your improvements to the caching code?
I did, but still didn't finish :-(
I've uploaded a tarball. It builds and installs as a module so you
don't have to patch
Stephen,
How is this going? Did you have any time to do some
work on your improvements to the caching code?
Cheers
Zoran
FYI:
See the stand-alone nscache module. I have NO idea why this isn't
part
of the AOLserver core ... unless folks really object, I think we
should
fold the nscache module in.
Agreed -- I'll add it in. In particular, "ns_cache eval" is smart.
This is from the AS mailing list: seems that
33 matches
Mail list logo
