andreas.dembach at kopernikus.de
Thu Dec 14 09:13:02 EST 2000
Yair Amir wrote:
> Seems to me your process had many messages waiting for it, it did not read from Spread, and Spread disconnected it.
> A few notes:
> 1. In Spread, processes that multicast to group but don't want to read messages sent to the group, should not join that group. They can still multicast to it.
> 2. If you have a process that receives messages from Spread, it should read them. Spread buffer messages for the process but only to an extent (Spread is not a disk). After that, it deems the process not responsive and closes the connection - which what seems to be happening. The default is to keep 1000 messages beyond what the socket buffer holds, as far as I remember.
> 3. The safe service is a strong service. You probably don't need it. The implication of using Safe will be paying more latency. But long term throughput will be the same. In any way, Safe will be no different than other services with respect to your problem.
> A question: Can you tell us what you are using Spread for?
As I said:
> > I want to use Spread to send cache expiry messages to a bunch of machines. These
> > messages are quite short char strings (actually the object id's).
The setup is like this:
We have a database server and several frontend servers running Apache/mod_perl/Mason.
We are using a self-written "java-style" PERL-class framework as a persistence layer between the frontends and the database.
Every frontend machine has a shared memory area (implemented with IPC::MM) which is accessed by the apache-processes to cache PERL objects retrieved from the database. Now when a process modifies an object, it has to be thrown out of the cache on every machine. That's where spread comes into play: a row lock is set on the object's record in the db, the object id is sent to
every machine in the spread multicast group (what happens, if a machine cannot be reached?), the update is written to the db and the lock released.
Before any cache lookups take place on any server, the cache class calls a "validate()" method to poll for ids to invalidate.
So that's why a process reads _and_ writes to Spread - but the read takes place asynchronously.
We are using spread with mod_log_spread anyway - so we don't have to install any more additional cpan-modules.
More information about the Spread-users