[
https://issues.apache.org/jira/browse/SOLR-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-4455:
---------------------------
Description:
I have a field in {{schema.xml}} defined like this:
{code:xml}
<field name="timestamp" type="date" indexed="true" stored="true" default="NOW"
/>
{code}
When I perform a query that's load-balanced across the servers in my cloud, the
value stored in that field differs slightly between each replica for the same
returned document.
I haven't seen this field differ by more than a tenth of a second and I'm not
running queries against it, but I can picture a situation where somebody has
one replica returning 23:59:59.990 and another returning 00:00:00.010 and a
query starts behaving oddly.
It seems like the leader should evaluate what "NOW" means and the replicas
should copy that value.
{panel:title=Possible Workaround}
A possible workaround for this issue is to use the
TimestampUpdateProcessorFactory in your update processor chain prior to the
DistributedUpdateProcessor instead of relying on the using "NOW" as a default
value for date fields.
This will cause the timestamp field of each document to be filled in with a
value before the documents are forwarded to any shards (or written to the
transaction log)
https://lucene.apache.org/solr/4_1_0/solr-core/org/apache/solr/update/processor/TimestampUpdateProcessorFactory.html
{panel}
was:
I have a field in {{schema.xml}} defined like this:
{code:xml}
<field name="timestamp" type="date" indexed="true" stored="true" default="NOW"
/>
{code}
When I perform a query that's load-balanced across the servers in my cloud, the
value stored in that field differs slightly between each replica for the same
returned document.
I haven't seen this field differ by more than a tenth of a second and I'm not
running queries against it, but I can picture a situation where somebody has
one replica returning 23:59:59.990 and another returning 00:00:00.010 and a
query starts behaving oddly.
It seems like the leader should evaluate what "NOW" means and the replicas
should copy that value.
updated issue description with a suggested workaround of using the
TimestampUpdateProcessorFactory
> Stored value of "NOW" differs between replicas
> ----------------------------------------------
>
> Key: SOLR-4455
> URL: https://issues.apache.org/jira/browse/SOLR-4455
> Project: Solr
> Issue Type: Bug
> Components: update
> Affects Versions: 4.1
> Reporter: Colin Bartolome
> Assignee: Hoss Man
> Priority: Minor
> Attachments: SOLR-4455.patch
>
>
> I have a field in {{schema.xml}} defined like this:
> {code:xml}
> <field name="timestamp" type="date" indexed="true" stored="true"
> default="NOW" />
> {code}
> When I perform a query that's load-balanced across the servers in my cloud,
> the value stored in that field differs slightly between each replica for the
> same returned document.
> I haven't seen this field differ by more than a tenth of a second and I'm not
> running queries against it, but I can picture a situation where somebody has
> one replica returning 23:59:59.990 and another returning 00:00:00.010 and a
> query starts behaving oddly.
> It seems like the leader should evaluate what "NOW" means and the replicas
> should copy that value.
> {panel:title=Possible Workaround}
> A possible workaround for this issue is to use the
> TimestampUpdateProcessorFactory in your update processor chain prior to the
> DistributedUpdateProcessor instead of relying on the using "NOW" as a default
> value for date fields.
> This will cause the timestamp field of each document to be filled in with a
> value before the documents are forwarded to any shards (or written to the
> transaction log)
> https://lucene.apache.org/solr/4_1_0/solr-core/org/apache/solr/update/processor/TimestampUpdateProcessorFactory.html
> {panel}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
