Skip to content
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

[SOLR-11209] Upgrade HttpClient to 4.5.3 #230

Closed
wants to merge 1 commit into from

Conversation

hgadre
Copy link

@hgadre hgadre commented Aug 11, 2017

No description provided.

@ctargett
Copy link
Contributor

https://issues.apache.org/jira/browse/SOLR-11209 was released in Solr 7.3, so this PR can be closed.

@ctargett ctargett closed this Jan 18, 2019
cpoerschke pushed a commit to cpoerschke/lucene-solr that referenced this pull request Apr 5, 2019
* sketch: [SkipSecondStep]SearchGroupShardResponseProcessor with inner [SkipSecondStep]SearchGroupsContainer helper class

* sketch: remove/replace SearchGroupsResultTransformer.getInstance

* Callers instead directly allocate either DefaultSearchResultResultTransformer or SkipSecondStepSearchResultResultTransformer.
* A next step could be the proposed SearchGroupsResultTransformer.SkipSecondStepSearchResultResultTransformer inner class to become a SkipSecondStepSearchResultResultTransformer.java class of its own and the proposed SearchGroupsResultTransformer.DefaultSearchResultResultTransformer inner class to _not_ be created with backcompat considerations in mind e.g. SearchGroupsResultTransformer to not become abstract and its constructor to remain public. This assumes that SearchGroupsResultTransformer would require only simple changes to make it extensible and that then SkipSecondStepSearchResultResultTransformer could extend it.
cpoerschke pushed a commit to cpoerschke/lucene-solr that referenced this pull request Jun 14, 2019
* sketch: [SkipSecondStep]SearchGroupShardResponseProcessor with inner [SkipSecondStep]SearchGroupsContainer helper class

* sketch: remove/replace SearchGroupsResultTransformer.getInstance

* Callers instead directly allocate either DefaultSearchResultResultTransformer or SkipSecondStepSearchResultResultTransformer.
* A next step could be the proposed SearchGroupsResultTransformer.SkipSecondStepSearchResultResultTransformer inner class to become a SkipSecondStepSearchResultResultTransformer.java class of its own and the proposed SearchGroupsResultTransformer.DefaultSearchResultResultTransformer inner class to _not_ be created with backcompat considerations in mind e.g. SearchGroupsResultTransformer to not become abstract and its constructor to remain public. This assumes that SearchGroupsResultTransformer would require only simple changes to make it extensible and that then SkipSecondStepSearchResultResultTransformer could extend it.
cpoerschke pushed a commit to cpoerschke/lucene-solr that referenced this pull request Aug 6, 2019
…gas patch)

Summary:
In cases where we do grouping and ask for  {{group.limit=1}} only it is possible to skip the second grouping step. In our test datasets it improved speed by around 40%.

Essentially, in the first grouping step each shard returns the top K groups based on the highest scoring document in each group. The top K groups from each shard are merged in the federator and in the second step we ask all the shards to return the top documents from each of the top ranking groups.

If we only want to return the highest scoring document per group we can return the top document id in the first step, merge results in the federator to retain the top K groups and then skip the second grouping step entirely.

QueryComponent: interim 'make it compile (somehow)' change (apache#228)

add SearchGroupsContainer (apache#230)

factor out SearchGroupsResultTransformer.serializeOneSearchGroup method (Christine)

Refactor transformToNative adding deserializeOneSearchGroup

 increase GroupParams.GROUP_SKIP_DISTRIBUTED_SECOND use (see also 6bdf87)

Remove error logging in allowSkipSecondGroupingStep

Check that withinGroupSort is a prefix of groupSort

SkipSecondStepSearchGroupShardResponseProcessor.addSearchGroupToShards now leaves ShardDoc.fields null

factor out TopGroupsShardResponseProcessor.fillResultIds method

Add regression test group.main=true and group.format=simple

Improve GroupingSpecification validation adding validate() method

SkipSecondStepSearchResultResultTransformer.serializeOneSearchGroup tweaks
cpoerschke pushed a commit to cpoerschke/lucene-solr that referenced this pull request Sep 6, 2019
…gas patch)

Summary:
In cases where we do grouping and ask for  {{group.limit=1}} only it is possible to skip the second grouping step. In our test datasets it improved speed by around 40%.

Essentially, in the first grouping step each shard returns the top K groups based on the highest scoring document in each group. The top K groups from each shard are merged in the federator and in the second step we ask all the shards to return the top documents from each of the top ranking groups.

If we only want to return the highest scoring document per group we can return the top document id in the first step, merge results in the federator to retain the top K groups and then skip the second grouping step entirely.

QueryComponent: interim 'make it compile (somehow)' change (apache#228)

add SearchGroupsContainer (apache#230)

factor out SearchGroupsResultTransformer.serializeOneSearchGroup method (Christine)

Refactor transformToNative adding deserializeOneSearchGroup

 increase GroupParams.GROUP_SKIP_DISTRIBUTED_SECOND use (see also 6bdf87)

Remove error logging in allowSkipSecondGroupingStep

Check that withinGroupSort is a prefix of groupSort

SkipSecondStepSearchGroupShardResponseProcessor.addSearchGroupToShards now leaves ShardDoc.fields null

factor out TopGroupsShardResponseProcessor.fillResultIds method

Add regression test group.main=true and group.format=simple

Improve GroupingSpecification validation adding validate() method

SkipSecondStepSearchResultResultTransformer.serializeOneSearchGroup tweaks
cpoerschke pushed a commit to cpoerschke/lucene-solr that referenced this pull request Nov 22, 2019
…gas patch)

Summary:
In cases where we do grouping and ask for  {{group.limit=1}} only it is possible to skip the second grouping step. In our test datasets it improved speed by around 40%.

Essentially, in the first grouping step each shard returns the top K groups based on the highest scoring document in each group. The top K groups from each shard are merged in the federator and in the second step we ask all the shards to return the top documents from each of the top ranking groups.

If we only want to return the highest scoring document per group we can return the top document id in the first step, merge results in the federator to retain the top K groups and then skip the second grouping step entirely.

QueryComponent: interim 'make it compile (somehow)' change (apache#228)

add SearchGroupsContainer (apache#230)

factor out SearchGroupsResultTransformer.serializeOneSearchGroup method (Christine)

Refactor transformToNative adding deserializeOneSearchGroup

 increase GroupParams.GROUP_SKIP_DISTRIBUTED_SECOND use (see also 6bdf87)

Remove error logging in allowSkipSecondGroupingStep

Check that withinGroupSort is a prefix of groupSort

SkipSecondStepSearchGroupShardResponseProcessor.addSearchGroupToShards now leaves ShardDoc.fields null

factor out TopGroupsShardResponseProcessor.fillResultIds method

Add regression test group.main=true and group.format=simple

Improve GroupingSpecification validation adding validate() method

SkipSecondStepSearchResultResultTransformer.serializeOneSearchGroup tweaks
diegoceccarelli pushed a commit to diegoceccarelli/lucene-solr that referenced this pull request Dec 4, 2019
…gas patch)

Summary:
In cases where we do grouping and ask for  {{group.limit=1}} only it is possible to skip the second grouping step. In our test datasets it improved speed by around 40%.

Essentially, in the first grouping step each shard returns the top K groups based on the highest scoring document in each group. The top K groups from each shard are merged in the federator and in the second step we ask all the shards to return the top documents from each of the top ranking groups.

If we only want to return the highest scoring document per group we can return the top document id in the first step, merge results in the federator to retain the top K groups and then skip the second grouping step entirely.

QueryComponent: interim 'make it compile (somehow)' change (apache#228)

add SearchGroupsContainer (apache#230)

factor out SearchGroupsResultTransformer.serializeOneSearchGroup method (Christine)

Refactor transformToNative adding deserializeOneSearchGroup

 increase GroupParams.GROUP_SKIP_DISTRIBUTED_SECOND use (see also 6bdf87)

Remove error logging in allowSkipSecondGroupingStep

Check that withinGroupSort is a prefix of groupSort

SkipSecondStepSearchGroupShardResponseProcessor.addSearchGroupToShards now leaves ShardDoc.fields null

factor out TopGroupsShardResponseProcessor.fillResultIds method

Add regression test group.main=true and group.format=simple

Improve GroupingSpecification validation adding validate() method

SkipSecondStepSearchResultResultTransformer.serializeOneSearchGroup tweaks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants