Hi,
I think we should keep this independent from indexing. Running the counter consolidation asynchronously might have commonalities with async indexing. If so, I'd first implement the former separately and then factor out the commonalties.
Michael On 3.2.15 12:42 , Davide Giannella wrote:
Good morning Team, with OAK-2220 we added support for atomic counters on non-clustered deployments. Now with OAK-2472 we're trying to provide a reliable way for having it working on a mongo cluster as well; read it some sort of async process. We already instructed the Editor to write hidden variables with UUID and consolidate them later on (0). As of now the consolidation mechanism happens in the same commit (synchronous). (0) http://goo.gl/lxCLGR I was looking at how we could achieve it and thought that the easiest way is to do something like the NodeCounterEditorProvider(1) where we register an async index (default)(2). (1) http://goo.gl/FbdIRi (2) http://goo.gl/M1OXll Pros - it's very easy to achieve - don't have to go through any refactoring or wheel-reinventing. - customers running on segment and willing to have the very latest counts up to dates will simply have to turn the index configuration to sync Cons - it's not really an index and sounds a bit misleading - we should "share" the async mechanism so that it can be used by both query indexes as any other additional process - the point above could involve major refactoring of a core functionality. - we should provide a different mechanism for configuring if wanted synchronous or asynchronous. Thoughts? Cheers Davide
