Growl Hangs on receipt of too many notifications simultaneously.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Send Growl about ~70-100 notifications all at once via GNTP
2. Growl becomes unresponsive.
3.

What is the expected output?
Growl remains responsive, and processes the notifications.   
What do you see instead?
Growl hangs (does NOT spike CPU, but also will not respond). 

The main cause I can think of is Growl 2.0's new networking stack which is 
multi threaded, and uses a few dispatch_barrier protected mutable dictionary 
for maintaining various things related to the receipt and processing and 
response to incoming notifications.  I cannot lock down a specific cause 
relating to their use yet, we should investigate further and fix if possible, 
or at worst, lower the limit on our simultaneous connections.  We presently 
limit simultaneous connections to 200, but we could lower that if need be.

Original issue reported on code.google.com by dan...@growl.info on 28 Sep 2012 at 7:34

[GoogleCodeExporter]

Original comment by rarich...@gmail.com on 18 Oct 2012 at 4:26

• Added labels: Milestone-2.1
• Removed labels: Milestone-2.0.1

[GoogleCodeExporter]

This is in reference to 
https://twitter.com/wundercounter/status/259312058724671488

Original comment by olaf.ald...@gmail.com on 24 Oct 2012 at 2:53

Attachments:

• gistfile1.txt

[GoogleCodeExporter]

The reason that people in threads reference this as happening on wake from 
sleep is likely that when a lot of apps wake from sleep, they fire 
notifications that they just received (such as back log in a server logged chat 
in IRC), and they are all doing it at once, resulting in hitting the dispatch 
soft limit.  

 I can confirm now that this is related to the access to the dispatch mutable dictionaries.  Lowering the amount of incoming connections could fix it, but from what I can tell, we would have to lower the limit below the dispatch soft limit of 64 threads blocked in synchronous operations.  This is a very low number, and not ideal.  I tried fixing the dispatch mutable protected dictionaries, using all sorts of methods, and have yet to find a solution.  Anything that imposes a wait in the thread on shared resources could cause this, whether its semaphores or the dispatch barriers.  

Moving the server to use a background serial queue instead resolves the issue, 
and we are again able to handle 200 simultaneous connections as intended (and 
additional connections are simply dropped).   Performance seems to be good.  
This may have been a case of doing multi-threadedness unnecessarily ultimately.

I have pushed this in [abfc83069da1] for Growl 2.1, and in theory it could be 
back ported to 2.0.2 (2.1 brings other changes to the server, but this change 
has no conflict with any of those changes to my knowledge).

Flagging as fixed in source, I was able to replicate this quite well, and I can 
no longer replicate it, and can in fact hit the socket limiter properly (and 
confirm that it is working as well)

Original comment by dan...@growl.info on 23 Jan 2013 at 3:40

• Changed state: FixedInSource

[GoogleCodeExporter]

Any word on when a new release will be rolled and pushed to the MAS? This bug 
is hitting me every time I wake from sleep. It's annoying to have to manually 
kill off growl every time!

Original comment by devianti...@gmail.com on 6 Apr 2013 at 3:03

[GoogleCodeExporter]

Is this supposed to be resolved with version 2.1.1? Because it is still 
happening to my MacBook Pro with Mountain Lion (when waking up from sleep).

Original comment by codeblog...@gmail.com on 21 Aug 2013 at 5:51