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

[John Lane Schultz]

Doug Palmer wrote:
> We're using spread (4.0.0rc2) to provide messaging for a mixed Java/C++
> environment across a WAN and we're seeing odd freezes in components
> using the C API when we start sending a reasonable message rate. What
> happens is that message delivery appears to freeze for 2-5 seconds and
> then resume, with no messages lost. The messages are on the order of 1kb
> each.
>

Hi Doug,

More than likely what is happening is that you are experiencing intermittent 
losses that are occasionally hitting token control packets.  When a token packet 
is lost the system will appear to freeze until the token is regenerated after a 
timeout.  By default, this timeout is on the order of seconds.

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.

As an attempt to diagnose if losing token packets is the problem you can lower 
that timeout and see if the hiccups get shorter.

> With two machines, trabant (remote) and beetle (local)
> 
> trabant (C++) -> beetle (Java) 20mps bad
> trabant (Java) -> beetle (Java) 20mps OK
> trabant (Java) -> beetle (Java) 50mps OK
> trabant (Java) -> beetle (C++) 20mps OK
> trabant (Java) -> beetle (C++) >30mps bad
> beetle (Java) -> beetle (C++) >30mps OK
> 
> And, bizarrely,
> 
> trabant (Java) -> beetle (C++) >30mps and beetle (Java) -> beetle (Java) 20mps OK
> 

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.

Cheers!

-- 
John Schultz
Spread Concepts LLC
Phn: 443 838 2200
Fax: 301 560 8875