[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Subscription leasing, garbage collection and scalability
I believe the upshot of the previous exchange is, if you expect a subscriber to make a lot of subscriptions, the lease time had better be long or indefinite. In fact, from the producer's point of view, if you expect there to be a lot of subscriptions, period, the lease time had better be long or indefinite. In other words, the only method that WS-BN provides for garbage collection of subscriptions should be effectively disabled precisely when it is most likely to matter. I think the problem here is that WS-BN addresses subscription leasing and not garbage collection per se. This doesn't mean that it should try to provide all possible means of garbage collection, only that it should specifically point out a need, allow for as wide a range of solutions as is feasible, and point to subscription leasing (a la WS-RL) as one solution. This is essentially the same road we went down with topics. The more I consider leasing of individual subscriptions, the more potential technical issues I see. Obviously, none of them is insurmountable -- they have all been addressed and solved in other contexts. But each carries weight for the potential implementor. I'm willing to drill down on these a bit if needed, but I'm hoping we can avoid this and take a higher-level decision that leasing of individual subscriptions, while useful in some contexts, should not be required or be the only possible GC mechanism. With that provisional assumption, the immediate question becomes how can we allow for session-based garbage collection without adding undue weight to the WS-BN framework. Sessions have their own technical issues and implementation weight.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]