Skip Menu |

This queue is for tickets about the Cache-Cache CPAN distribution.

Report information
The Basics
Id: 6076
Status: rejected
Priority: 0/
Queue: Cache-Cache

People
Owner: dewitt [...] unto.net
Requestors: thomas.acunzo [...] ubs.com
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: (no value)
Fixed in: (no value)



Subject: Cache::SharedMemoryCache fails when more than one instance runs on the same server
"[Thu Apr 15 17:35:06 2004] [error] Can't call method "fetch" on an undefined value at .../cpan/5.8.0-2003.05/lib/Cache/SharedMemoryBackend.pm line 98." Hi If you start seeing this type of error and your application was running fine until this point, it could mean that another process chain is also using the Cache::SharedMemoryCache module on the same machine. I'm unsure as what is causing this error but I bet it has something to do with the Locking of IPC::ShareLite. Note: using a separate namespace does not help getting through the problem. Switching to FileCache will help as a work around. The test program given below will traps errors to avoid getting the generic 'Internal Server' message. The result should be that the system time is cache upon the first http request (Apache Pid). All other http requests (Apache Pids) should also see this number. After 5 minutes has past the cache will clear itself and a new time will be cached for all pids until the next rotation. Load the sample once to see how it works normally. Load a second apache instance with the same code and see the error messages. Use netscape browser with <shift> <click 'reload'>. # Apache 1.3.27 conf (requires mod-perl) # include lib path in your @INC PerlModule testShareMemCache <Location /test> SetHandler perl-script PerlHandler testShareMemCache </Location> # file testShareMemCache.pm package testShareMemCache; use lib qw(../cpan/5.8.0-2003.05/lib); use Cache::SharedMemoryCache; my $cache = new Cache::SharedMemoryCache; Apache->server->register_cleanup(sub {$cache->clear;}); my $pid = $$; sub handler { my $r = shift; my $time = eval{$cache->get('TiMeStAmP')}; if (!$time) { $time = time; eval{$cache->set('TiMeStAmP',$time,'5 min')}; } print '<html><head> <title>Testing Cache::SharedMemoryCache</title> </head><body>', "Parent pid: $pid <h3>System Clock: $time Apache Pid: $$</h3> $@</body></html>"; return OK; } 1; I was running on Perl 5.8.0 mod-perl 1.27 for apache 1.3.27 on Solaris 5.8 IPC::ShareLite v0.09 Cache::Cache v1.40 Cache::SharedMemoryCache v1.23 Cache::SharedMemoryBackend v1.7 If I could make a suggestion: The problem may turn out to be a module dependency (IPC). It would better help the developer if the external error was trapped, like using an eval block or testing $p_ipc_identifier for a null value. From error block SharedMemoryBackend: sub _Restore_Shared_Hash_Ref { my ( $p_ipc_identifier ) = Static_Params( @_ ); Assert_Defined( $p_ipc_identifier ); my $frozen_hash_ref = _Instantiate_Share( $p_ipc_identifier )->fetch( ) or return { }; return Thaw_Data( $frozen_hash_ref ); } If this turns out to be some platform limitation, please make a note of this in the perldocs. Regards Tom Acunzo Ubs Investment Bank (IMS Perot Systems)
Good bug report. Accepting the bug, and will comment on it shortly.
A few thoughts on this, then I am going to close the ticket. 1) My official answer these days is to use FileCache instead of SharedMemoryCache. The reasons are many. First, FileCache provides equal or better performance in all cases that I've been able to test. (This is due to all modern OS's ability to buffer and cache file system accesses very well.) Second, FileCache has no real limits on cached object size or the number of cached objects, whereas the SharedMemoryCache has limits, and rather low ones at that. Third, FileCache works well on every OS, wherease the SharedMemoryCache works only on systems that support IPC::ShareLite. And IPC::ShareLite is an impressive effort -- but think about how hard it is to get shared memory working properly on *one* system. Now imagine writing a wrapper around SM for many operating systems. So the point of that is use FileCache instead. You won't regret it. 2) There were a few places in SharedMemoryBackend that I could do some error checking, so I added that to the library. I'm not sure if it will actually report what's going on (because, as you described, the issues lie in the IPC::ShareLite layer), but it is a start. This has been checked into the CVS version -- please visit the perl-cache page on Sourceforge if you need this update ASAP. 3) I'm adding a comment to SharedMemoryCache to recommend using FileCache instead. I'd remove SMC altogether, but I don't want to break anyone's code. Thanks again!
Very Cool! Thank you for your prompt response. [DCLINTON - Sat Apr 24 11:41:59 2004]: Show quoted text
> A few thoughts on this, then I am going to close the ticket. > > 1) My official answer these days is to use FileCache instead of > SharedMemoryCache. The reasons are many. First, FileCache provides > equal or better performance in all cases that I've been able to test. > (This is due to all modern OS's ability to buffer and cache file > system > accesses very well.) Second, FileCache has no real limits on cached > object size or the number of cached objects, whereas the > SharedMemoryCache has limits, and rather low ones at that. Third, > FileCache works well on every OS, wherease the SharedMemoryCache works > only on systems that support IPC::ShareLite. And IPC::ShareLite is an > impressive effort -- but think about how hard it is to get shared > memory > working properly on *one* system. Now imagine writing a wrapper > around > SM for many operating systems. > > So the point of that is use FileCache instead. You won't regret it. > > 2) There were a few places in SharedMemoryBackend that I could do some > error checking, so I added that to the library. I'm not sure if it > will > actually report what's going on (because, as you described, the issues > lie in the IPC::ShareLite layer), but it is a start. This has been > checked into the CVS version -- please visit the perl-cache page on > Sourceforge if you need this update ASAP. > > 3) I'm adding a comment to SharedMemoryCache to recommend using > FileCache instead. I'd remove SMC altogether, but I don't want to > break > anyone's code. > > Thanks again! >
[guest - Mon Apr 26 12:53:58 2004]: PLEASE CLOSE. Didn't mean to reopen this chain sorry. Show quoted text
> > Very Cool! > Thank you for your prompt response. > >