[ 
https://issues.apache.org/jira/browse/SOLR-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14662292#comment-14662292
 ] 

Supriya Bommareddy edited comment on SOLR-4455 at 8/7/15 7:20 PM:
------------------------------------------------------------------

I tried the workaround with the following changes in my solrconfig.xml and its 
not working. I have solr-5.2.1 installed.

NOTE: I am not sending the timestamp field in the document and I am updating 
the document via the admin console UI.

{code}
 <requestHandler name="/update" class="solr.UpdateRequestHandler">
    <!-- See below for information on defining
         updateRequestProcessorChains that can be used by name
         on each Update Request
      -->
       <lst name="defaults">
         <str name="update.chain">timestamp</str>
       </lst>
  </requestHandler>



 <updateRequestProcessorChain name="timestamp" default="true">
          <processor class="solr.TimestampUpdateProcessorFactory">
               <str name="fieldName">timestamp</str>
          </processor>
          <processor class="solr.DistributedUpdateProcessorFactory"/>
          <processor class="solr.LogUpdateProcessorFactory" />
          <processor class="solr.RunUpdateProcessorFactory" />
     </updateRequestProcessorChain>

{code}

*********************************************************************************************************
schema.xml has the below entry

{code}
<field name="timestamp" type="date" indexed="true" stored="true" 
multiValued="false"/>
<fieldType name="date" class="solr.TrieDateField" precisionStep="0" 
positionIncrementGap="0"/>

{code}



was (Author: supreddy):
I tried the workaround with the following changes in my solrconfig.xml and its 
not working. I have solr-5.2.1 installed

{code}
 <requestHandler name="/update" class="solr.UpdateRequestHandler">
    <!-- See below for information on defining
         updateRequestProcessorChains that can be used by name
         on each Update Request
      -->
       <lst name="defaults">
         <str name="update.chain">timestamp</str>
       </lst>
  </requestHandler>



 <updateRequestProcessorChain name="timestamp" default="true">
          <processor class="solr.TimestampUpdateProcessorFactory">
               <str name="fieldName">timestamp</str>
          </processor>
          <processor class="solr.DistributedUpdateProcessorFactory"/>
          <processor class="solr.LogUpdateProcessorFactory" />
          <processor class="solr.RunUpdateProcessorFactory" />
     </updateRequestProcessorChain>

{code}

*********************************************************************************************************
schema.xml has the below entry

{code}
<field name="timestamp" type="date" indexed="true" stored="true" 
multiValued="false"/>
<fieldType name="date" class="solr.TrieDateField" precisionStep="0" 
positionIncrementGap="0"/>

{code}


> 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 was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to