[Spread-users] Daemons appear segmented even though network is not.
Rangoli.Mathur at wnco.com
Mon Aug 13 13:46:44 EDT 2007
I am using Spread 4.0 and notice something strange in the behavior.
I have 1 daemon each on hosts 1 through 8. Each daemon is in its own
I am using spuser to connect to certain daemons, and notice that,
Daemons on host 1,2,4,5,6 are in 1 network group, while Daemons on host
3,7,8 appear to be on a different group. Messages from 1 group are not
seen in the other group. My initial thought was it may be a network
issue. But using traceroute, all hosts are actually reachable from each
other. Distance between host 3 and host 4 is actually just 1 hop.
Spmonitor shows the details of daemon on each of the 8 hosts.
But using spuser or spflooder while connected on a daemon in group1,
messages don't show up the spuser on group2.
I was wondering if anyone has seen this kind of behavior, and if so,
what I could possibly do in this case..
Any help would be greatly appreciated.
> -----Original Message-----
> From: spread-users-bounces at lists.spread.org
> [mailto:spread-users-bounces at lists.spread.org] On Behalf Of
> Theo Schlossnagle
> Sent: Thursday, August 09, 2007 7:58 AM
> To: Colin Meyer
> Cc: spread-users at lists.spread.org; Theo Schlossnagle; Daniel
> F. Savarese
> Subject: Re: [Spread-users] Spread for HA rpc services
> You might want to take a look at ActiveMQ.
> Actively developed, production ready (widely deployed)
> message broker providing (among other things) durable message
> queues with safe competing consumer semantics. Very very
> fast with a lot of other features.
> On Aug 9, 2007, at 2:46 AM, Colin Meyer wrote:
> > On Wed, Aug 08, 2007 at 05:26:36PM -0400, Daniel F. Savarese wrote:
> >> Since Colin's questions have already been answered, I just want to
> >> touch on Colin's original description of wanting the
> "first available
> >> server" to process a request. The approaches described amount to
> >> round-robin load balancing, which may or may not achieve the same
> >> effect depending on your application.
> > Agreed. Van's suggestion of hashing the input would would
> perhaps lead
> > to a better distribution of jobs than round robin.
> >> That's why I said there are
> >> a number of different ways to go about it (exact answers
> are always
> >> application-specific). If the time to process a request is not a
> >> constant, either because of heterogeneous hardware or
> because of the
> >> nature of the processing, you run the risk of underusing
> or starving
> >> your fast workers and piling up unprocessed requests for your slow
> >> workers.
> > In my case the hardware will be homogenous, and the jobs will
> > typically be well within an order of magnitude of each
> other (with the
> > bulk of them being nearly identical in difficulty).
> > I suppose that one approach could be for a given server to remove
> > itself from the queue, while it was feeling overworked.
> > -Colin.
> > _______________________________________________
> > Spread-users mailing list
> > Spread-users at lists.spread.org
> > http://lists.spread.org/mailman/listinfo/spread-users
> // Theo Schlossnagle
> // Principal at OmniTI: http://omniti.com
> // Esoteric Curio: http://www.lethargy.org/~jesus/
> Spread-users mailing list
> Spread-users at lists.spread.org
More information about the Spread-users