[jira] [Commented] (SOLR-14443) Make SolrLogPostTool resilient to unexpected requests
[ https://issues.apache.org/jira/browse/SOLR-14443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114122#comment-17114122 ] ASF subversion and git services commented on SOLR-14443: Commit 322fe54715a646525b7b0c0717977092ca456be0 in lucene-solr's branch refs/heads/branch_8x from Jason Gerlowski [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=322fe54 ] SOLR-14443: Make SolrLogPostTool resilient to odd requests (#1525) > Make SolrLogPostTool resilient to unexpected requests > - > > Key: SOLR-14443 > URL: https://issues.apache.org/jira/browse/SOLR-14443 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Affects Versions: master (9.0) >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Trivial > Time Spent: 20m > Remaining Estimate: 0h > > When SolrLogPostTool parses log messages corresponding to incoming requests, > it sets various predefined fields based on the parameters on the request. > e.g. it sets a rows_i field, a wt_s field, and so on. > This logic works for most requests, but if the log-parser encounters requests > with multiple of these params (e.g. rows), it will blithely add them to the > SolrInputDocument, and error out when Solr rejects the eventual update > request because it is attempting to put multiple values into a single-valued > field. > We can do two things to fix this. > # Make SolrLogPostTool's "posting" code resilient to individual update > failures. It doesn't make any sense to crash the entire posting routine just > because one batch (or one log message) was malformed. > # Tweak the field parsing logic to be more resilient to the specific > "redundant query params" case I encountered specifically here. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14443) Make SolrLogPostTool resilient to unexpected requests
[ https://issues.apache.org/jira/browse/SOLR-14443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114071#comment-17114071 ] ASF subversion and git services commented on SOLR-14443: Commit 78f4a5b8ff854861ac6ad17c27016e222463e54c in lucene-solr's branch refs/heads/master from Jason Gerlowski [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=78f4a5b ] SOLR-14443: Make SolrLogPostTool resilient to odd requests (#1525) > Make SolrLogPostTool resilient to unexpected requests > - > > Key: SOLR-14443 > URL: https://issues.apache.org/jira/browse/SOLR-14443 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Affects Versions: master (9.0) >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Trivial > Time Spent: 10m > Remaining Estimate: 0h > > When SolrLogPostTool parses log messages corresponding to incoming requests, > it sets various predefined fields based on the parameters on the request. > e.g. it sets a rows_i field, a wt_s field, and so on. > This logic works for most requests, but if the log-parser encounters requests > with multiple of these params (e.g. rows), it will blithely add them to the > SolrInputDocument, and error out when Solr rejects the eventual update > request because it is attempting to put multiple values into a single-valued > field. > We can do two things to fix this. > # Make SolrLogPostTool's "posting" code resilient to individual update > failures. It doesn't make any sense to crash the entire posting routine just > because one batch (or one log message) was malformed. > # Tweak the field parsing logic to be more resilient to the specific > "redundant query params" case I encountered specifically here. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14443) Make SolrLogPostTool resilient to unexpected requests
[ https://issues.apache.org/jira/browse/SOLR-14443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110465#comment-17110465 ] Jason Gerlowski commented on SOLR-14443: Pushed up a PR for this. Changes are pretty trivial, so I'll merge by the end of the week if I don't get any feedback. > Make SolrLogPostTool resilient to unexpected requests > - > > Key: SOLR-14443 > URL: https://issues.apache.org/jira/browse/SOLR-14443 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Affects Versions: master (9.0) >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Trivial > Time Spent: 10m > Remaining Estimate: 0h > > When SolrLogPostTool parses log messages corresponding to incoming requests, > it sets various predefined fields based on the parameters on the request. > e.g. it sets a rows_i field, a wt_s field, and so on. > This logic works for most requests, but if the log-parser encounters requests > with multiple of these params (e.g. rows), it will blithely add them to the > SolrInputDocument, and error out when Solr rejects the eventual update > request because it is attempting to put multiple values into a single-valued > field. > We can do two things to fix this. > # Make SolrLogPostTool's "posting" code resilient to individual update > failures. It doesn't make any sense to crash the entire posting routine just > because one batch (or one log message) was malformed. > # Tweak the field parsing logic to be more resilient to the specific > "redundant query params" case I encountered specifically here. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
