[Spread-users] Daemons appear segmented even though network is not.

Rangoli Mathur Rangoli.Mathur at wnco.com
Mon Aug 13 13:46:44 EDT 2007


Hi.
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
segment.
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.

Regards,
Renee.
 

> -----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.
> 
> activemq.apache.org
> 
> 
> 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
> http://lists.spread.org/mailman/listinfo/spread-users
> 




More information about the Spread-users mailing list