hystericalhell opened a new pull request #143: URL: https://github.com/apache/incubator-tubemq/pull/143
**Initial Prototype** for demonstration only Further details needs to be discussed. Currently it should be incomplete, and it *will* be some time. Here the major issue directly from initial plan in TUBEMQ-124, I think, contains (but not limited to): 1. Bloom Filter, as a probability prediction set, does **not** support a **remove** operation, so we have to choose an *appropriate* time to rebuild it after a long run with massive topics in and out, which is such an expensive thing just like the GC STP (stop-the-world); 2. Fine-grained control might be introduced to scatter the impact while exploit the negative-prediction efficiency, like we could do something like Java 8 revised ConcurrentHashMap, we could setup Bloom Filter on Segment (even available for memory prediction), and apply something like URA (unbalanced resource allocation) to better concentrate messages of the same topic into the same segment. Please review the prototype about the overall architecture of how Bloom Filter (my opinion) could behave, and let's discuss something in details about above factors, if any or more. Details: [TUBEMQ-124](https://issues.apache.org/jira/projects/TUBEMQ/issues/TUBEMQ-124) *The same would be synchronized to original issue comments* ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
