[
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: [email protected]
For additional commands, e-mail: [email protected]
