Re: Build Lucene/Solr in cloud

Aha, thanks! It appear's the build's CPU detection is failing to see how many are actually available in the Crave environment. So I am manually upping it and I'm seeing much better build times, at least on the Lucene end. I'll now let this run overnight for the Solr side: crave run -- ant -f so

Re: Build Lucene/Solr in cloud

Hi David, @node spec: The current setup has Crave configured to spin up a 16 core (VCPU) with 64 GB ram. I can change that to more cores, more memory if you want to try it out. @variable number of arguments: Crave does accept a variable number of arguments. It is very similar to the ssh style o

Re: Build Lucene/Solr in cloud

I don't know what Crave.io does should I, say, close my laptop and go to sleep and come back to it. If it could survive that somehow then that'd be a sweet feature! I doubt my simple rsync script plays well with that so I don't dare. ~ David On Wed, May 20, 2020 at 10:05 PM David Smiley wrote

Re: Build Lucene/Solr in cloud

Hi Yuvraaj, I do builds on a corporate provided VM that I don't know a lot about but it reports 16 CPUs and plenty of RAM (32GB?). I tuned the Solr build to use 10 test runners, which seems to work out best. Lately, the Solr-only tests take about 21-22 minutes or so. I run with "ant -f solr/bui

Re: Gradle precommit checks

log.info(“something {}”, object.toString()); and log.info(“something {}”, object)); produce an equivalent log message at info level and above I agree. However, let’s say I’m at warn level and have the following call log.info(“something {}”, object.toString() the toString() method is executed _r

Re: [VOTE] Release Lucene/Solr 8.5.2 RC1

+1 SUCCESS! [1:03:16.225214] I did no manual tests, just ran smoketester on macOS Jan > 20. mai 2020 kl. 19:58 skrev Mike Drob : > > Devs, > > Please vote for release candidate 1 for Lucene/Solr 8.5.2 > > The artifacts can be downloaded from: > https://dist.apache.org/repos/dist/dev/lucene/lu

Re: Build Lucene/Solr in cloud

Hi Pushkar, Thanks for your kind words! Hi David, Glad to hear the build was smooth with Crave. I echo Pushkar's questions. Also, I am all ears to any other feedback and questions you may have. Thanks, -Uv On May 20 2020, at 5:17 am, Pushkar Raste wrote: > Hi David, > Good to hear it worked for

Re: BinaryDocValues compression with 8.5.1

I think we could do this at the Codec level? For example, for stored fields, the current default format (Lucene50StoredFieldsFormat) has two modes, Mode.BEST_SPEED and Mode.BEST_COMPRESSION, that are easy for the user to pick. Both modes use compression, just at varying levels. I think for the (

Re: BinaryDocValues compression with 8.5.1

I guess the compression we added to binary doc values, and for postings, seems to have hurt performance in a way that wasn't detected in testing when those changes were made, or if it was detected, I don't recall any discussion about the tradeoff being made. Now that we do see there is a tradeoff,

Re: Gradle precommit checks

Thanks for your detailed response. I agree. Simplicity brings value. And I agree that performance degradation of format method vs. native concat is negligible in the warn context. I need to look at the trace method to see the difference between the two calls (because I do believe that ("text" + ob

Re: Gradle precommit checks

Ilan: Technically it may be true (although frankly I don’t know for sure), but practically at warn level any extra work isn’t worth the confusion. What do I mean by that? Well, we built up a huge debt with all sorts of debug and info and even trace messages that either concatenated strings or

Re: Intermittent NullPointerException in ZkController on Solr 8.x

(Patch for that issue available on https://issues.apache.org/jira/browse/SOLR-14503) On Wed, 20 May 2020 at 17:06, Colvin Cowie wrote: > Hi Ishan, thanks for prompting me to look at it again. > The robust SDF was something I added to our product before > https://issues.apache.org/jira/browse/SOL

[VOTE] Release Lucene/Solr 8.5.2 RC1

Devs, Please vote for release candidate 1 for Lucene/Solr 8.5.2 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.2-RC1-rev384dadd9141cec3f848d8c416315dc2384749814 You can run the smoke tester directly with this command: python3 -u dev-tools/scr

Gradle precommit checks

This might have been discussed previously but since I'm seeing this behavior... Gradle precommit check does not allow code such as: log.warn("Only in tree one: " + t1); And forces changing it into: log.warn("Only in tree one: {}", t1); I do understand such constraints for debug level logs to not

Re: packaging Solr binaries with Ant

Thank you, that did it! On Wed, May 20, 2020 at 10:04 AM Jan Høydahl wrote: > Try ant create-package > > Jan > > 20. mai 2020 kl. 15:35 skrev Theyaa Matti : > > I have compiled Solr locally and I would like to know how package solr in > a tar file similar to the ones provided here > https://luce

Re: Intermittent NullPointerException in ZkController on Solr 8.x

Hi Ishan, thanks for prompting me to look at it again. The robust SDF was something I added to our product before https://issues.apache.org/jira/browse/SOLR-5129 was implemented, which should achieve the same effect (unless my understanding of the intention behind it is wrong). However when I teste

Re: Intermittent NullPointerException in ZkController on Solr 8.x

Hi Colvin, Off topic: but did you consider contributing your robust SDF changes upstream? It you need it, others might as well. And if everyone is using it, the tracking down of bugs in supported code becomes easier as well. 🙂 Regards, Ishan On Wed, 20 May, 2020, 7:39 pm Colvin Cowie, wrote: > H

Re: Solr Java-API Question

I hope this helps: https://lucene.apache.org/solr/guide/8_5/working-with-dates.html No, LongPointField only does single points, not point-ranges. Some day we need a dedicated LongRangeField and similar for other primitives. ~ David On Wed, May 20, 2020 at 3:25 AM Ruscheinski, Johannes < johann

Intermittent NullPointerException in ZkController on Solr 8.x

Hello, I've only seen this very occasionally on our automated tests so I've never really dug into it. Running on Solr 8.3.1 *2020-05-19 03:44:40.220 INFO (main) [ ] o.a.s.c.ZkContainer Zookeeper client=X:9983/_cluster2020-05-19 03:44:40.238 INFO (main) [ ] o.a.s.

Re: packaging Solr binaries with Ant

Try ant create-package Jan > 20. mai 2020 kl. 15:35 skrev Theyaa Matti : > > I have compiled Solr locally and I would like to know how package solr in a > tar file similar to the ones provided here > https://lucene.apache.org/solr/downloads.html >

packaging Solr binaries with Ant

I have compiled Solr locally and I would like to know how package solr in a tar file similar to the ones provided here https://lucene.apache.org/solr/downloads.html. I tried to see if Ant provides that, but seems like I can't find that option. Does anyone know please how do I package solr in a tar

Re: Build Lucene/Solr in cloud

Hi David, Good to hear it worked for you. I suggested Crave team to join the mailing list so they can directly hear the feedback and answer any questions. For rest of us in the community who may not have beefier boxes can you share what is config of your buildbox, how long builds take on the buildb

Re: Solr Java-API Question

Hi again, we originally thought that LongPointField was what we might have to go with. Is that the wrong field type because it doesn't support intersection with multiple ranges simultaneously whereas the DateRangeField does? Johannes -- Dr. Johannes Ruscheinski Universitätsbibliothek Tübing

Re: Solr Java-API Question

Hi David, thanks for the advice. I hope I get the necessary resolution this way. As I understand the recommendation it is to use seconds. I think we need 9 decimal places. So that's 10^9 s which is not quite 32 years. Also how do I issue my intersection queries at the Java API level once