[jira] [Commented] (SOLR-4455) Stored value of "NOW" differs between replicas
[
https://issues.apache.org/jira/browse/SOLR-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16481314#comment-16481314
]
Hoss Man commented on SOLR-4455:
AFAIK this is still an open problem, and using TimestampUpdateProcessorFactory
prior to DistributedUpdateProcessorFactory is still the best solution -- it
ensures that the timestamp is generated prior to forwarding the doc to shards
*AND* before writing to the tlog, so even if a replica recovers later, the same
value will be used.
> 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}
> 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
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4455) Stored value of "NOW" differs between replicas
[
https://issues.apache.org/jira/browse/SOLR-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479154#comment-16479154
]
Erick Erickson commented on SOLR-4455:
--
[~hossman]Is this still current? Happened to run across it searching for
something else.
> 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}
> 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
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4455) Stored value of NOW differs between replicas
[
https://issues.apache.org/jira/browse/SOLR-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680876#comment-14680876
]
Supriya Bommareddy commented on SOLR-4455:
--
Calling the DistributedUpdateProcessoryFactory after the
LogUpdateProcessoryFactory as shown below worked.
{code}
updateRequestProcessorChain name=timestamp default=true
processor class=solr.TimestampUpdateProcessorFactory
str name=fieldNametimestamp/str
/processor
processor class=solr.LogUpdateProcessorFactory /
processor class=solr.DistributedUpdateProcessorFactory/
processor class=solr.RunUpdateProcessorFactory /
/updateRequestProcessorChain
{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
[jira] [Commented] (SOLR-4455) Stored value of NOW differs between replicas
[
https://issues.apache.org/jira/browse/SOLR-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662292#comment-14662292
]
Supriya Bommareddy commented on SOLR-4455:
--
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.chaintimestamp/str
/lst
/requestHandler
updateRequestProcessorChain name=timestamp default=true
processor class=solr.TimestampUpdateProcessorFactory
str name=fieldNametimestamp/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
[jira] [Commented] (SOLR-4455) Stored value of NOW differs between replicas
[
https://issues.apache.org/jira/browse/SOLR-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13643088#comment-13643088
]
Colin Bartolome commented on SOLR-4455:
---
That workaround seems to work perfectly. Thanks!
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4455) Stored value of NOW differs between replicas
[
https://issues.apache.org/jira/browse/SOLR-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13578250#comment-13578250
]
Jan Høydahl commented on SOLR-4455:
---
+1
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
Priority: Minor
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.
--
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4455) Stored value of NOW differs between replicas
[
https://issues.apache.org/jira/browse/SOLR-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13578083#comment-13578083
]
Hoss Man commented on SOLR-4455:
bq. It seems like the leader should evaluate what NOW means and the replicas
should copy that value.
Hmm... we actually have all the logic to do this, and i know it's being used
for distributed queries, but i guess maybe the value isn't being forwarded in
the DistributedUpdateProcessor?
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
Priority: Minor
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.
--
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
