You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Webster Homer <we...@sial.com> on 2017/06/05 18:52:57 UTC
Solr collections Async status is nearly useless
the collections-api has a call to retrieve the async status.
All this does is tell you failure/success. and a message:
found [9cfb05af-b778-416e-b3c6-8b8e62345f4e] in failed tasks
It would be nice if instead it retrieved the information written to the
failed tasks queue!
So I used the zkcli.sh command to retrieve it to a file, but the data
retrieved is binary. How do I convert it to utf-8 and a readable format?
I have noticed that sometimes collections api calls timeout after 180
seconds when run synchronously, but the job actually seems to be serviced
as an asynchronous job. If I could easily find these in the /overseer
collection maps it would help immensely, but they need to be readable, or
have a documented api for reading them
also a minor issue. The async job id was
9cfb05af-b778-416e-b3c6-8b8e62345f4e but in failed tasks it was mapped as
mn-9cfb05af-b778-416e-b3c6-8b8e62345f4e. Why the "mn-" prepended to the
async ID?
--
This message and any attachment are confidential and may be privileged or
otherwise protected from disclosure. If you are not the intended recipient,
you must not copy this message or attachment or disclose the contents to
any other person. If you have received this transmission in error, please
notify the sender immediately and delete the message and any attachment
from your system. Merck KGaA, Darmstadt, Germany and any of its
subsidiaries do not accept liability for any omissions or errors in this
message which may arise as a result of E-Mail-transmission or for damages
resulting from any unauthorized changes of the content of this message and
any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its
subsidiaries do not guarantee that this message is free of viruses and does
not accept liability for any damages caused by any virus transmitted
therewith.
Click http://www.emdgroup.com/disclaimer to access the German, French,
Spanish and Portuguese versions of this disclaimer.
Re: Solr collections Async status is nearly useless
Posted by Webster Homer <we...@sial.com>.
So I figured out that the binary format is the serialized version of the
org.apache.solr.cloud.OverseerSolrResponse class. However, this class isn't
in solrj so I'm not sure how I can deserialize its contents. This looks
like a poor choice by a developer to not have this in the Solrj library.
On Mon, Jun 5, 2017 at 1:52 PM, Webster Homer <we...@sial.com>
wrote:
> the collections-api has a call to retrieve the async status.
>
> All this does is tell you failure/success. and a message:
> found [9cfb05af-b778-416e-b3c6-8b8e62345f4e] in failed tasks
>
> It would be nice if instead it retrieved the information written to the
> failed tasks queue!
>
> So I used the zkcli.sh command to retrieve it to a file, but the data
> retrieved is binary. How do I convert it to utf-8 and a readable format?
>
> I have noticed that sometimes collections api calls timeout after 180
> seconds when run synchronously, but the job actually seems to be serviced
> as an asynchronous job. If I could easily find these in the /overseer
> collection maps it would help immensely, but they need to be readable, or
> have a documented api for reading them
>
> also a minor issue. The async job id was 9cfb05af-b778-416e-b3c6-
> 8b8e62345f4e but in failed tasks it was mapped as mn-
> 9cfb05af-b778-416e-b3c6-8b8e62345f4e. Why the "mn-" prepended to the
> async ID?
>
--
This message and any attachment are confidential and may be privileged or
otherwise protected from disclosure. If you are not the intended recipient,
you must not copy this message or attachment or disclose the contents to
any other person. If you have received this transmission in error, please
notify the sender immediately and delete the message and any attachment
from your system. Merck KGaA, Darmstadt, Germany and any of its
subsidiaries do not accept liability for any omissions or errors in this
message which may arise as a result of E-Mail-transmission or for damages
resulting from any unauthorized changes of the content of this message and
any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its
subsidiaries do not guarantee that this message is free of viruses and does
not accept liability for any damages caused by any virus transmitted
therewith.
Click http://www.emdgroup.com/disclaimer to access the German, French,
Spanish and Portuguese versions of this disclaimer.