UnicastContentSubject GC issues

[daschl]

In addition to the other issues, it looks like there is a big issue in terms of GC and/or a leak. Here is a comparison to the same code running (load against a Couchbase cluster). AsyncSubject vs UnicastContentSubject. Btw I expected a little bit more GC since more stuff is done, but this drastic difference seems weird (note the 2s vs 50s gc pause time in a 3 min run).

For some context: that comes from 10k ops/s by fetching docs from the server. But in this test its against nonexistent keys, so the buffers are empty.. just wanted a baseline :)

AsyncSubject

UnicastContentSubject

[daschl]

I've been playing around a bit with timings and it seems that a much shorter timeout doesn't have as much impact as longer ones. This indicates to me that it's because the timers are getting moved out of the young gen making them more costly to be cleaned up.

Any idea how we can work around this to some degree?

[daschl]

@NiteshKant @benjchristensen one thing I found as a potential improvement is to only schedule the call when one is still actually unsubscribed. Because currently the disposeIfNotSubscribed() is still called even if one is already subscribed, paying the penalty there too.

want me to submit a PR for this as well?

[daschl]

#313 related.

[NiteshKant]

0.5.x has no UnicastContentSubject and no unnecessary buffering of data.