[jira] [Comment Edited] (SOLR-13502) Investigate using something other than ZooKeeper's "4 letter words" for the admin UI status
[
https://issues.apache.org/jira/browse/SOLR-13502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842199#comment-17842199
]
John Durham edited comment on SOLR-13502 at 4/30/24 2:11 AM:
-
I think having it be an addition to 4lw makes sense. I'll work towards making
it work with either the original 4lw or admin server.
was (Author: jdurham):
I think having it be in addition to 4lw makes sense. I'll work towards making
it work with either the original 4lw or admin server.
> Investigate using something other than ZooKeeper's "4 letter words" for the
> admin UI status
> ---
>
> Key: SOLR-13502
> URL: https://issues.apache.org/jira/browse/SOLR-13502
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI
>Reporter: Erick Erickson
>Priority: Major
>
> ZooKeeper 3.5.5 requires a whitelist of allowed "4 letter words". The only
> place I see on a quick look at the Solr code where 4lws are used is in the
> admin UI "ZK Status" link.
> In order to use the admin UI "ZK Status" link, users will have to modify
> their zoo.cfg file with
> {code}
> 4lw.commands.whitelist=mntr,conf,ruok
> {code}
> This JIRA is to see if there are alternatives to using 4lw for the admin UI.
> This depends on SOLR-8346. If we find an alternative, we need to remove the
> additions to the ref guide that mention changing zoo.cfg (just scan for 4lw
> in all the .adoc files) and remove SolrZkServer.ZK_WHITELIST_PROPERTY and all
> references to it (SolrZkServer and SolrTestCaseJ4).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-13502) Investigate using something other than ZooKeeper's "4 letter words" for the admin UI status
[
https://issues.apache.org/jira/browse/SOLR-13502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842199#comment-17842199
]
John Durham edited comment on SOLR-13502 at 4/30/24 12:33 AM:
--
I think having it be in addition to 4lw makes sense. I'll work towards making
it work with either the original 4lw or admin server.
was (Author: jdurham):
I think having it be in addition to 4lw makes sense. I'll work towards making
it work with either the original 4lw or admin server.
So far I'm not seeing SSL supported on admin server. However, with admin server
being served on a separate port (8080 default) from the regular client
connections (port 2181), at least some kind of monitoring/metrics will be
available even if SSL isn't currently available.
> Investigate using something other than ZooKeeper's "4 letter words" for the
> admin UI status
> ---
>
> Key: SOLR-13502
> URL: https://issues.apache.org/jira/browse/SOLR-13502
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI
>Reporter: Erick Erickson
>Priority: Major
>
> ZooKeeper 3.5.5 requires a whitelist of allowed "4 letter words". The only
> place I see on a quick look at the Solr code where 4lws are used is in the
> admin UI "ZK Status" link.
> In order to use the admin UI "ZK Status" link, users will have to modify
> their zoo.cfg file with
> {code}
> 4lw.commands.whitelist=mntr,conf,ruok
> {code}
> This JIRA is to see if there are alternatives to using 4lw for the admin UI.
> This depends on SOLR-8346. If we find an alternative, we need to remove the
> additions to the ref guide that mention changing zoo.cfg (just scan for 4lw
> in all the .adoc files) and remove SolrZkServer.ZK_WHITELIST_PROPERTY and all
> references to it (SolrZkServer and SolrTestCaseJ4).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-13502) Investigate using something other than ZooKeeper's "4 letter words" for the admin UI status
[
https://issues.apache.org/jira/browse/SOLR-13502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842199#comment-17842199
]
John Durham commented on SOLR-13502:
I think having it be in addition to 4lw makes sense. I'll work towards making
it work with either the original 4lw or admin server.
So far I'm not seeing SSL supported on admin server. However, with admin server
being served on a separate port (8080 default) from the regular client
connections (port 2181), at least some kind of monitoring/metrics will be
available even if SSL isn't currently available.
> Investigate using something other than ZooKeeper's "4 letter words" for the
> admin UI status
> ---
>
> Key: SOLR-13502
> URL: https://issues.apache.org/jira/browse/SOLR-13502
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI
>Reporter: Erick Erickson
>Priority: Major
>
> ZooKeeper 3.5.5 requires a whitelist of allowed "4 letter words". The only
> place I see on a quick look at the Solr code where 4lws are used is in the
> admin UI "ZK Status" link.
> In order to use the admin UI "ZK Status" link, users will have to modify
> their zoo.cfg file with
> {code}
> 4lw.commands.whitelist=mntr,conf,ruok
> {code}
> This JIRA is to see if there are alternatives to using 4lw for the admin UI.
> This depends on SOLR-8346. If we find an alternative, we need to remove the
> additions to the ref guide that mention changing zoo.cfg (just scan for 4lw
> in all the .adoc files) and remove SolrZkServer.ZK_WHITELIST_PROPERTY and all
> references to it (SolrZkServer and SolrTestCaseJ4).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-13502) Investigate using something other than ZooKeeper's "4 letter words" for the admin UI status
[
https://issues.apache.org/jira/browse/SOLR-13502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17841560#comment-17841560
]
John Durham commented on SOLR-13502:
Hello - I would be willing to work on refactoring the Solr admin UI to use ZK's
adminServer. Is this something I could volunteer to take on, on a part-time
basis? A few months back, I had to set up SolrCloud/Zookeeper with TLS enabled
at work and while the admin UI not working with TLS wasn't a blocker, it would
have been a nice-to-have!
> Investigate using something other than ZooKeeper's "4 letter words" for the
> admin UI status
> ---
>
> Key: SOLR-13502
> URL: https://issues.apache.org/jira/browse/SOLR-13502
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI
>Reporter: Erick Erickson
>Priority: Major
>
> ZooKeeper 3.5.5 requires a whitelist of allowed "4 letter words". The only
> place I see on a quick look at the Solr code where 4lws are used is in the
> admin UI "ZK Status" link.
> In order to use the admin UI "ZK Status" link, users will have to modify
> their zoo.cfg file with
> {code}
> 4lw.commands.whitelist=mntr,conf,ruok
> {code}
> This JIRA is to see if there are alternatives to using 4lw for the admin UI.
> This depends on SOLR-8346. If we find an alternative, we need to remove the
> additions to the ref guide that mention changing zoo.cfg (just scan for 4lw
> in all the .adoc files) and remove SolrZkServer.ZK_WHITELIST_PROPERTY and all
> references to it (SolrZkServer and SolrTestCaseJ4).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16468) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (collection level)
[ https://issues.apache.org/jira/browse/SOLR-16468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702159#comment-17702159 ] John Durham edited comment on SOLR-16468 at 3/19/23 5:44 PM: - Hi Jason - I started a [Draft PR|https://github.com/apache/solr/pull/1471] that should contain LIST, CREATE, and DELETE collection snapshot resources. I still need to add tests and update docs, but had some questions regarding those two topics: # Is there a base class I can use to create tests for Collection level code? I did some looking around the test suite, but nothing stuck out to me. I also considered doing some mocking, but wanted to avoid that if there was a better way of testing available. # Looking through the existing adocs, I didn't see anything documenting the Collection snapshots V1 APIs. Is that something we want to start for the V2 APIs? I'm thinking if we did, they would probably be located in documentation regarding backup/restore functionality. What do you think? was (Author: jdurham): Hi Jason - I started a [Draft PR|https://github.com/apache/solr/pull/1471] that should contain LIST, CREATE, and DELETE collection snapshot resources. I still need to add tests and update docs, but had some questions regarding those two topics: # Is there an abstract class I can use to create tests for Collection level code? I did some looking around the test suite, but nothing stuck out to me. I also considered doing some mocking, but wanted to avoid that if there was a better way of testing available. # Looking through the existing adocs, I didn't see anything documenting the Collection snapshots V1 APIs. Is that something we want to start for the V2 APIs? I'm thinking if we did, they would probably be located in documentation regarding backup/restore functionality. What do you think? > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (collection level) > --- > > Key: SOLR-16468 > URL: https://issues.apache.org/jira/browse/SOLR-16468 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.2 >Reporter: Sanjay Dutt >Assignee: Jason Gerlowski >Priority: Major > Labels: V2, newdev > > Snapshot API has no v2 equivalent at collection level. This ticket is to > track changes made to the Solr to add v2 equivalent of 'CREATESNAPSHOT', > 'LISTSNAPSHOT' and 'DELETESNAPSHOT' api. > Proposed API design > * collection CREATESNAPSHOT - POST > /api/collections/collName/snapshots/snapshotName > * collection LISTSNAPSHOT - GET /api/collections/collName/snapshots > * collection DELETESNAPSHOT - DELETE > /api/collections/collName/snapshots/snapshotName > A few other pointers that might be helpful, especially for newcomers: > * The v1 logic for this API lives in CollectionsHandler (for the > collection-level APIs) and CoreAdminHandler (for the core-level APIs). > * Some discussion of how APIs work in Solr (Particularly the "APIs in Solr" > section.) > * A step-by-step guide to creating APIs using the preferred v2 API framework > * [A recent PR that adds a v2 API, as an > example|https://github.com/apache/solr/pull/1061/files] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16468) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (collection level)
[ https://issues.apache.org/jira/browse/SOLR-16468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702159#comment-17702159 ] John Durham edited comment on SOLR-16468 at 3/18/23 6:51 PM: - Hi Jason - I started a [Draft PR|https://github.com/apache/solr/pull/1471] that should contain LIST, CREATE, and DELETE collection snapshot resources. I still need to add tests and update docs, but had some questions regarding those two topics: # Is there an abstract class I can use to create tests for Collection level code? I did some looking around the test suite, but nothing stuck out to me. I also considered doing some mocking, but wanted to avoid that if there was a better way of testing available. # Looking through the existing adocs, I didn't see anything documenting the Collection snapshots V1 APIs. Is that something we want to start for the V2 APIs? I'm thinking if we did, they would probably be located in documentation regarding backup/restore functionality. What do you think? was (Author: jdurham): Hi Jason - I started a [Draft PR|https://github.com/apache/solr/pull/1471] that should contain LIST, CREATE, and DELETE collection snapshot resources. I still need to add tests and update docs, but had some questions regarding those two topics: # Is there an abstract class I can use to create tests for Collection level code? I did some looking around the test suite, but nothing stuck out to me. I also considered doing some mocking, but wanted to avoid that if there was a better way of testing available. # Looking through the existing adocs, I didn't see anything documenting the Collection snapshots. Is that something we want to start for the V2 APIs? I'm thinking if we did, they would probably be located in documentation regarding backup/restore functionality. What do you think? > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (collection level) > --- > > Key: SOLR-16468 > URL: https://issues.apache.org/jira/browse/SOLR-16468 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.2 >Reporter: Sanjay Dutt >Assignee: Jason Gerlowski >Priority: Major > Labels: V2, newdev > > Snapshot API has no v2 equivalent at collection level. This ticket is to > track changes made to the Solr to add v2 equivalent of 'CREATESNAPSHOT', > 'LISTSNAPSHOT' and 'DELETESNAPSHOT' api. > Proposed API design > * collection CREATESNAPSHOT - POST > /api/collections/collName/snapshots/snapshotName > * collection LISTSNAPSHOT - GET /api/collections/collName/snapshots > * collection DELETESNAPSHOT - DELETE > /api/collections/collName/snapshots/snapshotName > A few other pointers that might be helpful, especially for newcomers: > * The v1 logic for this API lives in CollectionsHandler (for the > collection-level APIs) and CoreAdminHandler (for the core-level APIs). > * Some discussion of how APIs work in Solr (Particularly the "APIs in Solr" > section.) > * A step-by-step guide to creating APIs using the preferred v2 API framework > * [A recent PR that adds a v2 API, as an > example|https://github.com/apache/solr/pull/1061/files] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16468) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (collection level)
[ https://issues.apache.org/jira/browse/SOLR-16468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702159#comment-17702159 ] John Durham edited comment on SOLR-16468 at 3/18/23 6:50 PM: - Hi Jason - I started a [Draft PR|https://github.com/apache/solr/pull/1471] that should contain LIST, CREATE, and DELETE collection snapshot resources. I still need to add tests and update docs, but had some questions regarding those two topics: # Is there an abstract class I can use to create tests for Collection level code? I did some looking around the test suite, but nothing stuck out to me. I also considered doing some mocking, but wanted to avoid that if there was a better way of testing available. # Looking through the existing adocs, I didn't see anything documenting the Collection snapshots. Is that something we want to start for the V2 APIs? I'm thinking if we did, they would probably be located in documentation regarding backup/restore functionality. What do you think? was (Author: jdurham): Hi Jason - I started a [Draft PR|https://github.com/apache/solr/pull/1471] that should contain LIST, CREATE, and DELETE snapshot collection. I still need to add tests and update docs, but had some questions regarding those two topics: # Is there an abstract class I can use to create tests for Collection level code? I did some looking around the test suite, but nothing stuck out to me. I also considered doing some mocking, but wanted to avoid that if there was a better way of testing available. # Looking through the existing adocs, I didn't see anything documenting the Collection snapshots. Is that something we want to start for the V2 APIs? I'm thinking if we did, they would probably be located in documentation regarding backup/restore functionality. What do you think? > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (collection level) > --- > > Key: SOLR-16468 > URL: https://issues.apache.org/jira/browse/SOLR-16468 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.2 >Reporter: Sanjay Dutt >Assignee: Jason Gerlowski >Priority: Major > Labels: V2, newdev > > Snapshot API has no v2 equivalent at collection level. This ticket is to > track changes made to the Solr to add v2 equivalent of 'CREATESNAPSHOT', > 'LISTSNAPSHOT' and 'DELETESNAPSHOT' api. > Proposed API design > * collection CREATESNAPSHOT - POST > /api/collections/collName/snapshots/snapshotName > * collection LISTSNAPSHOT - GET /api/collections/collName/snapshots > * collection DELETESNAPSHOT - DELETE > /api/collections/collName/snapshots/snapshotName > A few other pointers that might be helpful, especially for newcomers: > * The v1 logic for this API lives in CollectionsHandler (for the > collection-level APIs) and CoreAdminHandler (for the core-level APIs). > * Some discussion of how APIs work in Solr (Particularly the "APIs in Solr" > section.) > * A step-by-step guide to creating APIs using the preferred v2 API framework > * [A recent PR that adds a v2 API, as an > example|https://github.com/apache/solr/pull/1061/files] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16468) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (collection level)
[ https://issues.apache.org/jira/browse/SOLR-16468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702159#comment-17702159 ] John Durham commented on SOLR-16468: Hi Jason - I started a [Draft PR|https://github.com/apache/solr/pull/1471] that should contain LIST, CREATE, and DELETE snapshot collection. I still need to add tests and update docs, but had some questions regarding those two topics: # Is there an abstract class I can use to create tests for Collection level code? I did some looking around the test suite, but nothing stuck out to me. I also considered doing some mocking, but wanted to avoid that if there was a better way of testing available. # Looking through the existing adocs, I didn't see anything documenting the Collection snapshots. Is that something we want to start for the V2 APIs? I'm thinking if we did, they would probably be located in documentation regarding backup/restore functionality. What do you think? > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (collection level) > --- > > Key: SOLR-16468 > URL: https://issues.apache.org/jira/browse/SOLR-16468 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.2 >Reporter: Sanjay Dutt >Assignee: Jason Gerlowski >Priority: Major > Labels: V2, newdev > > Snapshot API has no v2 equivalent at collection level. This ticket is to > track changes made to the Solr to add v2 equivalent of 'CREATESNAPSHOT', > 'LISTSNAPSHOT' and 'DELETESNAPSHOT' api. > Proposed API design > * collection CREATESNAPSHOT - POST > /api/collections/collName/snapshots/snapshotName > * collection LISTSNAPSHOT - GET /api/collections/collName/snapshots > * collection DELETESNAPSHOT - DELETE > /api/collections/collName/snapshots/snapshotName > A few other pointers that might be helpful, especially for newcomers: > * The v1 logic for this API lives in CollectionsHandler (for the > collection-level APIs) and CoreAdminHandler (for the core-level APIs). > * Some discussion of how APIs work in Solr (Particularly the "APIs in Solr" > section.) > * A step-by-step guide to creating APIs using the preferred v2 API framework > * [A recent PR that adds a v2 API, as an > example|https://github.com/apache/solr/pull/1061/files] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16468) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (collection level)
[ https://issues.apache.org/jira/browse/SOLR-16468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694240#comment-17694240 ] John Durham commented on SOLR-16468: I'd be willing to pick up the CREATE and DELETE endpoints, since LIST is already complete. > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (collection level) > --- > > Key: SOLR-16468 > URL: https://issues.apache.org/jira/browse/SOLR-16468 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.2 >Reporter: Sanjay Dutt >Assignee: Jason Gerlowski >Priority: Major > Labels: V2, newdev > > Snapshot API has no v2 equivalent at collection level. This ticket is to > track changes made to the Solr to add v2 equivalent of 'CREATESNAPSHOT', > 'LISTSNAPSHOT' and 'DELETESNAPSHOT' api. > Proposed API design > * collection CREATESNAPSHOT - POST > /api/collections/collName/snapshots/snapshotName > * collection LISTSNAPSHOT - GET /api/collections/collName/snapshots > * collection DELETESNAPSHOT - DELETE > /api/collections/collName/snapshots/snapshotName > A few other pointers that might be helpful, especially for newcomers: > * The v1 logic for this API lives in CollectionsHandler (for the > collection-level APIs) and CoreAdminHandler (for the core-level APIs). > * Some discussion of how APIs work in Solr (Particularly the "APIs in Solr" > section.) > * A step-by-step guide to creating APIs using the preferred v2 API framework > * [A recent PR that adds a v2 API, as an > example|https://github.com/apache/solr/pull/1061/files] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16462) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (core level)
[ https://issues.apache.org/jira/browse/SOLR-16462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17629538#comment-17629538 ] John Durham commented on SOLR-16462: Some of what I'm writing below is just a rehash of some responses I left on the Github PR: I went ahead with creating a CoreAdminAPIBase class to house the async logic mentioned above. I copied code from the CoreAdminHandler that handled async Tasks, and I think I have this Base class solution in a position where it works similar to the Handler. During the refactor, I had to Inject the SolrQueryRequest and SolrQueryResponse which is causing a MultiException to be printed in the terminal when calling the Snapshot V2 APIs. From what I can tell, it appears that Jersey is having trouble resolving the InjectionFactories subclasses. I pasted the exception stacktrace over on the PR. If you decide to do any work on writing a more general async handling service, I'd be happy to pitch in! It sounds like a neat project and a great way to get more familiar with the other Solr APIs. > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (core level) > -- > > Key: SOLR-16462 > URL: https://issues.apache.org/jira/browse/SOLR-16462 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.1 >Reporter: Sanjay Dutt >Priority: Major > Labels: V2, newdev > Time Spent: 2h 10m > Remaining Estimate: 0h > > Snapshot API has no v2 equivalent. This ticket is to track changes made to > the Solr to add v2 equivalent of 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' api. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16462) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (core level)
[ https://issues.apache.org/jira/browse/SOLR-16462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17625265#comment-17625265 ] John Durham edited comment on SOLR-16462 at 10/27/22 7:18 PM: -- I think what you described makes sense and think that your second approach feels more like the right way to handle it. Keeping state in a static field could solve the issue, but I agree that is feels a little off. I think having some kind of object that was coupled to the CoreContainer would be a good approach. With either approach, where would the "async" handling logic happen? My initial thought would be we could still have a base class with a method that handles submitting the work to an executor, but the developer would have to know to call that method when writing their API Resource and would have to be responsible for returning early. Also, would handling this async work at the Resource level be too far down (up?) the stack? What I like about the current V1 system is that an author of an operation doesn't have to concern themselves with whether their code is being called synchronously or asynchronously (insofar as I can tell). Would it make sense to have the CoreContainer hold an object that *wraps* the ApplicationHandler? If we did that, then when V2HttpCall.invokeJerseyRequest calls jerseyHandler.handle (line 371), it'll first go through our async tracking logic (in our new object) before routing into the actual ApplicationHandler logic. was (Author: jdurham): I think what you described makes sense and think that your second approach feels more like the right way to handle it. Keeping state in a static field could solve the issue, but I agree that is feels a little off. I think having some kind of object that was coupled to the CoreContainer would be a good approach. With either approach, where would the "async" handling logic happen? My initial thought would be we could still have a base class with a method that handles submitting the work to an executor, but the developer would have to know to call that method when writing their API Resource and would have to be responsible for returning early. Also, would handling this async work at the Resource level be too far down (up?) the stack? What I like about the current V1 system is that an author of an operation doesn't have to concern themselves with whether they're code is being called synchronously or asynchrously (insofar as I can tell). Would it make sense to have the CoreContainer hold an object that *wraps* the ApplicationHandler? If we did that, then when V2HttpCall.invokeJerseyRequest calls jerseyHandler.handle (line 371), it'll first go through our async tracking logic (in our new object) before routing into the actual ApplicationHandler logic. > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (core level) > -- > > Key: SOLR-16462 > URL: https://issues.apache.org/jira/browse/SOLR-16462 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.1 >Reporter: Sanjay Dutt >Priority: Major > Labels: V2, newdev > Time Spent: 1h > Remaining Estimate: 0h > > Snapshot API has no v2 equivalent. This ticket is to track changes made to > the Solr to add v2 equivalent of 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' api. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16462) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (core level)
[ https://issues.apache.org/jira/browse/SOLR-16462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17625265#comment-17625265 ] John Durham commented on SOLR-16462: I think what you described makes sense and think that your second approach feels more like the right way to handle it. Keeping state in a static field could solve the issue, but I agree that is feels a little off. I think having some kind of object that was coupled to the CoreContainer would be a good approach. With either approach, where would the "async" handling logic happen? My initial thought would be we could still have a base class with a method that handles submitting the work to an executor, but the developer would have to know to call that method when writing their API Resource and would have to be responsible for returning early. Also, would handling this async work at the Resource level be too far down (up?) the stack? What I like about the current V1 system is that an author of an operation doesn't have to concern themselves with whether they're code is being called synchronously or asynchrously (insofar as I can tell). Would it make sense to have the CoreContainer hold an object that *wraps* the ApplicationHandler? If we did that, then when V2HttpCall.invokeJerseyRequest calls jerseyHandler.handle (line 371), it'll first go through our async tracking logic (in our new object) before routing into the actual ApplicationHandler logic. > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (core level) > -- > > Key: SOLR-16462 > URL: https://issues.apache.org/jira/browse/SOLR-16462 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.1 >Reporter: Sanjay Dutt >Priority: Major > Labels: V2, newdev > Time Spent: 1h > Remaining Estimate: 0h > > Snapshot API has no v2 equivalent. This ticket is to track changes made to > the Solr to add v2 equivalent of 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' api. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16462) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (core level)
[ https://issues.apache.org/jira/browse/SOLR-16462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623963#comment-17623963 ] John Durham edited comment on SOLR-16462 at 10/25/22 6:09 PM: -- Sure thing! The PR should be available here: [https://github.com/apache/solr/pull/1126]. I spent a little bit of time thinking through how to make the async handling code usable by both the original V1 flow and the new V2 resources, but I haven't found a solution yet (at least not a convoluted one). was (Author: jdurham): Sure thing! The PR should be available [here|[https://github.com/apache/solr/pull/1126].] I spent a little bit of time thinking through how to make the async handling code usable by both the original V1 flow and the new V2 resources, but I haven't found a solution yet (at least not a convoluted one). > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (core level) > -- > > Key: SOLR-16462 > URL: https://issues.apache.org/jira/browse/SOLR-16462 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.1 >Reporter: Sanjay Dutt >Priority: Major > Labels: V2, newdev > Time Spent: 10m > Remaining Estimate: 0h > > Snapshot API has no v2 equivalent. This ticket is to track changes made to > the Solr to add v2 equivalent of 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' api. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16462) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (core level)
[ https://issues.apache.org/jira/browse/SOLR-16462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623963#comment-17623963 ] John Durham commented on SOLR-16462: Sure thing! The PR should be available [here|[https://github.com/apache/solr/pull/1126].] I spent a little bit of time thinking through how to make the async handling code usable by both the original V1 flow and the new V2 resources, but I haven't found a solution yet (at least not a convoluted one). > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (core level) > -- > > Key: SOLR-16462 > URL: https://issues.apache.org/jira/browse/SOLR-16462 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.1 >Reporter: Sanjay Dutt >Priority: Major > Labels: V2, newdev > Time Spent: 10m > Remaining Estimate: 0h > > Snapshot API has no v2 equivalent. This ticket is to track changes made to > the Solr to add v2 equivalent of 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' api. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16462) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (core level)
[ https://issues.apache.org/jira/browse/SOLR-16462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622882#comment-17622882 ] John Durham commented on SOLR-16462: Hi [~gerlowskija] - I think I'm getting fairly close to being ready to submit a PR for this work, but while working through updates to the reference documentation, I discovered that the new JerseyResource based V2 API I wrote isn't handling the "async" query parameter (effectively no-op). Digging through the CoreAdminHandler code, I noticed that when the async parameter is present in a V1 API call, the handleRequestBody method takes care of submitting the call to a parallelExecutor. From what I can tell, V2 JerseyResource based calls wouldn't go through that code path, hence the async parameter not being handled. Is there an existing Filter/Interceptor I'm missing that needs to be included for JerseyResource based APIs or is that something that hasn't been implemented elsewhere yet? > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (core level) > -- > > Key: SOLR-16462 > URL: https://issues.apache.org/jira/browse/SOLR-16462 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.1 >Reporter: Sanjay Dutt >Priority: Major > Labels: V2, newdev > > Snapshot API has no v2 equivalent. This ticket is to track changes made to > the Solr to add v2 equivalent of 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' api. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16462) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (core level)
[ https://issues.apache.org/jira/browse/SOLR-16462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17618188#comment-17618188 ] John Durham edited comment on SOLR-16462 at 10/16/22 12:23 AM: --- Hello - if no one else is currently working through this sub-task, I'd like to volunteer to implement it. From what I gather, this ticket is just for the three core APIs, so I'll focus on those. I've read through the some of the discussion on the parent ticket's thread, have already done a little poking around in the CoreAdminHandler, and I think I see where the changes need to be made. was (Author: jdurham): Hello - if no one else is currently working through this sub-task, I'd like to volunteer to implement it. From what I gather, this ticket is just for the three core APIs. I've read through the some of the discussion on the parent ticket's thread, have already done a little poking around in the CoreAdminHandler, and I think I see where the changes need to be made. > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (core level) > -- > > Key: SOLR-16462 > URL: https://issues.apache.org/jira/browse/SOLR-16462 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.1 >Reporter: Sanjay Dutt >Priority: Major > Labels: V2, newdev > > Snapshot API has no v2 equivalent. This ticket is to track changes made to > the Solr to add v2 equivalent of 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' api. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16462) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (core level)
[ https://issues.apache.org/jira/browse/SOLR-16462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17618188#comment-17618188 ] John Durham commented on SOLR-16462: Hello - if no one else is currently working through this sub-task, I'd like to volunteer to implement it. From what I gather, this ticket is just for the three core APIs. I've read through the some of the discussion on the parent ticket's thread, have already done a little poking around in the CoreAdminHandler, and I think I see where the changes need to be made. > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (core level) > -- > > Key: SOLR-16462 > URL: https://issues.apache.org/jira/browse/SOLR-16462 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.1 >Reporter: Sanjay Dutt >Priority: Major > Labels: V2, newdev > > Snapshot API has no v2 equivalent. This ticket is to track changes made to > the Solr to add v2 equivalent of 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' api. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15480) Tuple clone and copy constructor are inconsistent
[ https://issues.apache.org/jira/browse/SOLR-15480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17391042#comment-17391042 ] John Durham commented on SOLR-15480: I submitted a PR on Github here that should hopefully resolve this issue. https://github.com/apache/solr/pull/243 > Tuple clone and copy constructor are inconsistent > - > > Key: SOLR-15480 > URL: https://issues.apache.org/jira/browse/SOLR-15480 > Project: Solr > Issue Type: Task >Reporter: Mike Drob >Priority: Major > Labels: newdev > Time Spent: 10m > Remaining Estimate: 0h > > Discovered by [~cpoerschke] while reviewing SOLR-15385: > The Tuple clone and merge methods do not preserve EOF and Exception markers, > while the copy constructor will preserve it. However, the copy constructor is > susceptible to several rounds of rehashing because it does not use bulk > putAll. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15480) Tuple clone and copy constructor are inconsistent
[ https://issues.apache.org/jira/browse/SOLR-15480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17391028#comment-17391028 ] John Durham commented on SOLR-15480: Hi, I've been using Solr for a few years now, but haven't worked on it directly. I'd be willing to submit some code for this issue to get my feet wet! > Tuple clone and copy constructor are inconsistent > - > > Key: SOLR-15480 > URL: https://issues.apache.org/jira/browse/SOLR-15480 > Project: Solr > Issue Type: Task >Reporter: Mike Drob >Priority: Major > Labels: newdev > > Discovered by [~cpoerschke] while reviewing SOLR-15385: > The Tuple clone and merge methods do not preserve EOF and Exception markers, > while the copy constructor will preserve it. However, the copy constructor is > susceptible to several rounds of rehashing because it does not use bulk > putAll. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
