[
https://issues.apache.org/jira/browse/SOLR-9883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-9883:
-----------------------------
Attachment: SOLR-9883.patch
Patch with a new automated data corruption test. I tried to make a cloud test,
but I couldn't get it to work. Instead, the test in the patch simulates this
situation by directly turning on tlog buffering mode in a single core, and
sending in an update (with param {{update.distrib=fromleader}}) after manually
running the "add-unknown-fields-to-schema" update chain on it up through the
DUP. The test succeeds with the solr config modifications in the patch, and
fails without it.
The patch also fixes a typos in the replay failure log message
({{REYPLAY}}->{{REPLAY}}).
I'm running all Solr tests and precommit now. When they succeed, I'll commit.
> example solr config files can lead to invalid tlog replays when using
> add-unknown-fields-to-schema updat chain
> --------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-9883
> URL: https://issues.apache.org/jira/browse/SOLR-9883
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 6.3, trunk
> Reporter: Erick Erickson
> Assignee: Steve Rowe
> Attachments: SOLR-9883.patch, SOLR-9883.patch
>
>
> The current basic_configs and data_driven_schema_configs try to create
> unknown fields. The problem is that the date processing
> "ParseDateFieldUpdateProcessorFactory" is not invoked if the doc is replayed
> from the tlog. Whether there are other places this is a problem I don't know,
> this is a concrete example that fails in the field.
> So say I have a pattern for dates that omits the trialing 'Z', as:
> yyyy-MM-dd'T'HH:mm:ss.SSS
> This work fine when the doc is initially indexed. Now say the doc must be
> replayed from the tlog. The doc errors out with "unknown date format" since
> (apparently) this doesn't go through the same update chain, perhaps due to
> the sample configs defining ParseDateFieldUpdateProcessorFactory after
> DistributedUpdateProcessorFactory?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]