[jira] [Commented] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679531#comment-14679531 ] ASF subversion and git services commented on SOLR-7855: --- Commit 1694952 from gcha...@apache.org in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1694952 ] SOLR-7855: OverseerCollectionProcessor: separate general task management from collection message handling > OverseerCollectionProcessor: separate general task management from collection > message handling > -- > > Key: SOLR-7855 > URL: https://issues.apache.org/jira/browse/SOLR-7855 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7855.patch, SOLR-7855.patch, SOLR-7855.patch > > > While working on SOLR-7789, I realized it would be easier if I split up the > OverseerCollectionProcessor into two parts: > 1) General handling of tasks (work queues, etc) > 2) Processing a collection handler request > I haven't decided whether the ConfigSet should have its own processor, i.e. > OverseerConfigSetProcessor or reuse at least the thread for the > OverseerCollectionProcessor, but in either case this refactoring will be > helpful. That is, if the ConfigSet processing has its own processing, I can > reuse the general handling of tasks part. If the ConfigSet processing reuses > the OverseerCollectionProcessing thread, I won't complicate the > implementation with ConfigSet operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14663117#comment-14663117 ] Ramkumar Aiyengar commented on SOLR-7855: - [~gchanan], SOLR-7766 is now done, any plans to commit this soon to branch_5x? Trying to avoid conflicts with SOLR-7859.. > OverseerCollectionProcessor: separate general task management from collection > message handling > -- > > Key: SOLR-7855 > URL: https://issues.apache.org/jira/browse/SOLR-7855 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7855.patch, SOLR-7855.patch, SOLR-7855.patch > > > While working on SOLR-7789, I realized it would be easier if I split up the > OverseerCollectionProcessor into two parts: > 1) General handling of tasks (work queues, etc) > 2) Processing a collection handler request > I haven't decided whether the ConfigSet should have its own processor, i.e. > OverseerConfigSetProcessor or reuse at least the thread for the > OverseerCollectionProcessor, but in either case this refactoring will be > helpful. That is, if the ConfigSet processing has its own processing, I can > reuse the general handling of tasks part. If the ConfigSet processing reuses > the OverseerCollectionProcessing thread, I won't complicate the > implementation with ConfigSet operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659546#comment-14659546 ] Gregory Chanan commented on SOLR-7855: -- Committed to trunk. I tried to merge to branch_5x, but SOLR-7766 not being there causes a bunch of conflicts. Going to wait until that is committed before proceeding. > OverseerCollectionProcessor: separate general task management from collection > message handling > -- > > Key: SOLR-7855 > URL: https://issues.apache.org/jira/browse/SOLR-7855 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7855.patch, SOLR-7855.patch, SOLR-7855.patch > > > While working on SOLR-7789, I realized it would be easier if I split up the > OverseerCollectionProcessor into two parts: > 1) General handling of tasks (work queues, etc) > 2) Processing a collection handler request > I haven't decided whether the ConfigSet should have its own processor, i.e. > OverseerConfigSetProcessor or reuse at least the thread for the > OverseerCollectionProcessor, but in either case this refactoring will be > helpful. That is, if the ConfigSet processing has its own processing, I can > reuse the general handling of tasks part. If the ConfigSet processing reuses > the OverseerCollectionProcessing thread, I won't complicate the > implementation with ConfigSet operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659545#comment-14659545 ] ASF subversion and git services commented on SOLR-7855: --- Commit 1694406 from gcha...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1694406 ] SOLR-7855: OverseerCollectionProcessor: separate general task management from collection message handling > OverseerCollectionProcessor: separate general task management from collection > message handling > -- > > Key: SOLR-7855 > URL: https://issues.apache.org/jira/browse/SOLR-7855 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7855.patch, SOLR-7855.patch, SOLR-7855.patch > > > While working on SOLR-7789, I realized it would be easier if I split up the > OverseerCollectionProcessor into two parts: > 1) General handling of tasks (work queues, etc) > 2) Processing a collection handler request > I haven't decided whether the ConfigSet should have its own processor, i.e. > OverseerConfigSetProcessor or reuse at least the thread for the > OverseerCollectionProcessor, but in either case this refactoring will be > helpful. That is, if the ConfigSet processing has its own processing, I can > reuse the general handling of tasks part. If the ConfigSet processing reuses > the OverseerCollectionProcessing thread, I won't complicate the > implementation with ConfigSet operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654648#comment-14654648 ] Mark Miller commented on SOLR-7855: --- Actually, skip it. I'll make another issue and move all the overseer classes to the proper package. > OverseerCollectionProcessor: separate general task management from collection > message handling > -- > > Key: SOLR-7855 > URL: https://issues.apache.org/jira/browse/SOLR-7855 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7855.patch, SOLR-7855.patch > > > While working on SOLR-7789, I realized it would be easier if I split up the > OverseerCollectionProcessor into two parts: > 1) General handling of tasks (work queues, etc) > 2) Processing a collection handler request > I haven't decided whether the ConfigSet should have its own processor, i.e. > OverseerConfigSetProcessor or reuse at least the thread for the > OverseerCollectionProcessor, but in either case this refactoring will be > helpful. That is, if the ConfigSet processing has its own processing, I can > reuse the general handling of tasks part. If the ConfigSet processing reuses > the OverseerCollectionProcessing thread, I won't complicate the > implementation with ConfigSet operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654589#comment-14654589 ] Mark Miller commented on SOLR-7855: --- Then why not just move it since the patch adds even more Overseer* classes in an odd spot? Either way, but seems like a gimme to me. > OverseerCollectionProcessor: separate general task management from collection > message handling > -- > > Key: SOLR-7855 > URL: https://issues.apache.org/jira/browse/SOLR-7855 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7855.patch, SOLR-7855.patch > > > While working on SOLR-7789, I realized it would be easier if I split up the > OverseerCollectionProcessor into two parts: > 1) General handling of tasks (work queues, etc) > 2) Processing a collection handler request > I haven't decided whether the ConfigSet should have its own processor, i.e. > OverseerConfigSetProcessor or reuse at least the thread for the > OverseerCollectionProcessor, but in either case this refactoring will be > helpful. That is, if the ConfigSet processing has its own processing, I can > reuse the general handling of tasks part. If the ConfigSet processing reuses > the OverseerCollectionProcessing thread, I won't complicate the > implementation with ConfigSet operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654545#comment-14654545 ] Gregory Chanan commented on SOLR-7855: -- bq. I think it goes without saying this is how it should be I should have said the question is "for this patch" -- I agree with how things should be. > OverseerCollectionProcessor: separate general task management from collection > message handling > -- > > Key: SOLR-7855 > URL: https://issues.apache.org/jira/browse/SOLR-7855 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7855.patch, SOLR-7855.patch > > > While working on SOLR-7789, I realized it would be easier if I split up the > OverseerCollectionProcessor into two parts: > 1) General handling of tasks (work queues, etc) > 2) Processing a collection handler request > I haven't decided whether the ConfigSet should have its own processor, i.e. > OverseerConfigSetProcessor or reuse at least the thread for the > OverseerCollectionProcessor, but in either case this refactoring will be > helpful. That is, if the ConfigSet processing has its own processing, I can > reuse the general handling of tasks part. If the ConfigSet processing reuses > the OverseerCollectionProcessing thread, I won't complicate the > implementation with ConfigSet operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654542#comment-14654542 ] Mark Miller commented on SOLR-7855: --- bq. I think the question is whether we move all the overseer related code to the cloud.overseer package or not. I think it goes without saying this is how it should be. We have a bunch of Overseer* classes in a cloud package instead of an existing cloud.overseer package. To be more specific on my complaint (a lot of which I'm am the cause of), a bunch of classes are jammed in the core and cloud packages that could surely be broken up into packages in a more useful fashion. The CollectionsOverseerProcesser is just one example where little thought was used. Seems like a good thing to fix this in this case. > OverseerCollectionProcessor: separate general task management from collection > message handling > -- > > Key: SOLR-7855 > URL: https://issues.apache.org/jira/browse/SOLR-7855 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7855.patch, SOLR-7855.patch > > > While working on SOLR-7789, I realized it would be easier if I split up the > OverseerCollectionProcessor into two parts: > 1) General handling of tasks (work queues, etc) > 2) Processing a collection handler request > I haven't decided whether the ConfigSet should have its own processor, i.e. > OverseerConfigSetProcessor or reuse at least the thread for the > OverseerCollectionProcessor, but in either case this refactoring will be > helpful. That is, if the ConfigSet processing has its own processing, I can > reuse the general handling of tasks part. If the ConfigSet processing reuses > the OverseerCollectionProcessing thread, I won't complicate the > implementation with ConfigSet operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654439#comment-14654439 ] Gregory Chanan commented on SOLR-7855: -- Thanks for the feedback Mark. bq. A lot of cloud code has already kind of cluttered up random packages as it was added for various easy at the time reasons - moving towards something nicer makes sense to me. I think the question is whether we move all the overseer related code to the cloud.overseer package or not. Now seemed like a good time because we are moving around a bunch of code anyway (which complicates the history to a certain extent). So if we can do it at one time, that's ideal. I'll investigate how feasible that is. > OverseerCollectionProcessor: separate general task management from collection > message handling > -- > > Key: SOLR-7855 > URL: https://issues.apache.org/jira/browse/SOLR-7855 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7855.patch, SOLR-7855.patch > > > While working on SOLR-7789, I realized it would be easier if I split up the > OverseerCollectionProcessor into two parts: > 1) General handling of tasks (work queues, etc) > 2) Processing a collection handler request > I haven't decided whether the ConfigSet should have its own processor, i.e. > OverseerConfigSetProcessor or reuse at least the thread for the > OverseerCollectionProcessor, but in either case this refactoring will be > helpful. That is, if the ConfigSet processing has its own processing, I can > reuse the general handling of tasks part. If the ConfigSet processing reuses > the OverseerCollectionProcessing thread, I won't complicate the > implementation with ConfigSet operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653905#comment-14653905 ] Mark Miller commented on SOLR-7855: --- bq. (it doesn't really have anything to do directly with collections AFAICT, though the CollectionProcessor handles messages about it). Seems like someone was lazy when they added it. Don't know what to tell you now. At least it's more isolated with this patch. bq. package-level info We can open that up and add internal comment notes or something if you think that makes sense. A lot of this is probably fairly arbitrary when compared to the rest of the code. A lot of cloud code has already kind of cluttered up random packages as it was added for various easy at the time reasons - moving towards something nicer makes sense to me. > OverseerCollectionProcessor: separate general task management from collection > message handling > -- > > Key: SOLR-7855 > URL: https://issues.apache.org/jira/browse/SOLR-7855 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7855.patch, SOLR-7855.patch > > > While working on SOLR-7789, I realized it would be easier if I split up the > OverseerCollectionProcessor into two parts: > 1) General handling of tasks (work queues, etc) > 2) Processing a collection handler request > I haven't decided whether the ConfigSet should have its own processor, i.e. > OverseerConfigSetProcessor or reuse at least the thread for the > OverseerCollectionProcessor, but in either case this refactoring will be > helpful. That is, if the ConfigSet processing has its own processing, I can > reuse the general handling of tasks part. If the ConfigSet processing reuses > the OverseerCollectionProcessing thread, I won't complicate the > implementation with ConfigSet operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653857#comment-14653857 ] Mark Miller commented on SOLR-7855: --- +1, looks good to me. Minor suggestions: Assign.java - remove unused imports rather than refactor OverseerProcessor - new file, remove unused imports OvrseerCollectionMessageHandler -new file, remove unused imports OverseeerMessageHandlerSelector - add light class doc OverseerCollectionProcessor - add light class doc OverseerProcessor - add light class doc > OverseerCollectionProcessor: separate general task management from collection > message handling > -- > > Key: SOLR-7855 > URL: https://issues.apache.org/jira/browse/SOLR-7855 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7855.patch, SOLR-7855.patch > > > While working on SOLR-7789, I realized it would be easier if I split up the > OverseerCollectionProcessor into two parts: > 1) General handling of tasks (work queues, etc) > 2) Processing a collection handler request > I haven't decided whether the ConfigSet should have its own processor, i.e. > OverseerConfigSetProcessor or reuse at least the thread for the > OverseerCollectionProcessor, but in either case this refactoring will be > helpful. That is, if the ConfigSet processing has its own processing, I can > reuse the general handling of tasks part. If the ConfigSet processing reuses > the OverseerCollectionProcessing thread, I won't complicate the > implementation with ConfigSet operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
