Number of attachments :
Every space has a single Timer (expiryTimer) used to reap/cleanup tuples from the storage when placed with TTL's greater than zero. Each Timer object takes up a single thread on the host machine. This limit is variable.
I'm not familiar with use cases but if each space effectively requires a thread, creating 10,000 spaces (conceivable on a 32-way machine I suppose) will crash all spaces. Even worse, if a database-driven tuple store is used and experiences high latency (or even worse an error), the expirtyTimer thread will fail for all consecutive calls resulting in cleanup failure and incorrect delivery of tuples to consumers.
I suggest we move to the SchedulesExecutorService executor delivered as part of JDK5+. It works much better in the failure case, is much more memory-efficient.
In addition to this change, I believe spaces should hold not only tuples, but an internal class that has both the Tuple AND its expiry (another ticket?).