Skip to content

#626: Add routing field in metadata - Solr StatusUpdaterBolt #1242

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Jul 25, 2024

Conversation

mvolikas
Copy link
Contributor

@mvolikas mvolikas commented Jun 15, 2024

#626 Now one can specify a routing key, which is added to the status metadata.

@rzo1 rzo1 requested a review from jnioche June 17, 2024 08:03
@rzo1 rzo1 added this to the 3.1.0 milestone Jun 17, 2024
@jnioche
Copy link
Contributor

jnioche commented Jun 24, 2024

do we need doRouting at all? Not sure how the routing is done for SOLR, is it via the collection definition or the indexing API as in OpenSearch?

@rzo1
Copy link
Contributor

rzo1 commented Jun 26, 2024

do we need doRouting at all? Not sure how the routing is done for SOLR, is it via the collection definition or the indexing API as in OpenSearch?

At least the variable is never used, so might be dropped.

@mvolikas
Copy link
Contributor Author

do we need doRouting at all?

I'm aware that doRouting is not currently used. I left the variable for use in #620 but we can remove it for now.

Not sure how the routing is done for SOLR, is it via the collection definition or the indexing API as in OpenSearch?

If I'm not mistaken it depends on the router.name specified when creating the collection. I was thinking to use the compositeId option so that we do not manually specify the destination shard during indexing.

@jnioche
Copy link
Contributor

jnioche commented Jun 29, 2024

do we need doRouting at all?

I'm aware that doRouting is not currently used. I left the variable for use in #620 but we can remove it for now.

yes please, let's add it back later with the rest of the code that relies on it

Not sure how the routing is done for SOLR, is it via the collection definition or the indexing API as in OpenSearch?

If I'm not mistaken it depends on the router.name specified when creating the collection. I was thinking to use the compositeId option so that we do not manually specify the destination shard during indexing.

I suppose what we need is to use

router.field (v1), router (v2)

and point it to the key field, otherwise it will take the unique document key. Is that correct?

@mvolikas
Copy link
Contributor Author

mvolikas commented Jul 2, 2024

and point it to the key field, otherwise it will take the unique document key. Is that correct?

Yes, you are right - thanks for noting!

@jnioche
Copy link
Contributor

jnioche commented Jul 5, 2024

and point it to the key field, otherwise it will take the unique document key. Is that correct?

Yes, you are right - thanks for noting!

where should router.field=key be specified? in solrconfig.xml?

@mvolikas
Copy link
Contributor Author

mvolikas commented Jul 24, 2024

Thanks for the patience - I just found some time to look again into this :-)

where should router.field=key be specified? in solrconfig.xml?

I don't think this will work. The router.field is configured during the collection creation with the Collections API. (collection specific)

So, for #620 we could do the following:

  • Add a new property solr.status.routing.shards: 10 to solr-conf.yaml.
  • Add a script that creates the "status" collection with the numShards equal to the property above, and the router.field equal to the solr.status.routing.fieldname: "key".
  • The user should make sure that the SolrSpout parallelism equals the number of shards specified.

@jnioche
Copy link
Contributor

jnioche commented Jul 24, 2024

Thanks @mvolikas
Ok so the logic will be done in #620 so for this one we just need to remove SolrStatusRoutingParamName, correct?

@mvolikas
Copy link
Contributor Author

Yes, this variable is #620 related and was unused. I removed it for this PR.

@jnioche jnioche merged commit cb02ce9 into apache:main Jul 25, 2024
4 checks passed
@jnioche
Copy link
Contributor

jnioche commented Jul 25, 2024

Thanks @mvolikas

@mvolikas mvolikas deleted the feature-626 branch September 22, 2024 14:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants