The phrase "all scripts" concerns me (unless you are talking about differing
languages).
If its Perl - then have you considered consolidated configuration in one
place - as in Singleton::Memcache ?
At least this resolves down to only one place to look for configuration
problems etc.
As to the original poster, depending on how you've initialised your Perl
memcached object - there are a number of possible problems that I've
recently observed....(as a memcached noob)
Some of these problems were my fault (failing to adequately read
*all*documentation), some not. All of these observations are anecdotal
and I
didn't apply complete rigour noting observations (i.e. your mileage may
vary).
Here are some examples:-
1. Not using Singleton::Memcached - thereby creating a
maintenance/management headache from the plethora of perl scripts I'd had to
code similar memcached initialisation config into.
2. Using Singleton::Memcached and...
a) typos in server addresses (didn't match actual server hosts)
b) definition of server addresses in memcached initialisation config -
but some of these server addresses were *not* running a memcached daemon
c) typos in other memcached initialisation code
3. Failing to appreciate/notice that set methods could return a result value
indicating whether the set was successful or not. (Only noticed this in the
Cache::Memcached::Fast documentation). Looking at the return code may help
you.
4. Failing to appreciate/notice that servers could be configured with a
noReply/noWait parameter (Again only noticed this in the
Cache::Memcached::Fast documentation).
5. Failing to appreciate/notice that its possible to instruct the Perl
memcached client to abort/abend if the initialisation configuration dataset
is deemed invalid (typos, poor structure, incorrect params). (Again - I only
noticed this in the Cache::Memcached::Fast documentation). This may be
useful to validate your initialisation parameter set.
I hope this helps.
Paul
