Sure. Here is an example of ADDREPLICA in synchronous mode: http://localhost:8983/solr/admin/collections?action=addreplica&collection=293&shard=shard1_1
response: <response> <lst name="responseHeader"> <int name="status">0</int> <int name="QTime">1168</int> </lst> <lst name="success"> <lst> <lst name="responseHeader"> <int name="status">0</int> <int name="QTime">1158</int> </lst> <str name="core">293_shard1_1_replica2</str> </lst> </lst> </response> And here is the same in asynchronous mode: http://localhost:8983/solr/admin/collections?action=addreplica&collection=293&shard=shard1_1&async=foo99 response: <response> <lst name="responseHeader"> <int name="status">0</int> <int name="QTime">2</int> </lst> <str name="requestid">foo99</str> </response> Note that the format of this response does NOT match the response format that I got from the attempt at an async DELETESHARD in my earlier email. Also note that I am now able to query for the status of this request: http://localhost:8983/solr/admin/collections?action=requeststatus&requestid=foo99 response: <response> <lst name="responseHeader"> <int name="status">0</int> <int name="QTime">0</int> </lst> <lst name="status"> <str name="state">completed</str> <str name="msg">found foo99 in completed tasks</str> </lst> </response> On Tue, Apr 28, 2015 at 2:06 PM, Anshum Gupta <ans...@anshumgupta.net> wrote: > Hi Ian, > > What do you mean by "*my testing shows*" ? Can you elaborate on the steps > and how did you confirm that the call was indeed *async* ? > I may be wrong but I think what you're seeing is a normal DELETEREPLICA > call succeeding behind the scenes. It is not treated or processed as an > async call. > > Also, that page is the official reference guide and might need fixing if > it's out of sync. > > > On Tue, Apr 28, 2015 at 10:47 AM, Ian Rose <ianr...@fullstory.com> wrote: > > > Hi Anshum, > > > > FWIW I find that page is not entirely accurate with regard to async > > params. For example, my testing shows that DELETEREPLICA *does* support > > the async param, although that is not listed here: > > > > > https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api9 > > > > Cheers, > > Ian > > > > > > On Tue, Apr 28, 2015 at 12:47 PM, Anshum Gupta <ans...@anshumgupta.net> > > wrote: > > > > > Hi Ian, > > > > > > DELETESHARD doesn't support ASYNC calls officially. We could certainly > do > > > with a better response but I believe with most of the Collections API > > calls > > > at this time in Solr, you could send random params which would get > > ignored. > > > Therefore, in this case, I believe that the async param gets ignored. > > > > > > The go-to reference point to check what's supported is the official > > > reference guide: > > > > > > > > > https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api7 > > > > > > This doesn't mentioned support for async DELETESHARD calls. > > > > > > On Tue, Apr 28, 2015 at 8:05 AM, Ian Rose <ianr...@fullstory.com> > wrote: > > > > > > > Is it possible to run DELETESHARD commands in async mode? Google > > > searches > > > > seem to indicate yes, but not definitively. > > > > > > > > My local experience indicates otherwise. If I start with an async > > > > SPLITSHARD like so: > > > > > > > > > > > > > > > > > > http://localhost:8983/solr/admin/collections?action=splitshard&collection=2Gp&shard=shard1_0_0&async=12-foo-1 > > > > > > > > Then I get back the expected response format, with <str > > name="requestid"> > > > > 12-foo-1</str> > > > > > > > > And I can later query for the result via REQUESTSTATUS. > > > > > > > > However if I try an async DELETESHARD like so: > > > > > > > > > > > > > > > > > > http://localhost:8983/solr/admin/collections?action=deleteshard&collection=2Gp&shard=shard1_0_0&async=12-foo-4 > > > > > > > > The response includes the command result, indicating that the command > > was > > > > not run async: > > > > > > > > <lst name="success"> > > > > <lst name="192.168.1.106:8983_solr"> > > > > <lst name="responseHeader"> > > > > <int name="status">0</int> > > > > <int name="QTime">16</int> > > > > </lst> > > > > </lst> > > > > </lst> > > > > > > > > And in addition REQUESTSTATUS calls for that requestId fail with "Did > > not > > > > find taskid [12-foo-4] in any tasks queue". > > > > > > > > Synchronous deletes are causing problems for me in production as they > > are > > > > timing out in some cases. > > > > > > > > Thanks, > > > > Ian > > > > > > > > > > > > p.s. I'm on version 5.0.0 > > > > > > > > > > > > > > > > -- > > > Anshum Gupta > > > > > > > > > -- > Anshum Gupta >
