vigyasharma commented on issue #13883: URL: https://github.com/apache/lucene/issues/13883#issuecomment-3017158053
I think both of them are viable options with pros and cons. With the `MultiTenantCMSManager` approach, you can probably avoid making deep changes to existing CMS logic. This leaves users with the flexibility of keeping a dedicated CMS for their high activity index writers. CMS already has hooks to update merge threads and IO throttling, which can be used here. One crucial piece, is that manager needs to be aware of active and pending merges across all registered CMS objects. This means you need some mechanism to update the manager whenever pending/active merges change. A downside with option 1 could be limited control on merge scheduling. The most you can do is reduce merge threads to 1. What happens in machines with few cores, say 4 cores but 8 index writers..? Although, this is no worse from the setup today where the application has implicitly allocated more threads than cores to merging (because each CMS is unaware of other merging activity). > In the meantime, we will be starting on the first option… +1, I would encourage you to do the same. We can always pivot to option 2 later if needed. Feel free to share early an draft PR and we can brainstorm on code structure. I'd love to see how you're thinking of modeling manager – CMS interactions. -- 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. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
