Re: Communicating the future of DIH?

I think that the fact that this code is no longer under the Apache umbrella will lead to such issues and moving this into a different GitHub org wouldn't really help with the problem that's been highlighted. Also, the maintainers of a plugin should be people who understand and monitor the project a

Re: Communicating the future of DIH?

Our messages crossed, but I read yours after I sent mine and I think I agree with you. I hear “deprecated” and think “it’s going away someday” but I keep getting questions from people (even inside Lucidworks) who are panicking like it’s gone in 8.6.3 already. Speaking more generally, though, in

Re: Communicating the future of DIH?

Thanks Cassandra. I read it. IMO, I think the word "Deprecated" is just too misleading for plugins that are *moving*. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Thu, Oct 15, 2020 at 5:16 PM Cassandra Targett wrote: > I updated the Ref Guide

Re: Communicating the future of DIH?

I updated the Ref Guide for 8.7 to include a link to the plugin repo (for all plugins which have an established repo, not just DIH), hoping that would help answer user questions and spur adoption. That’s just a super-minor thing, but it’s something. If Rohit doesn’t have time to be a maintainer

Re: Communicating the future of DIH?

BTW I think a consultant/consuntancy would do good business in taking ownership of DIH. Loads of people use it and some will come looking to pay for help! Heck, even a user of my tiny HTTP Proxy Servlet https://github.com/mitre/HTTP-Proxy-Servlet/ inquired about paid support! If I was still a fre

Re: Communicating the future of DIH?

I'm glad you're raising this because I've been meaning get more visibility on a proposal I made in JIRA: https://issues.apache.org/jira/browse/SOLR-12987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17203524#comment-17203524

Re: Communicating the future of DIH?

Some of those issues are opened by me, not beause I plan to be a DIH maintainer myself, but I was hoping that Rohit had some real interest in forming a comunity. Turns out that the plugin is as good as dead on arrival, which is really disappointing. We as the donator could perhaps help by sendi

Re: Communicating the future of DIH?

There’s always issues opened in every product that aren’t being closed. Everyone who knows it or cares about it should be pitching in. Marcus On Thu, Oct 15, 2020 at 12:21 Eric Pugh wrote: > I noticed that we’re getting tickets like SOLR-14938 opened that are all > about the future of DIH. I k

Potential memory leak on ReplicationHandler

Hi, I seem to experience a memory leak on my Solr Cloud cluster with 3 TLOG machines. Followers in this configuration get ReplicationHandlers reloaded - old ReplicationHandler would be shut down and new one created and registered. As part of registration ReplicationHandler is added to SolrCore clo

Communicating the future of DIH?

I noticed that we’re getting tickets like SOLR-14938 opened that are all about the future of DIH. I know some of my own clients are asking about it as well. I suspect we will get more and more of these! I wonder if there are any ideas/suggestions on how to better communicate that DIH isn’t g

Re: Index documents in async way

> > What I mean here is right now, when we send a batch of documents to Solr. > We still process it as concrete - unrelated documents by indexing one by > one. If indexing the fifth document causing error, that won't affect > already indexed 4 documents. Using this model we can index the batch in a

RE: [JENKINS] Lucene-Solr-master-Linux (64bit/jdk-12.0.2) - Build # 28332 - Failure!

Hi Noble, this file and directory is still there, just empty: https://github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/cloud/rule/RulesTest.java This causes license check to fail. Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u.

Re: Index documents in async way

> The biggest problem I have with this is that the client doesn't know about indexing problems without awkward callbacks later to see if something went wrong. Even simple stuff like a schema problem (e.g. undefined field). It's a useful *option*, any way. > Currently we now guarantee that if solr