[Spread-users] Sudden freezes in message delivery using C API

[Doug Palmer]

On Tue, 2007-05-22 at 11:26 -0400, John Lane Schultz wrote:

> The token regeneration timeout parameter (Hurry_timeout) is set near the top of 
> membership.c in the Memb_init() fcn.  If Spread thinks you are on a WAN 
> (Wide_network) the default token regeneration timeout is six seconds.  If Spread 
> thinks you are on a LAN (!Wide_network) then the default timeout is two seconds.

I've timed the freezes and it works out to be 2 seconds every time. So
token loss looks like a likely candidate.

We have a peculiar setup where all the machines appear to be on a single
virtual LAN but we observed this behaviour before we separated the two
ends. So I'd like do a test where I put each machine in its own segment
and see whether . Is is possible to set up a spread.conf where machines
on the same subnet are in separate segments?

> I don't understand what you are trying to convey with the above table.  I doubt 
> this is a Java vs. C issue.  If anything, in the past the C interface has been 
> the more reliable / less buggy of the two interfaces.

This is what I would have expected. But we seem to only see problems in
C code. 

The other oddity is that adding messages into the mix seems to remove
the problem. But what we may be doing there is influencing the token
passing.