[jira] [Commented] (LUCENE-8740) AssertionError FlattenGraphFilter
[ https://issues.apache.org/jira/browse/LUCENE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929699#comment-16929699 ] Chongchen Chen commented on LUCENE-8740: It seems that FlattenGraphFilter doesn't work well with StopFilter's result. The workaround is putting the FlattenGraphFilter before StopFilter. > AssertionError FlattenGraphFilter > - > > Key: LUCENE-8740 > URL: https://issues.apache.org/jira/browse/LUCENE-8740 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.5, 8.0 >Reporter: Markus Jelsma >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-8740.patch > > > Our unit tests picked up an unusual AssertionError in FlattenGraphFilter > which manifests itself only in very specific circumstances involving > WordDelimiterGraph, StopFilter, FlattenGraphFilter and MinhashFilter. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13238) BlobHandler generates non-padded md5
[
https://issues.apache.org/jira/browse/SOLR-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929776#comment-16929776
]
Jeff Walraven commented on SOLR-13238:
--
[~janhoy] [~noble.paul] Anything else you need from me to get this merged?
> BlobHandler generates non-padded md5
>
>
> Key: SOLR-13238
> URL: https://issues.apache.org/jira/browse/SOLR-13238
> Project: Solr
> Issue Type: Bug
> Components: blobstore
>Affects Versions: 6.0, 6.6.5, 7.0, 7.6, 7.7
>Reporter: Jeff Walraven
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Introduced in SOLR-6787
> The blob handler currently uses the following logic for generating/storing
> the md5 for uploads:
> {code:java}
> MessageDigest m = MessageDigest.getInstance("MD5");
> m.update(payload.array(), payload.position(), payload.limit());
> String md5 = new BigInteger(1, m.digest()).toString(16);
> {code}
> Unfortunately, this method does not provide padding for any md5 with less
> than 0x10 for its most significant byte. This means that on many occasions it
> could end up with a md5 hash of 31 characters instead of 32.
> I have opened a PR with the following recommended change:
> {code:java}
> String md5 = new String(Hex.encodeHex(m.digest()));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13238) BlobHandler generates non-padded md5
[
https://issues.apache.org/jira/browse/SOLR-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Walraven updated SOLR-13238:
-
Status: Patch Available (was: Open)
> BlobHandler generates non-padded md5
>
>
> Key: SOLR-13238
> URL: https://issues.apache.org/jira/browse/SOLR-13238
> Project: Solr
> Issue Type: Bug
> Components: blobstore
>Affects Versions: 6.0, 6.6.5, 7.0, 7.6, 7.7
>Reporter: Jeff Walraven
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Introduced in SOLR-6787
> The blob handler currently uses the following logic for generating/storing
> the md5 for uploads:
> {code:java}
> MessageDigest m = MessageDigest.getInstance("MD5");
> m.update(payload.array(), payload.position(), payload.limit());
> String md5 = new BigInteger(1, m.digest()).toString(16);
> {code}
> Unfortunately, this method does not provide padding for any md5 with less
> than 0x10 for its most significant byte. This means that on many occasions it
> could end up with a md5 hash of 31 characters instead of 32.
> I have opened a PR with the following recommended change:
> {code:java}
> String md5 = new String(Hex.encodeHex(m.digest()));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13238) BlobHandler generates non-padded md5
[
https://issues.apache.org/jira/browse/SOLR-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Walraven updated SOLR-13238:
-
Status: Open (was: Patch Available)
> BlobHandler generates non-padded md5
>
>
> Key: SOLR-13238
> URL: https://issues.apache.org/jira/browse/SOLR-13238
> Project: Solr
> Issue Type: Bug
> Components: blobstore
>Affects Versions: 6.0, 6.6.5, 7.0, 7.6, 7.7
>Reporter: Jeff Walraven
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Introduced in SOLR-6787
> The blob handler currently uses the following logic for generating/storing
> the md5 for uploads:
> {code:java}
> MessageDigest m = MessageDigest.getInstance("MD5");
> m.update(payload.array(), payload.position(), payload.limit());
> String md5 = new BigInteger(1, m.digest()).toString(16);
> {code}
> Unfortunately, this method does not provide padding for any md5 with less
> than 0x10 for its most significant byte. This means that on many occasions it
> could end up with a md5 hash of 31 characters instead of 32.
> I have opened a PR with the following recommended change:
> {code:java}
> String md5 = new String(Hex.encodeHex(m.digest()));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] eribeiro commented on a change in pull request #864: SOLR-13101 : Shared storage support in SolrCloud
eribeiro commented on a change in pull request #864: SOLR-13101 : Shared
storage support in SolrCloud
URL: https://github.com/apache/lucene-solr/pull/864#discussion_r324026158
##
File path:
solr/core/src/java/org/apache/solr/store/blob/client/BlobCoreMetadata.java
##
@@ -0,0 +1,284 @@
+package org.apache.solr.store.blob.client;
+
+import java.util.Arrays;
+import java.util.HashSet;
+import java.util.Set;
+import java.util.UUID;
+
+/**
+ * Object defining metadata stored in blob store for a Shared Collection shard
and its builders.
+ * This metadata includes all actual segment files as well as the segments_N
file of the commit point.
+ *
+ * This object is serialized to/from Json and stored in the blob store as a
blob.
+ */
+public class BlobCoreMetadata {
+
+/**
+ * Name of the shard index data that is shared by all replicas belonging
to that shard. This
+ * name is to decouple the core name that Solr manages from the name of
the core on blob store.
+ */
+private final String sharedBlobName;
+
+/**
+ * Unique identifier of this metadata, that changes on every update to the
metadata (except generating a new corrupt metadata
+ * through {@link #getCorruptOf}).
+ */
+private final String uniqueIdentifier;
+
+/**
+ * Indicates that a Solr (search) server pulled this core and was then
unable to open or use it. This flag is used as
+ * an indication to servers pushing blobs for that core into Blob Store to
push a complete set of files if they have
+ * a locally working copy rather than just diffs (files missing on Blob
Store).
+ */
+private final boolean isCorrupt;
+
+/**
+ * Indicates that this core has been deleted by the client. This flag is
used as a marker to prevent other servers
+ * from pushing their version of this core to blob and to allow local copy
cleanup.
+ */
+private final boolean isDeleted;
+
+/**
+ * The array of files that constitute the current commit point of the core
(as known by the Blob store).
+ * This array is not ordered! There are no duplicate entries in it either
(see how it's built in {@link BlobCoreMetadataBuilder}).
+ */
+private final BlobFile[] blobFiles;
+
+/**
+ * Files marked for delete but not yet removed from the Blob store. Each
such file contains information indicating when
+ * it was marked for delete so we can actually remove the corresponding
blob (and the entry from this array in the metadata)
+ * when it's safe to do so even if there are (unexpected) conflicting
updates to the blob store by multiple solr servers...
+ * TODO: we might want to separate the metadata blob with the deletes as
it's not required to always fetch the delete list when checking freshness of
local core...
+ */
+private final BlobFileToDelete[] blobFilesToDelete;
+
+/**
+ * This is the constructor called by {@link BlobCoreMetadataBuilder}.
+ * It always builds non "isCorrupt" and non "isDeleted" metadata.
+ * The only way to build an instance of "isCorrupt" metadata is to use
{@link #getCorruptOf} and for "isDeleted" use {@link #getDeletedOf()}
+ */
+BlobCoreMetadata(String sharedBlobName, BlobFile[] blobFiles,
BlobFileToDelete[] blobFilesToDelete) {
+this(sharedBlobName, blobFiles, blobFilesToDelete,
UUID.randomUUID().toString(), false,
+false);
+}
+
+private BlobCoreMetadata(String sharedBlobName, BlobFile[] blobFiles,
BlobFileToDelete[] blobFilesToDelete,
+String uniqueIdentifier, boolean isCorrupt, boolean isDeleted) {
+this.sharedBlobName = sharedBlobName;
+this.blobFiles = blobFiles;
+this.blobFilesToDelete = blobFilesToDelete;
+this.uniqueIdentifier = uniqueIdentifier;
+this.isCorrupt = isCorrupt;
+this.isDeleted = isDeleted;
+}
+
+/**
+ * Given a non corrupt {@link BlobCoreMetadata} instance, creates an
equivalent one based on it but marked as corrupt.
+ * The new instance keeps all the rest of the metadata unchanged,
including the {@link #uniqueIdentifier}.
+ */
+public BlobCoreMetadata getCorruptOf() {
+assert !isCorrupt;
+return new BlobCoreMetadata(sharedBlobName, blobFiles,
blobFilesToDelete, uniqueIdentifier, true, isDeleted);
+}
+
+/**
+ * Given a {@link BlobCoreMetadata} instance, creates an equivalent one
based on it but marked as deleted.
+ *
+ * The new instance keeps all the rest of the metadata unchanged,
including the {@link #uniqueIdentifier}.
+ */
+public BlobCoreMetadata getDeletedOf() {
+assert !isDeleted;
+return new BlobCoreMetadata(sharedBlobName, blobFiles,
blobFilesToDelete, uniqueIdentifier, isCorrupt, true);
+}
+
+/**
+ * Returns true if the Blob metadata was marked as deleted
+ */
+public boolean getIsDeleted() {
+return isDeleted;
+}
+
+/**
+
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929760#comment-16929760 ] Uwe Schindler commented on LUCENE-8951: --- [~elyograg]: Maybe because you are "watcher" of this issue? I also get 2 mails: One to the mailing list and one to me privately. But thats usual. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists (/) > # Announce to dev@ list that the change will happen (/) > # Modify Jira and Github bots to post to issues@ list instead of dev@ (/) > # Modify Jenkins (including Policeman and other) to post to builds@ (/) > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13622) Add FileStream Streaming Expression
[ https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929847#comment-16929847 ] ASF subversion and git services commented on SOLR-13622: Commit 2546e7a2ec577b7cfbce3f96c9c69d45d979a2cf in lucene-solr's branch refs/heads/master from Jason Gerlowski [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2546e7a ] SOLR-13622: Fix file-handle leak > Add FileStream Streaming Expression > --- > > Key: SOLR-13622 > URL: https://issues.apache.org/jira/browse/SOLR-13622 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Jason Gerlowski >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13622.patch, SOLR-13622.patch > > > The FileStream will read files from a local filesystem and Stream back each > line of the file as a tuple. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13622) Add FileStream Streaming Expression
[ https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929860#comment-16929860 ] Jason Gerlowski edited comment on SOLR-13622 at 9/15/19 1:09 AM: - The problem was pretty clear once I took a look (and with Hoss' digging). I pushed a fix, and tried to make the file-handling a little cleaner while I was there. I would normally push a patch and let it sit for review, but since it was causing test failures I just committed it straight away. If anyone has any review comments I'm happy to address them at this point though. I'll check back in a week and close this if things check out. was (Author: gerlowskija): The problem was pretty clear once I took a look (and with Hoss' digging). I pushed a fix, and tried to make the file-handling a little cleaner while I was there. I would normally push a patch and let it sit for review, but since it was causing test failures I just committed it straight away. If anyone has any review comments I'm happy to address them at this point though. > Add FileStream Streaming Expression > --- > > Key: SOLR-13622 > URL: https://issues.apache.org/jira/browse/SOLR-13622 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Jason Gerlowski >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13622.patch, SOLR-13622.patch > > > The FileStream will read files from a local filesystem and Stream back each > line of the file as a tuple. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13238) BlobHandler generates non-padded md5
[
https://issues.apache.org/jira/browse/SOLR-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929813#comment-16929813
]
Jan Høydahl commented on SOLR-13238:
I'm adding a CHANGES entry and fixing a precommit failure in
{{TestBlobHandler}} and will then merge.
Thanks for the contribution Jeff. Regarding precommit failure, we have a
workflow where we in addition to 'ant test' also run 'ant precommit' to
validate various code requirements. We have recently added automatic CI to
GitHub, so next PR you submit will be tested with 'ant precommit' :) Also,
there is a new PR description template with a checklist that helps you remember
what to do.
> BlobHandler generates non-padded md5
>
>
> Key: SOLR-13238
> URL: https://issues.apache.org/jira/browse/SOLR-13238
> Project: Solr
> Issue Type: Bug
> Components: blobstore
>Affects Versions: 6.0, 6.6.5, 7.0, 7.6, 7.7
>Reporter: Jeff Walraven
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Introduced in SOLR-6787
> The blob handler currently uses the following logic for generating/storing
> the md5 for uploads:
> {code:java}
> MessageDigest m = MessageDigest.getInstance("MD5");
> m.update(payload.array(), payload.position(), payload.limit());
> String md5 = new BigInteger(1, m.digest()).toString(16);
> {code}
> Unfortunately, this method does not provide padding for any md5 with less
> than 0x10 for its most significant byte. This means that on many occasions it
> could end up with a md5 hash of 31 characters instead of 32.
> I have opened a PR with the following recommended change:
> {code:java}
> String md5 = new String(Hex.encodeHex(m.digest()));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13238) BlobHandler generates non-padded md5
[
https://issues.apache.org/jira/browse/SOLR-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-13238:
---
Fix Version/s: 8.3
> BlobHandler generates non-padded md5
>
>
> Key: SOLR-13238
> URL: https://issues.apache.org/jira/browse/SOLR-13238
> Project: Solr
> Issue Type: Bug
> Components: blobstore
>Affects Versions: 6.0, 6.6.5, 7.0, 7.6, 7.7
>Reporter: Jeff Walraven
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Introduced in SOLR-6787
> The blob handler currently uses the following logic for generating/storing
> the md5 for uploads:
> {code:java}
> MessageDigest m = MessageDigest.getInstance("MD5");
> m.update(payload.array(), payload.position(), payload.limit());
> String md5 = new BigInteger(1, m.digest()).toString(16);
> {code}
> Unfortunately, this method does not provide padding for any md5 with less
> than 0x10 for its most significant byte. This means that on many occasions it
> could end up with a md5 hash of 31 characters instead of 32.
> I have opened a PR with the following recommended change:
> {code:java}
> String md5 = new String(Hex.encodeHex(m.digest()));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13238) BlobHandler generates non-padded md5
[
https://issues.apache.org/jira/browse/SOLR-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929816#comment-16929816
]
ASF subversion and git services commented on SOLR-13238:
Commit 31735eeb402d7b00785bba484093b81107ffc2c9 in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=31735ee ]
SOLR-13238: BlobHandler generates non-padded md5
> BlobHandler generates non-padded md5
>
>
> Key: SOLR-13238
> URL: https://issues.apache.org/jira/browse/SOLR-13238
> Project: Solr
> Issue Type: Bug
> Components: blobstore
>Affects Versions: 6.0, 6.6.5, 7.0, 7.6, 7.7
>Reporter: Jeff Walraven
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Introduced in SOLR-6787
> The blob handler currently uses the following logic for generating/storing
> the md5 for uploads:
> {code:java}
> MessageDigest m = MessageDigest.getInstance("MD5");
> m.update(payload.array(), payload.position(), payload.limit());
> String md5 = new BigInteger(1, m.digest()).toString(16);
> {code}
> Unfortunately, this method does not provide padding for any md5 with less
> than 0x10 for its most significant byte. This means that on many occasions it
> could end up with a md5 hash of 31 characters instead of 32.
> I have opened a PR with the following recommended change:
> {code:java}
> String md5 = new String(Hex.encodeHex(m.digest()));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-11492) More Modern cloud dev script
[ https://issues.apache.org/jira/browse/SOLR-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929881#comment-16929881 ] Mark Miller commented on SOLR-11492: bq. I'll be happy to check it into either of /solr/cloud-dev or /dev-tools/scripts +1 - those scripts have not seen any improvement since they were added years and years ago - and yet what a pain to develop on solrcloud if you can't simply and easily start up a local dev cluster. > More Modern cloud dev script > > > Key: SOLR-11492 > URL: https://issues.apache.org/jira/browse/SOLR-11492 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 8.0 >Reporter: Gus Heck >Assignee: Gus Heck >Priority: Minor > Attachments: cloud.sh, cloud.sh, cloud.sh, cloud.sh, cloud.sh, > cloud.sh > > > Most of the scripts in solr/cloud-dev do things like start using java -jar > and other similarly ancient techniques. I recently decided I really didn't > like that it was a pain to setup a cloud to test a patch/feature and that > often one winds up needing to blow away existing testing so working on more > than one thing at a time is irritating... so here's a script I wrote, if > folks like it I'd be happy for it to be included in solr/cloud-dev -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929833#comment-16929833 ] Mark Miller commented on SOLR-13452: [~anshumg] some weird issue I ran into where xml-apis:xml-apis gets pulled in on osx and not linux - had tried to address it without fully testing. Seems to be okay now. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] KoenDG opened a new pull request #881: LUCENE-8979: Code Cleanup: Use entryset for map iteration wherever possible. - part 2
KoenDG opened a new pull request #881: LUCENE-8979: Code Cleanup: Use entryset for map iteration wherever possible. - part 2 URL: https://github.com/apache/lucene-solr/pull/881 https://issues.apache.org/jira/browse/LUCENE-8979 It appears not all instances were picked up by the previous sweep, which is strange as it's all automated. I'm hoping this is all of them. Some simple cleanup. No need to spend company/personal time reviewing this, would be good if someone had some spare time. If you don't, feel free to close this tab. It's a very simple PR: just changing keySet() to entrySet() when possible. In general just the better choice. Only really a performance gain when going over a TreeMap(as I recall at least), but in general a good idea to consistent with it. A small move in TermsComponent.java, there's no point in doing the method call to populate the field and then the very next thing that happens is an unrelated check that potentially forces a `continue`, rendering the call pointless for that iteration. All tests have run locally and succeeded. Sorry about doing this twice, I don't get how these weren't picked up the first time. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gus-asf opened a new pull request #879: SOLR-13760 - restore viability of date math in TRA start property
gus-asf opened a new pull request #879: SOLR-13760 - restore viability of date math in TRA start property URL: https://github.com/apache/lucene-solr/pull/879 # Description Fix Date math parsing for TRA start # Solution Invoke the DateMathParser.parseMath method rather than using the parseRouteKey method. # Tests Added a test that fails without the fix to ensure support for date math is not lost again. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I am authorized to contribute this code to the ASF and have removed any code I do not have a license to distribute. - [x] I have developed this patch against the `master` branch. - [x] I have run `ant precommit` and the appropriate test suite. - [x] I have added tests for my changes. - [x] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929854#comment-16929854 ] ASF subversion and git services commented on SOLR-13452: Commit 739425bd7bb0e81ebfb28d2061a4479131dc13d8 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_7 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=739425b ] SOLR-13452: Make circular dependency a warning instead of error automatically for Eclipse. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929857#comment-16929857 ] ASF subversion and git services commented on SOLR-13452: Commit b57ed8b96ee5e651cd24ee27e138a95e0660caec in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_7 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b57ed8b ] SOLR-13452: Fix our repos. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929853#comment-16929853 ] ASF subversion and git services commented on SOLR-13452: Commit add8bb9e907171e37333041f4a2bfa96f2d59244 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_7 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=add8bb9 ] SOLR-13452: Start improving logging around missingDependencies. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929859#comment-16929859 ] ASF subversion and git services commented on SOLR-13452: Commit 7dc2f381ce19310c63d5b5c04b27917339af7211 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_7 from markrmiller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7dc2f38 ] SOLR-13452: Set morfologik-ukrainian-search to a runtime dep. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13753) Get GitHub to run 'ant precommit' as an action for all PRs
[ https://issues.apache.org/jira/browse/SOLR-13753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929856#comment-16929856 ] Mark Miller commented on SOLR-13753: It won't, it only works on the default branch properly apparently, but I read they will fix it in 2-3 weeks 2 weeks ago. > Get GitHub to run 'ant precommit' as an action for all PRs > -- > > Key: SOLR-13753 > URL: https://issues.apache.org/jira/browse/SOLR-13753 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > Get GitHub to run 'ant precommit' as a check for all PRs. This would make > things much nicer as GitHub would run the checks for us and it's easier to > track and fix when precommits are broken. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929858#comment-16929858 ] ASF subversion and git services commented on SOLR-13452: Commit d48bab4277837ee02fd5f34f0e42200fe72c8479 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_7 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d48bab4 ] SOLR-13452: Fix the fix for the strange 'xml-apis:xmlapis comes in on osx and not linux' issue. Also, update the consistent-versions plugin to 1.12.4. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929855#comment-16929855 ] ASF subversion and git services commented on SOLR-13452: Commit ec9a8d55a78ac423057f3c067339337deb9984d6 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_7 from Gus Heck [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ec9a8d5 ] SOLR-13452 .get() from the atomic integer to allow the error message to be shown. (found by Eran Buchnick) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Description: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_7 was: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_7 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13622) Add FileStream Streaming Expression
[ https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929860#comment-16929860 ] Jason Gerlowski commented on SOLR-13622: The problem was pretty clear once I took a look (and with Hoss' digging). I pushed a fix, and tried to make the file-handling a little cleaner while I was there. I would normally push a patch and let it sit for review, but since it was causing test failures I just committed it straight away. If anyone has any review comments I'm happy to address them at this point though. > Add FileStream Streaming Expression > --- > > Key: SOLR-13622 > URL: https://issues.apache.org/jira/browse/SOLR-13622 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Jason Gerlowski >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13622.patch, SOLR-13622.patch > > > The FileStream will read files from a local filesystem and Stream back each > line of the file as a tuple. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929861#comment-16929861 ] Mark Miller commented on SOLR-13452: Development has shifted to https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_7 which is up to date with master. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_7 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929852#comment-16929852 ] ASF subversion and git services commented on SOLR-13452: Commit fbdb2c112773529ade24be8b3f9d79a0dfc208bc in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_7 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fbdb2c1 ] SOLR-13452: Fix up how we make sure buildSrc resources are handled nicely in IDE. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13753) Get GitHub to run 'ant precommit' as an action for all PRs
[ https://issues.apache.org/jira/browse/SOLR-13753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929865#comment-16929865 ] Mark Miller edited comment on SOLR-13753 at 9/15/19 1:56 AM: - Or I should say it just doesn't work well yet. The only workflows that will show up in GitHub UI are the ones specified in master - so you can configure other branches to also work in master, from that perspective you are fine. Where it's supposed to get better any day now is making changes or adding a workflow in another branch - right now those might as well not exist and it's just the workflows in the default branch (currently master). Your workflow in master working against other branches should be fine though. was (Author: markrmil...@gmail.com): Or I should say it just doesn't work well yet. The only workflows that will show up in GitHub UI are the ones specified in master - so you can configure other branches to also work in master, from that perspective you are find. Where it's supposed to get better any day now is making changes or adding a workflow in another branch - right now those might as well not exist and it's just the workflows in the default branch (currently master). > Get GitHub to run 'ant precommit' as an action for all PRs > -- > > Key: SOLR-13753 > URL: https://issues.apache.org/jira/browse/SOLR-13753 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > Get GitHub to run 'ant precommit' as a check for all PRs. This would make > things much nicer as GitHub would run the checks for us and it's easier to > track and fix when precommits are broken. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-13760) Date Math in "start" attribute of routed alias causes exception
Gus Heck created SOLR-13760: --- Summary: Date Math in "start" attribute of routed alias causes exception Key: SOLR-13760 URL: https://issues.apache.org/jira/browse/SOLR-13760 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Affects Versions: 8.3 Reporter: Gus Heck Assignee: Gus Heck The start parameter (for Time Routed Aliases and 2-Dimensional Routed Aliases using time components) is meant to accept date math as well as a timestamp. However it seems that none of the tests actually test this, and my changes for DRA forgot to account for it in one place, so an exception is thrown adding a document to an alias with such a configuration. Will add a test and a fix. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on issue #570: SOLR-13238 Fixed blob handler md5 padding issue
janhoy commented on issue #570: SOLR-13238 Fixed blob handler md5 padding issue URL: https://github.com/apache/lucene-solr/pull/570#issuecomment-531512762 Merged This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13238) BlobHandler generates non-padded md5
[
https://issues.apache.org/jira/browse/SOLR-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved SOLR-13238.
Resolution: Fixed
> BlobHandler generates non-padded md5
>
>
> Key: SOLR-13238
> URL: https://issues.apache.org/jira/browse/SOLR-13238
> Project: Solr
> Issue Type: Bug
> Components: blobstore
>Affects Versions: 6.0, 6.6.5, 7.0, 7.6, 7.7
>Reporter: Jeff Walraven
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.3
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Introduced in SOLR-6787
> The blob handler currently uses the following logic for generating/storing
> the md5 for uploads:
> {code:java}
> MessageDigest m = MessageDigest.getInstance("MD5");
> m.update(payload.array(), payload.position(), payload.limit());
> String md5 = new BigInteger(1, m.digest()).toString(16);
> {code}
> Unfortunately, this method does not provide padding for any md5 with less
> than 0x10 for its most significant byte. This means that on many occasions it
> could end up with a md5 hash of 31 characters instead of 32.
> I have opened a PR with the following recommended change:
> {code:java}
> String md5 = new String(Hex.encodeHex(m.digest()));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13238) BlobHandler generates non-padded md5
[
https://issues.apache.org/jira/browse/SOLR-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929820#comment-16929820
]
ASF subversion and git services commented on SOLR-13238:
Commit a5b558582293c7ef4b05e505e3d4cef493cbd1d9 in lucene-solr's branch
refs/heads/branch_8x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a5b5585 ]
SOLR-13238: BlobHandler generates non-padded md5
(cherry picked from commit 31735eeb402d7b00785bba484093b81107ffc2c9)
> BlobHandler generates non-padded md5
>
>
> Key: SOLR-13238
> URL: https://issues.apache.org/jira/browse/SOLR-13238
> Project: Solr
> Issue Type: Bug
> Components: blobstore
>Affects Versions: 6.0, 6.6.5, 7.0, 7.6, 7.7
>Reporter: Jeff Walraven
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Introduced in SOLR-6787
> The blob handler currently uses the following logic for generating/storing
> the md5 for uploads:
> {code:java}
> MessageDigest m = MessageDigest.getInstance("MD5");
> m.update(payload.array(), payload.position(), payload.limit());
> String md5 = new BigInteger(1, m.digest()).toString(16);
> {code}
> Unfortunately, this method does not provide padding for any md5 with less
> than 0x10 for its most significant byte. This means that on many occasions it
> could end up with a md5 hash of 31 characters instead of 32.
> I have opened a PR with the following recommended change:
> {code:java}
> String md5 = new String(Hex.encodeHex(m.digest()));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8979) Code Cleanup: Use entryset for map iteration wherever possible - part 2 possible.
[ https://issues.apache.org/jira/browse/LUCENE-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koen De Groote updated LUCENE-8979: --- Description: For some reason, not all issues had been picked up in the previous ticket. This should be all of them. My bad I suppose. == Simple, non-important code cleanup. Again, to clarify, please don't bother yourself with this ticket on company time, on personal time you could be working on something that makes you money or improves the product for your feature personally. This entire ticket is an afterthough. A look back at the code base that most people don't have the time for. While true that using `entrySet()` is really only an improvement for traversing a TreeMap(at least that's how it was in JDK8), it's a good practice in general to use it over keySet(), if you then use that keyset to do an extra lookup to get the value as well as the key. So that's what this ticket is. All changes were done automatically via Intellij's built-in code analysis. Putting this on LUCENE because code both in lucene and solr was changed. was: Simple, non-important code cleanup. Again, to clarify, please don't bother yourself with this ticket on company time, on personal time you could be working on something that makes you money or improves the product for your feature personally. This entire ticket is an afterthough. A look back at the code base that most people don't have the time for. While true that using `entrySet()` is really only an improvement for traversing a TreeMap(at least that's how it was in JDK8), it's a good practice in general to use it over keySet(), if you then use that keyset to do an extra lookup to get the value as well as the key. So that's what this ticket is. All changes were done automatically via Intellij's built-in code analysis. Putting this on LUCENE because code both in lucene and solr was changed. > Code Cleanup: Use entryset for map iteration wherever possible - part 2 > possible. > - > > Key: LUCENE-8979 > URL: https://issues.apache.org/jira/browse/LUCENE-8979 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 8.2 >Reporter: Koen De Groote >Priority: Trivial > > For some reason, not all issues had been picked up in the previous ticket. > This should be all of them. My bad I suppose. > > == > > Simple, non-important code cleanup. > Again, to clarify, please don't bother yourself with this ticket on company > time, on personal time you could be working on something that makes you money > or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > > > > While true that using `entrySet()` is really only an improvement for > traversing a TreeMap(at least that's how it was in JDK8), it's a good > practice in general to use it over keySet(), if you then use that keyset to > do an extra lookup to get the value as well as the key. > > So that's what this ticket is. > > All changes were done automatically via Intellij's built-in code analysis. > > Putting this on LUCENE because code both in lucene and solr was changed. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-8979) Code Cleanup: Use entryset for map iteration wherever possible - part 2 possible.
Koen De Groote created LUCENE-8979: -- Summary: Code Cleanup: Use entryset for map iteration wherever possible - part 2 possible. Key: LUCENE-8979 URL: https://issues.apache.org/jira/browse/LUCENE-8979 Project: Lucene - Core Issue Type: Improvement Affects Versions: 8.2 Reporter: Koen De Groote Fix For: 8.3 Simple, non-important code cleanup. Again, to clarify, please don't bother yourself with this ticket on company time, on personal time you could be working on something that makes you money or improves the product for your feature personally. This entire ticket is an afterthough. A look back at the code base that most people don't have the time for. While true that using `entrySet()` is really only an improvement for traversing a TreeMap(at least that's how it was in JDK8), it's a good practice in general to use it over keySet(), if you then use that keyset to do an extra lookup to get the value as well as the key. So that's what this ticket is. All changes were done automatically via Intellij's built-in code analysis. Putting this on LUCENE because code both in lucene and solr was changed. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8979) Code Cleanup: Use entryset for map iteration wherever possible - part 2 possible.
[ https://issues.apache.org/jira/browse/LUCENE-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koen De Groote updated LUCENE-8979: --- Fix Version/s: (was: 8.3) > Code Cleanup: Use entryset for map iteration wherever possible - part 2 > possible. > - > > Key: LUCENE-8979 > URL: https://issues.apache.org/jira/browse/LUCENE-8979 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 8.2 >Reporter: Koen De Groote >Priority: Trivial > > Simple, non-important code cleanup. > Again, to clarify, please don't bother yourself with this ticket on company > time, on personal time you could be working on something that makes you money > or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > > > > While true that using `entrySet()` is really only an improvement for > traversing a TreeMap(at least that's how it was in JDK8), it's a good > practice in general to use it over keySet(), if you then use that keyset to > do an extra lookup to get the value as well as the key. > > So that's what this ticket is. > > All changes were done automatically via Intellij's built-in code analysis. > > Putting this on LUCENE because code both in lucene and solr was changed. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13622) Add FileStream Streaming Expression
[ https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929849#comment-16929849 ] ASF subversion and git services commented on SOLR-13622: Commit f12a652e11da014a2934a74f7e0b5841143ad431 in lucene-solr's branch refs/heads/branch_8x from Jason Gerlowski [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f12a652 ] SOLR-13622: Fix file-handle leak > Add FileStream Streaming Expression > --- > > Key: SOLR-13622 > URL: https://issues.apache.org/jira/browse/SOLR-13622 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Jason Gerlowski >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13622.patch, SOLR-13622.patch > > > The FileStream will read files from a local filesystem and Stream back each > line of the file as a tuple. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929808#comment-16929808
]
Jan Høydahl commented on LUCENE-8951:
-
{quote}I think I'm getting the other two because I signed up my usual
apa...@elyograg.org email, and I'm also a moderator with elyog...@apache.org.
{quote}
Yep me too. I just sent an unsubscribe request from my @apache.org address so I
only get the mails to one account. I think perhaps I'm still a moderator with
my apache mail even if I don't get all posts there...?
> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
> # Create mailing lists as an announce only list (/)
> # Subscribe all emails that will be allowed to post (/)
> # Update websites with info about the new lists (/)
> # Announce to dev@ list that the change will happen (/)
> # Modify Jira and Github bots to post to issues@ list instead of dev@ (/)
> # Modify Jenkins (including Policeman and other) to post to builds@ (/)
> # Announce to dev@ list that the change is effective
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929809#comment-16929809
]
Jan Høydahl commented on LUCENE-8951:
-
One more thing that we discussed earlier.
It is possible to get all {{[jira] [Created]}} emails to dev@ list, i.e. a
one-time mail for every new JIRA. I think that could be smart so you can stay
on top of new issues even without following issues@ list, and add yourself as
watcher to the ones you want to monitor. WDYT? (Perhaps I just felt the dev
list became a bit too silent :) now)
> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
> # Create mailing lists as an announce only list (/)
> # Subscribe all emails that will be allowed to post (/)
> # Update websites with info about the new lists (/)
> # Announce to dev@ list that the change will happen (/)
> # Modify Jira and Github bots to post to issues@ list instead of dev@ (/)
> # Modify Jenkins (including Policeman and other) to post to builds@ (/)
> # Announce to dev@ list that the change is effective
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13760) Date Math in "start" attribute of routed alias causes exception
[ https://issues.apache.org/jira/browse/SOLR-13760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929819#comment-16929819 ] Gus Heck commented on SOLR-13760: - The fix in the pull request parses the date math correctly. The interesting effect here is that a DRA configured with something like "start":"NOW/DAY" would never allow old documents for a new category no matter how long it's been running. I think it's possible to see this as a feature, but also possible to see it as a bit tricky or surprising. We might want to consider converting the NOW/DAY to a timestamp and updating the alias after the first document arrives for a DRA, thus creating a level "first date" across all categories. For a pure TRA this is not a problem because there is only one time series in play, and the first TRA collection is created, the start parameter is never used again. As I type this I think I just realized that the fix in the PR still has a problem... I suspect that the NOW/DAY config will erroneously reject any document not in the present day because there's no check to see if a first collection exists already hmm > Date Math in "start" attribute of routed alias causes exception > --- > > Key: SOLR-13760 > URL: https://issues.apache.org/jira/browse/SOLR-13760 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 8.3 >Reporter: Gus Heck >Assignee: Gus Heck >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The start parameter (for Time Routed Aliases and 2-Dimensional Routed Aliases > using time components) is meant to accept date math as well as a timestamp. > However it seems that none of the tests actually test this, and my changes > for DRA forgot to account for it in one place, so an exception is thrown > adding a document to an alias with such a configuration. Will add a test and > a fix. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929832#comment-16929832 ] ASF subversion and git services commented on SOLR-13452: Commit b2d0272cab8a6dd35f07bcd26a0cfccac53746d2 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_6 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b2d0272 ] SOLR-13452: Fix the fix for the strange 'xml-apis:xmlapis comes in on osx and not linux' issue. Also, update the consistent-versions plugin to 1.12.4. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929837#comment-16929837 ] ASF subversion and git services commented on SOLR-13452: Commit 538b3d129d41d7316ffcecf6bb9891f3b9ce499c in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_6 from markrmiller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=538b3d1 ] SOLR-13452: Set morfologik-ukrainian-search to a runtime dep. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] markrmiller opened a new pull request #880: Tweak header format.
markrmiller opened a new pull request #880: Tweak header format. URL: https://github.com/apache/lucene-solr/pull/880 test This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929851#comment-16929851 ] ASF subversion and git services commented on SOLR-13452: Commit 69cd6a57f9f6f22e809a0e03ab1032bf7fa3702e in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_7 from markrmiller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=69cd6a5 ] SOLR-13452: We can't use cached without issues, so use consistent and add note. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929850#comment-16929850 ] ASF subversion and git services commented on SOLR-13452: Commit 7694e72d0cec6d05a3e23187791ba54f47cb5560 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_7 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7694e72 ] SOLR-13452: For now we don't try and use local gradle caches. Need a solution that works well on Linux and OSX ideally. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13238) BlobHandler generates non-padded md5
[
https://issues.apache.org/jira/browse/SOLR-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-13238:
--
Assignee: Jan Høydahl
> BlobHandler generates non-padded md5
>
>
> Key: SOLR-13238
> URL: https://issues.apache.org/jira/browse/SOLR-13238
> Project: Solr
> Issue Type: Bug
> Components: blobstore
>Affects Versions: 6.0, 6.6.5, 7.0, 7.6, 7.7
>Reporter: Jeff Walraven
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Introduced in SOLR-6787
> The blob handler currently uses the following logic for generating/storing
> the md5 for uploads:
> {code:java}
> MessageDigest m = MessageDigest.getInstance("MD5");
> m.update(payload.array(), payload.position(), payload.limit());
> String md5 = new BigInteger(1, m.digest()).toString(16);
> {code}
> Unfortunately, this method does not provide padding for any md5 with less
> than 0x10 for its most significant byte. This means that on many occasions it
> could end up with a md5 hash of 31 characters instead of 32.
> I have opened a PR with the following recommended change:
> {code:java}
> String md5 = new String(Hex.encodeHex(m.digest()));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13753) Get GitHub to run 'ant precommit' as an action for all PRs
[ https://issues.apache.org/jira/browse/SOLR-13753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929865#comment-16929865 ] Mark Miller commented on SOLR-13753: Or I should say it just doesn't work well yet. The only workflows that will show up in GitHub UI are the ones specified in master - so you can configure other branches to also work in master, from that perspective you are find. Where it's supposed to get better any day now is making changes or adding a workflow in another branch - right now those might as well not exist and it's just the workflows in the default branch (currently master). > Get GitHub to run 'ant precommit' as an action for all PRs > -- > > Key: SOLR-13753 > URL: https://issues.apache.org/jira/browse/SOLR-13753 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > Get GitHub to run 'ant precommit' as a check for all PRs. This would make > things much nicer as GitHub would run the checks for us and it's easier to > track and fix when precommits are broken. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-11492) More Modern cloud dev script
[ https://issues.apache.org/jira/browse/SOLR-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929883#comment-16929883 ] Mark Miller commented on SOLR-11492: Also, let's remove the current cloud-dev scripts - they were meant to simulate a real env as much as possible - otherwise it would likely make sense these days to simple use MiniCloudCluster. The idea was having something closer to what a user would setup though - so let's remove those dinosaurs and put this in. > More Modern cloud dev script > > > Key: SOLR-11492 > URL: https://issues.apache.org/jira/browse/SOLR-11492 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 8.0 >Reporter: Gus Heck >Assignee: Gus Heck >Priority: Minor > Attachments: cloud.sh, cloud.sh, cloud.sh, cloud.sh, cloud.sh, > cloud.sh > > > Most of the scripts in solr/cloud-dev do things like start using java -jar > and other similarly ancient techniques. I recently decided I really didn't > like that it was a pain to setup a cloud to test a patch/feature and that > often one winds up needing to blow away existing testing so working on more > than one thing at a time is irritating... so here's a script I wrote, if > folks like it I'd be happy for it to be included in solr/cloud-dev -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-11492) More Modern cloud dev script
[ https://issues.apache.org/jira/browse/SOLR-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929882#comment-16929882 ] Mark Miller commented on SOLR-11492: We should also consider trying to add a little CI test for this with the new GitHub workflows/actions stuff so that it won't easily break. It's probably as simple as configuring a bash script to fail if a command fails and then running all the script targets. > More Modern cloud dev script > > > Key: SOLR-11492 > URL: https://issues.apache.org/jira/browse/SOLR-11492 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 8.0 >Reporter: Gus Heck >Assignee: Gus Heck >Priority: Minor > Attachments: cloud.sh, cloud.sh, cloud.sh, cloud.sh, cloud.sh, > cloud.sh > > > Most of the scripts in solr/cloud-dev do things like start using java -jar > and other similarly ancient techniques. I recently decided I really didn't > like that it was a pain to setup a cloud to test a patch/feature and that > often one winds up needing to blow away existing testing so working on more > than one thing at a time is irritating... so here's a script I wrote, if > folks like it I'd be happy for it to be included in solr/cloud-dev -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8723) Bad interaction bewteen WordDelimiterGraphFilter, StopFilter and FlattenGraphFilter
[
https://issues.apache.org/jira/browse/LUCENE-8723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929712#comment-16929712
]
Chongchen Chen commented on LUCENE-8723:
The workaround is putting the FlattenGraphFilter before StopFilter.
> Bad interaction bewteen WordDelimiterGraphFilter, StopFilter and
> FlattenGraphFilter
> ---
>
> Key: LUCENE-8723
> URL: https://issues.apache.org/jira/browse/LUCENE-8723
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Affects Versions: 7.7.1, 8.0
>Reporter: Nicolás Lichtmaier
>Priority: Major
>
> I was debugging an issue (missing tokens after analysis) and when I enabled
> Java assertions I uncovered a bug when using WordDelimiterGraphFilter +
> StopFilter + FlattenGraphFilter.
> I could reproduce the issue in a small piece of code. This code gives an
> assertion failure when assertions are enabled (-ea java option):
> {code:java}
> Builder builder = CustomAnalyzer.builder();
> builder.withTokenizer(StandardTokenizerFactory.class);
> builder.addTokenFilter(WordDelimiterGraphFilterFactory.class,
> "preserveOriginal", "1");
> builder.addTokenFilter(StopFilterFactory.class);
> builder.addTokenFilter(FlattenGraphFilterFactory.class);
> Analyzer analyzer = builder.build();
>
> TokenStream ts = analyzer.tokenStream("*", new StringReader("x7in"));
> ts.reset();
> while(ts.incrementToken())
> ;
> {code}
> This gives:
> {code}
> Exception in thread "main" java.lang.AssertionError: 2
> at
> org.apache.lucene.analysis.core.FlattenGraphFilter.releaseBufferedToken(FlattenGraphFilter.java:195)
> at
> org.apache.lucene.analysis.core.FlattenGraphFilter.incrementToken(FlattenGraphFilter.java:258)
> at com.wolfram.textsearch.AnalyzerError.main(AnalyzerError.java:32)
> {code}
> Maybe removing stop words after WordDelimiterGraphFilter is wrong, I don't
> know. However is the only way to process stop-words generated by that filter.
> In any case, it should not eat tokens or produce assertions.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13739) Managed resource observers have to be added only once
[ https://issues.apache.org/jira/browse/SOLR-13739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929716#comment-16929716 ] Thomas Wöckinger commented on SOLR-13739: - Thanks for fast review and your input! > Managed resource observers have to be added only once > - > > Key: SOLR-13739 > URL: https://issues.apache.org/jira/browse/SOLR-13739 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: 8.0, 8.1, master (9.0), 8.2, 8.1.1 >Reporter: Thomas Wöckinger >Assignee: David Smiley >Priority: Major > Labels: easyfix, performance, pull-request-available, > ready-to-commit > Fix For: 8.3 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > On huge schema modifications, mostly happen due to creation of a new > collection, the same observer instance of an ResourceLoaderAware component is > added again and again. > This leads to a runtime behaviour of n²/2 where n is is the number of schema > operation multiplied by ResourceLoaderAware components instead of the number > of containing ResourceLoaderAware components. > E.g. If you have 1000 schema operations and 2 ResourceLoaderAware components > this leads to 50 operations instead of 2000. > Even worse the corresponding resource is registered again and again, which > can take some time e.g. ManagedSynonymGraphFilterFactory needs about 5s on > each call (depending on the size of synonyms). -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929773#comment-16929773 ] Shawn Heisey commented on LUCENE-8951: -- bq. Maybe because you are "watcher" of this issue? If you count that, I actually get 3. But the one generated by watching isn't sent to issues@ and gets filtered to a different mail folder, because it doesn't have the List-Id header. I think I'm getting the other two because I signed up my usual apa...@elyograg.org email, and I'm also a moderator with elyog...@apache.org. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists (/) > # Announce to dev@ list that the change will happen (/) > # Modify Jira and Github bots to post to issues@ list instead of dev@ (/) > # Modify Jenkins (including Policeman and other) to post to builds@ (/) > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
