On 15 December 2013 07:22, gpssolr2020 wrote:
>
> hi all,
>
> We are generating unique key(signaturefield) for solr based six unique
> fields from DB. The generated uniquekey is different in solr , when run
> through dataimport handler and updaterequesthandler for the same document
> though we are
As you can see by all the bugs introduced by the recent large scale
refactorings around core container, the tests will not prevent this. SolrCloud
is even worse in this regard - many things are difficult to test or rely on
timing or this or that. We could use way more tests than we have and even
hi all,
We are generating unique key(signaturefield) for solr based six unique
fields from DB. The generated uniquekey is different in solr , when run
through dataimport handler and updaterequesthandler for the same document
though we are calling the same update.chain for both.
So can any one ple
On 14 Dec 2013, at 19:58, Mark Miller wrote:
> I’ve looked at it over the years, but honestly, for most things, I don’t
> think switching would help much other than rewrite code that has been fairly
> hardened with fresh code that is just likely to introduce new bugs.
Well, that's what our com
I’ve looked at it over the years, but honestly, for most things, I don’t think
switching would help much other than rewrite code that has been fairly hardened
with fresh code that is just likely to introduce new bugs.
Targeted use of it for specific things could make sense, but that’s the type o
Yes, it is true that empty nested queries are not supported - your empty
parentheses. The exception is simply indicating that a right parenthesis is
not permissible immediately after a left parenthesis.
What effect were you trying to achieve? Or was that just a typo on your
part?
An empty to
Evening all,
I discovered the Apache Curator project yesterday
(http://curator.apache.org/index.html), which seems to make interaction with
Zookeeper much easier. What do people think about using it for SolrCloud? In
particular, the LeaderLatch, Barrier and NodeCache recipes would make the
O
Hmm…I think we shipped 4.4.0 on a pre hadoop 2.2.0 version? I’d assume that is
the problem - for instance, the goog protobuf lib prob has to be updated to
match what’s expected by 2.2.0 at the least if I remember right.
- Mark
On Dec 13, 2013, at 4:41 AM, javozzo wrote:
> Hi,
> I'm new in So
Hello madeinch,
Please see the Apache Public Forum Archive Policy - instructions for
archive modification are at the bottom of the page (read the rest of the
page first, though): http://www.apache.org/foundation/public-archives.html
Steve
I am seeing the following exception in solr logs after regular intervals, we
are not firing any query to have such error, what could be causing this?
ERROR - 2013-12-14 05:35:52.722; org.apache.solr.common.SolrException;
org.apache.solr.common.SolrException: org.apache.solr.search.Synt
Hello,
Could you please remove completely this thread?
Thank you
--
View this message in context:
http://lucene.472066.n3.nabble.com/Fwd-Solr-Wiki-Your-wiki-account-data-tp4104901p4106728.html
Sent from the Solr - User mailing list archive at Nabble.com.
I copy here this information as well.
Another detail that comes to my mind is that the SolrServer used to process
the request is *CloudSolrServer.*
I will check the implementation of the method.
2013/12/14 Alessandro Benedetti
> Thank you Raymond,
> so what's wrong in the code ?
> Who is respon
Thank you Raymond,
so what's wrong in the code ?
Who is responsible to decide if that params will go to the Header or in the
body?
Which is the "library I am using" you quoted ?
I am using that objects from SolrJ API library.
2013/12/13 Raymond Wiker
> I think you're wrong about this; both the
Thanks a lot Joel ..
For now I have taken it from trunk and verified the patched code works
fine ..
On Thu, Dec 12, 2013 at 9:21 PM, Joel Bernstein wrote:
> Hi,
>
> This is a known issue resolved in SOLR-5408. It's fixed in trunk and 4x and
> if there is a 4.6.1 it will be in there. If not
14 matches
Mail list logo
