There are several required fields - timestamp is one of them. All the required
fields are present in the document,
including a single element in the 'channel' array.
SOLR-6255 created. I'll try to reproduce with a minimal schema asap.
-- Nathan
On 07/17/2014 09:07 PM, Erick Erickson [via Lucen
Hmmm, is "channel" a multiValued field or not? I'm guessing that "id" is the
only required field, and if so the error message is misleading at best.
So yeah, it's probably a reasonable thing to open a JIRA. Please include the
schema file (as small as you can make it) and the JSON as well. Not
prom
Should I go ahead and submit this as a distinct bug issue w/ the query
parsing/json now that it's more clear what the problem is?
Jack Krupansky-2 wrote
> At least parts of Solr use semi-custom JSON parsing that allows repeating
> a
> map key, so either this particular feature didn't use that pa
Actually, turns out the 'intermittent' was our misinterpretation - we never
noticed that we were only occcasionally adding to two channels... Once I
figured that out, symptom is 100% repeatable and consistent.
Yonik Seeley-5 wrote
> On Wed, Jul 16, 2014 at 10:20 PM, Nathan Neulinger <
> nneul@
On Wed, Jul 16, 2014 at 10:20 PM, Nathan Neulinger wrote:
> [{"id":"4b2c4d09-31e2-4fe2-b767-3868efbdcda1","channel": {"add":
> "preet"},"channel": {"add": "adam"}}]
>
> Look at the JSON... It's trying to add two "channel" array elements...
> Should have been:
[...]
> From what I'm reading on JSON
Solr
side, if only better error reporting at a minimum.
-- Jack Krupansky
-Original Message-
From: Shalin Shekhar Mangar
Sent: Thursday, July 17, 2014 12:40 AM
To: solr-user@lucene.apache.org
Subject: Re: problem with replication/solrcloud - getting 'missing required
Phew, thanks for tracking it down.
On Thu, Jul 17, 2014 at 7:50 AM, Nathan Neulinger
wrote:
> FYI. We finally tracked down the problem at least 99.9% sure at this
> point, and it was staring me in the face the whole time - just never
> noticed:
>
> [{"id":"4b2c4d09-31e2-4fe2-b767-3868efbdcd
FYI. We finally tracked down the problem at least 99.9% sure at this point, and it was staring me in the face the
whole time - just never noticed:
[{"id":"4b2c4d09-31e2-4fe2-b767-3868efbdcda1","channel": {"add": "preet"},"channel":
{"add": "adam"}}]
Look at the JSON... It's trying to add t
It may have been a permissions problem, or it stared working after the master
had done another fresh scheduled full-import and jumped an index version.
Timestamp issue?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Problem-with-replication-tp2294313p3704559.html
Sent from th
Actually, I get:
No files to download for index generation:
this is after deleting the data directory on the slave.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Problem-with-replication-tp2294313p3704457.html
Sent from the Solr - User mailing list archive at Nabble.com.
We have tried that as well, but the slave still claims to have a higher index
version, even when the index files were deleted completely
Regards
Thomas
Stevo Slavić, 20.01.2011 16:52:
Not too elegant but valid check would be to bring slave down, delete
it's index data directory, then to commit
Not too elegant but valid check would be to bring slave down, delete
it's index data directory, then to commit a change to index to master,
then bring slave up, and wait for pollInterval to pass and replication
to occur.
Regards,
Stevo.
On Thu, Jan 20, 2011 at 4:16 PM, Thomas Kellerer wrote:
> S
Stevo Slavić, 20.01.2011 15:42:
So if on startup index gets replicated, then commit probably isn't
being called anywhere on master.
No, the index is not replicated on startup (same behaviour: "no files to
download")
Is that index configured to autocommit on master, or do you commit
from appl
So if on startup index gets replicated, then commit probably isn't
being called anywhere on master.
Is that index configured to autocommit on master, or do you commit
from application code? If you commit from application code, check if
commit actually gets issued to the slave.
Regards,
Stevo.
On
Thomas Kellerer, 20.01.2011 12:53:
Hi all,
we have implemented a Solr based search in our web application. We
have one master server that maintains the index which is replicated
to the slaves using the built-in Solr replication.
This has been working fine so far, but suddenly the replication do
Here is our configuration:
true
commit
startup
stopwords.txt,stopwords_de.txt,stopwords_en.txt,synonyms.txt
Stevo Slavić, 20.01.2011 13:26:
On which events did you configure master to perform replication? replicateAfter
Regards,
Stevo.
On Thu, Jan 20, 2011 at 12:53 PM, Thomas Ke
On which events did you configure master to perform replication? replicateAfter
Regards,
Stevo.
On Thu, Jan 20, 2011 at 12:53 PM, Thomas Kellerer wrote:
> Hi all,
>
> we have implemented a Solr based search in our web application. We have one
> master server that maintains the index which is rep
17 matches
Mail list logo
