[Spread-users] Spread daemon crashing

[Jonathan Stanton]

Hi Rick,

On Thu, Feb 14, 2008 at 10:34:52AM -0800, Rick Cobb wrote:
> Jonathan Stanton wrote:
> > Increaseing the size of private names is also something people have used in the past, but 
> > I've had fewer reports of success. 
> 
> We've configured our spread installations (we have a couple dozen) using:
> #define MAX_GROUP_NAME		(1+MAX_PRIVATE_NAME+1+MAX_PROC_NAME)
> #define MAX_PRIVATE_NAME        30 /* largest possible size of private_name field of SP_connect() */
> #define MAX_PROC_NAME           100 /* largest possible size of process name of daemon */
> 
> for quite some time (3.17.3, about 3 years in several dozen QA & production deployments). 
> 
> We've recently expanded this (only a month, 4.0.0, only in small QA configurations) to:
> #define MAX_PRIVATE_NAME        128 
> #define MAX_PROC_NAME           256 
> 

That is great to hear. I'm always happy to hear success stories (usually I get the bugs 
:-)

> This hasn't been intended as a way to support large messages, but more to ease local
> configuration. We use hostnames in many of these, and our customer configurations often
> have long FQDNs as their hostnames.

No, I didn't mean to imply that it was. The larger group names is used (as you do) to 
support larger daemon and client names, but doesn't require larger message sizes. It 
may need them indirectly, because now fewer group members names can fit into one 'packet' 
or message and so the number of members of groups your daemon can support will be less. 
With the support in version 4 for spreading internal group synchronization messages 
accross multiple data messages, this should be less of a hard limit and more of just a 
resource usage issue ( to synchronize group lists requires more data to be sent over the 
network when group names are larger)

> 
> I guess I should call this "a report of success", but you've piqued my curiosity: do you
> have reports of failures? In the absence of playing with MAX_SCATTER_ELEMENTS, etc?

When people first tried to raise the private name and proc name sizes (years ago) there 
were some bugs uncovered, and fixed. I am not aware of any current problems reported with 
using large names, but I hadn't seen a lot of success reports recently either so I wasn't 
sure if anyone was still using it. 

I'm glad to hear it's still working!

Thanks,

Jonathan

-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------