I'd say that the best approach would be to allow the listen backlog to be 
configurable, dispatch is ultimately a piece of infrastructure so probably 
shouldn't be making too many assumptions about client behaviour. I've been 
bitten by this sort of thing with other server technologies - CORBA and HTTP 
servers, so I've got fairly vivid memories of tearing my hair out trying to 
figure out what was happening :-) The listener backlog of 10 always seems a 
little small, I think that it's that value as much as a tradition as anything 
else.

Sent from my iPad

On 16 Apr 2014, at 15:46, "Ted Ross (JIRA)" <[email protected]> wrote:

> 
>    [ 
> https://issues.apache.org/jira/browse/DISPATCH-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13971497#comment-13971497
>  ] 
> 
> Ted Ross commented on DISPATCH-45:
> ----------------------------------
> 
> This is likely associated with the TCP listener backlog being overrun.  Two 
> things should be done:
> - Make the backlog configurable per-listener (requires changes in Proton)
> - Choose a default value that makes sense (Proton defaults to 50 currently)
> 
> 
>> starting clients too rapidly causes connection failures
>> -------------------------------------------------------
>> 
>>                Key: DISPATCH-45
>>                URL: https://issues.apache.org/jira/browse/DISPATCH-45
>>            Project: Qpid Dispatch
>>         Issue Type: Bug
>>         Components: Router Node
>>   Affects Versions: 0.2
>>           Reporter: michael goulish
>> 
>> I don't know if this should be a code change, or an extra warning issued by 
>> the router, or just a Note To Users of some kind, but I'm putting it here so 
>> as not to lose track of it.
>> If I start too many clients too rapidly, all trying to connect to the same 
>> router, some of them will fail.  My clients are very simple, not attempting 
>> any retries.  
>> When this shows up, it's looks like an error in the client, and users will 
>> probably hunt around for the cause.  It can be avoided by simply putting 
>> occasional pauses in my client-launching script.  Looks like some kind of 
>> backlog problem.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.2#6252)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to