|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
The application would not freeze, it would slow down with 100 (default value) ms waits on calling queue.offer and would show warnings for dropping events. So the use-case of connection drops would overlap with the one where there are more events than the queue can take.
By the way if I am not mistaken, the behaviour you describe is documented as such, see "In particular, in the extreme case where the network link to the server is down, the client will be eventually blocked.". Which seems outdated considering the current code base.