Hi David,
I agree with you: Unless there's a direct reference in our source code to
nashorn, one can use any scripting language (also groovy, ruby, python) if
heshe plugs it into class path using the SPI mechanism.
It may only fail test if it's no longer bundled with JDK, but afaik I added an
That file is only used for javadocs I think? I'm unaware of any actual
_hard dependency_ on Nashorn by Solr. It's provided by the JDK and it's
loaded dynamically at runtime *if* you use that URP with Javascript which
uses the JDK's javax.scripting API which is *not* going away. You can even
plug
On Wed, Aug 12, 2020 at 8:56 AM Jan Høydahl wrote:
> I was glad to read your last mail with a softer tone, Ishan. Respect! I
> really appreciate all your hard work and passion for Lucene/Solr, and
> thanks for putting time into benchmarking, it really shows that you care
> about the project! What
Hi Roman,
Sorry for the late reply!
I think there remains substantial confusion about multi-token synonyms and
IW's enforcement of offsets. It really is worth thoroughly
iterating/understanding your examples so we can get to the bottom of this.
It looks to me it is possible to emit tokens whose
I agree with the approach Jan voiced - that at least some of these
features should appear in 9.0 as deprecated to give users more time.
That said, maybe discussing what to do around these features should be
its own thread or should be taken back to some of the specific jiras
where there's already
+1 (binding)
Smoke Test: SUCCESS! [0:56:39.184673]
Attempting to run Ishan's benchmark suite comparing 8.6.0 and 8.6.1 I get
the comparable numbers for query times and indexing times.
On Wed, Aug 12, 2020 at 11:18 AM Munendra S N
wrote:
> +1
> SUCCESS! [1:30:17.973222]
>
> Regards,
> Munendra
That is a great thought and I agree with it.
On Wed, Aug 12, 2020 at 5:55 AM Mike Drob wrote:
> I don’t have time to write a more comprehensive email with links and
> references but the basic outline here is that Mark did some (read: a ton)
> work on a private branch that he later shared with hi
+1
SUCCESS! [1:30:17.973222]
Regards,
Munendra S N
On Wed, Aug 12, 2020 at 2:22 PM Noble Paul wrote:
> SUCCESS! [1:07:08.626970]
> Ubuntu 20.04.1 LTS
>
> On Wed, Aug 12, 2020 at 4:49 PM Atri Sharma wrote:
> >
> > +1 (non binding).
> >
> > SUCCESS! [1:03:32.13920]
> >
> > On Wed, Aug 12, 2020
> So let’s not suggest I was uncooperative just for the heck of it, or
because I didn’t care, ok?
Sure, Andrzej, I do think that you care. I just assume you missed my ping
here:
https://issues.apache.org/jira/browse/SOLR-14706?focusedCommentId=17170030&page=com.atlassian.jira.plugin.system.issueta
> It has been proposed on the list to NOT rip out all deprecations in 9.0,
but allow users to
> upgrade to 9.0 with e.g. SolrCell still available, and then have yet some
time to change their
> processes to adapt to the new way of doing stuff. I like that proposal.
Sure, 9.0 will remove lots
> of de
Didn’t think at first (only one cup of coffee). Here’s the Emails that test
appears in, the formatting is poor…
After that is the raw data from Hoss’ rollups that might be easier to ingest.
I have 1.3G of this kind of historical data, I’ve had vague thoughts about
putting it someplace accessibl
Sure Andrzej, I *sincerely* apologize. I felt Houston and Gus could've
received some more help from you while they were working on the release.
But, I take my words back.
I know that you care deeply about performance (
https://issues.apache.org/jira/browse/SOLR-14691), and please accept all my
help
http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.test
David for that specific test you asked the failures are recent with as far
as I know no change to HDFS stuff. Starting June/July failing regularly.
Kevin R
I have the weekly rollups (with a few gaps) going back to about April 2018, but
nothing’s been done to try to make them generally available. Each BadApple
report has rates for the last 4 weeks in the attached file, just below
"Failures over the last 4 weeks, but not every week. Ordered most-rece
I was glad to read your last mail with a softer tone, Ishan. Respect! I really
appreciate all your hard work and passion for Lucene/Solr, and thanks for
putting time into benchmarking, it really shows that you care about the
project! What I think we need more than anything else going forward (my
> On 12 Aug 2020, at 07:06, Ishan Chattopadhyaya
> wrote:
>
> > Whatever we do or not do is imperfect. I hope some "mandate" doesn't stop
> > progress.
> > We don't go changing code just for the heck of it; we do it for a variety
> > of matters.
>
> We sometimes do: https://issues.apache.
I don’t have time to write a more comprehensive email with links and
references but the basic outline here is that Mark did some (read: a ton)
work on a private branch that he later shared with his coworkers. Pieces of
that branch filtered out to Apache.
The intent behind this annotations was to s
"Perhaps the document has an indexed string field (solr.StrField) which is too
large solr.field”
string based fields have a limit of 32K. If you mean the field to be
searchable, a 32K field _as a single term_ makes little sense.
You probably want to change the fieldType to a text-based field tha
Hi All,
I went through all the concerns voiced above and took a step back and
re-assessed my position. I am withdrawing my initial proposal to
request/nag/demand/veto issues without a performance test.
I shall not insist on that and apologize for using such language as I did
above. I hope, though,
Perhaps you have a field which exceeds the set limit?
On Wed, Aug 12, 2020 at 4:47 PM Rajesh Somvanshi
wrote:
>
>
> Hi Team,
>
>
> I am using solr library to be indexing my documents. It is working as
> expected but sometimes I am getting below error. Could you please help with
> this?
>
>
>
>
Hi *Team,*
I am using solr library to be indexing my documents. It is working as
expected but sometimes I am getting below error. Could you please help with
this?
The document contains at least one immense term in
field="FileContent_en***" (whose UTF8 encoding is longer than the max
length 327
Doesn’t the StatelessScriptUpdateProcessorFactory require this? I poked
around a bit, and it didn’t seem like there was a direct replacement for
Nashorn…. I know lots of folks aren’t fans of it, however I’ve used it many
times to solve hard indexing problems.
Someday we’ll have proper pip
SUCCESS! [1:07:08.626970]
Ubuntu 20.04.1 LTS
On Wed, Aug 12, 2020 at 4:49 PM Atri Sharma wrote:
>
> +1 (non binding).
>
> SUCCESS! [1:03:32.13920]
>
> On Wed, Aug 12, 2020 at 3:24 AM Gus Heck wrote:
> >
> > SUCCESS! [0:54:03.106188]
> >
> > And installed the tarball as a 4 node cluster, created
I hadn't opened a ticket or PR but would as soon as I receive some support
from the community.
On Wed, Aug 12, 2020 at 1:29 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> +1 to removing it.
> Does the build pass if we remove that line?
>
> On Wed, Aug 12, 2020 at 12:48 PM Marcus E
+1 to removing it.
Does the build pass if we remove that line?
On Wed, Aug 12, 2020 at 12:48 PM Marcus Eagan wrote:
> Not trying to spam the list, just looking to get feedback about the goings
> on in the project and on some of my items before I share my Google Doc,
> which is damning, even of m
I edited the page to introduce the (super important) Solr TLP split into the
roadmap.
Also added a rough timeframe and a «major theme» for each release above the
issue table.
I added 8.8 and 9.1 as I think it is important to track what gets done just
before 9.0 and what can be deferred to after
Not trying to spam the list, just looking to get feedback about the goings
on in the project and on some of my items before I share my Google Doc,
which is damning, even of my own work and efforts.
This line and subsequent lines concern me:
https://github.com/apache/lucene-solr/blob/1d2749295b537
27 matches
Mail list logo
