Re: [Phishing Risk] [External] Re: High concurrency scenarios IndexReader‘s registerParentReader method takes a lot of CPU time

[张海雷]

Using elastic search index stats 
apihttps://www.elastic.co/guide/en/elasticsearch/reference/current/indices-stats.html#indices-stats
 


> 2020年4月17日 下午11:49，Bruno Roustant  写道：
> 
> Hi,
> 
> Next time please reply/send these technical questions to 
> java-u...@lucene.apache.org  or 
> dev@lucene.apache.org  to get more audience.
> 
> 538 segments seems huge. What is your configuration to get this number of 
> segments?
> 
> Le jeu. 16 avr. 2020 à 16:28, 张海雷  > a écrit :
> 
> 
>> 
>> Hi, all
>> In our Elastic Search benchmark, found out that  IndexReader‘s 
>> registerParentReader method takes a lot of CPU time  
>> Environment:
>> ES Version: 7.5.1
>> Lucene Version: 8.3.0
>> 
>> Index:
>> Shard Num 1
>> Replicator’s Num:1
>> Segment Count: 538
>> Size:49.5GB
>> 
>> Benchmark result: qps:5200,pct99 600ms
>> CPU Util:93%
>> 
>> Use flame graph find the hot method  IndexReader‘s registerParentReader. 
>> dive into code find out that Have a  race condition that on the 
>> synchronizedSet Because of only one
>> Shard and one shard have too many segments, this intensify competition
>> 
>> 
>> 
>> 
>> To verify this assumption,execute force merge on this index，after force 
>> merge:
>> QPS: more then 5600
>> PCT99: 60ms
>> CPU Util: 11% 
>> The performance improved by a factor of 10x
>> 
>> So we can use ConcurrentWeakKeyHashmap instead of synchronizedSet  to reduce 
>> lock competition?
>> 
>> 
>> 
>> 
>> 
> 

Re: [DISCUSS] 8.5.2 Release?

[Tomás Fernández Löbbe]

+1. Thanks Mike

On Thu, May 7, 2020 at 2:55 PM Adrien Grand  wrote:

> +1
>
> Le jeu. 7 mai 2020 à 19:13, Mike Drob  a écrit :
>
>> Devs,
>>
>> I know that we had 8.5.1 only a few weeks ago, but with the fix for
>> LUCENE-9350 I think we should consider another bug-fix. I know that without
>> it I will be explicitly recommending several users to stay off of 8.5.x on
>> their upgrade plans. There are some pretty scary looking charts on
>> SOLR-14428 that describe the impact of the bug in more detail.
>>
>> I'd be happy to volunteer as RM for this, would probably be looking at
>> trying to get it a vote started sometime next week.
>>
>> Thanks,
>> Mike
>>
>>
>> https://issues.apache.org/jira/browse/SOLR-14428
>> https://issues.apache.org/jira/browse/LUCENE-9350
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: [DISCUSS] 8.5.2 Release?

[Adrien Grand]

+1

Le jeu. 7 mai 2020 à 19:13, Mike Drob  a écrit :

> Devs,
>
> I know that we had 8.5.1 only a few weeks ago, but with the fix for
> LUCENE-9350 I think we should consider another bug-fix. I know that without
> it I will be explicitly recommending several users to stay off of 8.5.x on
> their upgrade plans. There are some pretty scary looking charts on
> SOLR-14428 that describe the impact of the bug in more detail.
>
> I'd be happy to volunteer as RM for this, would probably be looking at
> trying to get it a vote started sometime next week.
>
> Thanks,
> Mike
>
>
> https://issues.apache.org/jira/browse/SOLR-14428
> https://issues.apache.org/jira/browse/LUCENE-9350
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [DISCUSS] 8.5.2 Release?

[Ishan Chattopadhyaya]

+1

On Fri, 8 May, 2020, 12:01 am Alan Woodward,  wrote:

> +1, thanks for volunteering Mike
>
> On 7 May 2020, at 19:03, Anshum Gupta  wrote:
>
> Thanks for doing this, Mike.
> +1 to the 8.5.2 release.
>
> On Thu, May 7, 2020 at 10:13 AM Mike Drob  wrote:
>
>> Devs,
>>
>> I know that we had 8.5.1 only a few weeks ago, but with the fix for
>> LUCENE-9350 I think we should consider another bug-fix. I know that without
>> it I will be explicitly recommending several users to stay off of 8.5.x on
>> their upgrade plans. There are some pretty scary looking charts on
>> SOLR-14428 that describe the impact of the bug in more detail.
>>
>> I'd be happy to volunteer as RM for this, would probably be looking at
>> trying to get it a vote started sometime next week.
>>
>> Thanks,
>> Mike
>>
>>
>> https://issues.apache.org/jira/browse/SOLR-14428
>> https://issues.apache.org/jira/browse/LUCENE-9350
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> Anshum Gupta
>
>
>

Re: [DISCUSS] 8.5.2 Release?

[Alan Woodward]

+1, thanks for volunteering Mike

> On 7 May 2020, at 19:03, Anshum Gupta  > wrote:
> 
> Thanks for doing this, Mike. 
> +1 to the 8.5.2 release. 
> 
> On Thu, May 7, 2020 at 10:13 AM Mike Drob  > wrote:
> Devs,
> 
> I know that we had 8.5.1 only a few weeks ago, but with the fix for 
> LUCENE-9350 I think we should consider another bug-fix. I know that without 
> it I will be explicitly recommending several users to stay off of 8.5.x on 
> their upgrade plans. There are some pretty scary looking charts on SOLR-14428 
> that describe the impact of the bug in more detail.
> 
> I'd be happy to volunteer as RM for this, would probably be looking at trying 
> to get it a vote started sometime next week.
> 
> Thanks,
> Mike
> 
> 
> https://issues.apache.org/jira/browse/SOLR-14428 
> 
> https://issues.apache.org/jira/browse/LUCENE-9350 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 
> 
> -- 
> Anshum Gupta

Re: [DISCUSS] 8.5.2 Release?

[Anshum Gupta]

Thanks for doing this, Mike.
+1 to the 8.5.2 release.

On Thu, May 7, 2020 at 10:13 AM Mike Drob  wrote:

> Devs,
>
> I know that we had 8.5.1 only a few weeks ago, but with the fix for
> LUCENE-9350 I think we should consider another bug-fix. I know that without
> it I will be explicitly recommending several users to stay off of 8.5.x on
> their upgrade plans. There are some pretty scary looking charts on
> SOLR-14428 that describe the impact of the bug in more detail.
>
> I'd be happy to volunteer as RM for this, would probably be looking at
> trying to get it a vote started sometime next week.
>
> Thanks,
> Mike
>
>
> https://issues.apache.org/jira/browse/SOLR-14428
> https://issues.apache.org/jira/browse/LUCENE-9350
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Anshum Gupta

[DISCUSS] 8.5.2 Release?

[Mike Drob]

Devs,

I know that we had 8.5.1 only a few weeks ago, but with the fix for LUCENE-9350 
I think we should consider another bug-fix. I know that without it I will be 
explicitly recommending several users to stay off of 8.5.x on their upgrade 
plans. There are some pretty scary looking charts on SOLR-14428 that describe 
the impact of the bug in more detail.

I'd be happy to volunteer as RM for this, would probably be looking at trying 
to get it a vote started sometime next week.

Thanks,
Mike


https://issues.apache.org/jira/browse/SOLR-14428
https://issues.apache.org/jira/browse/LUCENE-9350

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Bram Van Dam]

> The big question is this: “Is this the right time to split Solr and
> Lucene into two independent projects?”.

Sounds like there are quite a few tasks to complete to get this done.
Splitting the build and codebase. Presumably a bunch of administration
within Apache/the PMC. Setting up infrastructure etc.

These are the costs, to be paid up front in the currency of someone's
time. The benefits are less clear. Faster build times and easier
maintenance sound attractive, but when will those benefits be visible?
Next month? Or in a year?

Whoever will be doing this work should probably ask themselves the
questions: is this the best use of their time?

 - Bram

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: AttributeError: 'bool' object has no attribute 'setdefault'

[Andi Vajda]

On Thu, 7 May 2020, Chee Yong Teh wrote:


Hi Andi,

I think I got it working but there is an issue with the class name with '.'.

In the jar there are some class name like below

public static final class SensitivityProfileIdList.Builder
public static final class SRMBreakdown.Builder


Yes, these are so-called inner classes.


So JCC will wrap this can change the '.' to '$'


Which Java exposes to JCC with a '$' in place of the '.' in the name.


SensitivityProfileIdList$Builder
SRMBreakdown$Builder

I cannot really use this classes in python and python flag it up as syntax 
error. Would it be better to use '_' instead of '$' to replace the '.' in 
the class name?


That's definitely an option. Doing this automatically may then cause a clash 
with a class that uses _ already. There is a --rename flag that lets you

control the name to pick:

  --rename 
'full.package.path.here.SensitivityProfileIdList$Builder=SensitivityProfileIdList_Builder'

(you need '' around a string with literal $ in a shell command line)

Andi..



Thanks,

Chee Yong


Chee Yong Teh
27 Bush Lane, London, EC4R 0AN  |  +44 203 929 3138
OTC Infrastructure Service of the Year & ​Global Compression Service of the Year
-Original Message-
From: Andi Vajda 
Sent: 06 May 2020 00:34
To: Chee Yong Teh 
Cc: pylucene-dev@lucene.apache.org
Subject: Re: AttributeError: 'bool' object has no attribute 'setdefault'



On May 5, 2020, at 16:17, Chee Yong Teh  wrote:


Hi Andi,

Ok I have changed the command to

python -m jcc --version 7.1.4 --use_full_names --include 
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/smart-swapclear-public-release_daru.12.
jar --include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/colt-1.2.0.jar --include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/commons-math3-3.6.1.jar
--include /home/cheeyong .teh/SMART-API-7.1.4/smart/lib/jna-5.2.0.jar
--include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/log4j-1.2.16.jar
--include /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/proto
buf-java-3.5.1.jar --include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/slf4j-api-1.6.1.jar
--include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/slf4j-log4j12-1.6.1.jar
--py thon lch_smart --build --install
com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory

I'm using --include instead of --jar and pass in
com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory as a
class I want to wrap. It seem fine and everything build fine but when
I do a print(dir(lch_smart)). It doesn't seem to wrap that
SMARTClientDataProviderFactory class


print(dir(lch_smart))

['CLASSPATH', 'ConstVariableDescriptor', 'FinalizerClass',
'FinalizerProxy', 'InvalidArgsError', 'JArray', 'JArray_bool',
'JArray_byte', 'JArray_char', 'JArray_double', 'JArray_float',
'JArray_int', 'JArray_long', 'JArray_object', 'JArray_short',
'JArray_string', 'JCCEnv', 'JCC_VERSION', 'JObject', 'JavaError',
'PrintWriter', 'StringWriter', 'VERSION', '__builtins__',
'__cached__', '__doc__', '__file__', '__loader__', '__module_dir__',
'__name__', '__package__', '__path__', '__spec__', '_lch_smart',
'findClass', 'getVMEnv', 'initVM', 'makeClass', 'makeInterface', 'os']




You're using --use_full_names, thus to access the wrapper for 
com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory
you need to say:
 >>> from com.lchclearnet.swapclear.smart import SMARTClientDataProviderFactory

Andi..



If I use --jar option I will still get the "AttributeError: 'bool' object has no 
attribute 'setdefault'" error.

Thanks,

Chee Yong

Chee Yong Teh​
27 Bush Lane, London, EC4R 0AN   |   +44 203 929 3138

OTC Infrastructure Service of the Year & ​Global Compression Service
of the Year -Original Message-
From: Andi Vajda 
Sent: 05 May 2020 23:30
To: Chee Yong Teh 
Cc: pylucene-dev@lucene.apache.org
Subject: Re: AttributeError: 'bool' object has no attribute 'setdefault'


On Tue, 5 May 2020, Chee Yong Teh wrote:


Hi Andi,

That’s third party library jar file that we try to wrap so we can call it from 
python.

I don’t really know why they create a classes like that way.

Would you able to add an option to just only wrap classes under a
package like I want to wrap all public classes in package
com.lchclearnet.*

So any public classes under com.lchclearnet.swapclear and
com.lchclearnet.common will get wrapped? At the moment I think JCC
try to wrap all the public classes found in the jar if I pass in the
jar via -jar option.


I wonder why this isn't documented.
JCC's __main__.py file lists all the options you can use with JCC.
The one that doesn't seem listed is the non-option:
if a command line argument doesn't start with '-', then it is assumed
to be a class name. Better yet, you can also use a
className:methodName syntax to only wrap that. There is a large
example of a JCC invocation
here:
https://svn.apache.org/viewvc/lucene/pylucene/trunk/Makefile?view=mark
up look for org.apache.lucene.index.IndexWriter:getReader, for an
example.
For controlling which 

RE: AttributeError: 'bool' object has no attribute 'setdefault'

[Chee Yong Teh]

Hi Andi,

I think I got it working but there is an issue with the class name with '.'.

In the jar there are some class name like below

public static final class SensitivityProfileIdList.Builder
public static final class SRMBreakdown.Builder

So JCC will wrap this can change the '.' to '$'

SensitivityProfileIdList$Builder
SRMBreakdown$Builder

I cannot really use this classes in python and python flag it up as syntax 
error. Would it be better to use '_' instead of '$' to replace the '.' in the 
class name?

Thanks,

Chee Yong


Chee Yong Teh 
27 Bush Lane, London, EC4R 0AN  |  +44 203 929 3138 
OTC Infrastructure Service of the Year & ​Global Compression Service of the Year
-Original Message-
From: Andi Vajda  
Sent: 06 May 2020 00:34
To: Chee Yong Teh 
Cc: pylucene-dev@lucene.apache.org
Subject: Re: AttributeError: 'bool' object has no attribute 'setdefault'


> On May 5, 2020, at 16:17, Chee Yong Teh  wrote:
> 
> 
> Hi Andi,
> 
> Ok I have changed the command to
> 
> python -m jcc --version 7.1.4 --use_full_names --include 
> /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/smart-swapclear-public-release_daru.12.
> jar --include 
> /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/colt-1.2.0.jar --include 
> /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/commons-math3-3.6.1.jar 
> --include /home/cheeyong .teh/SMART-API-7.1.4/smart/lib/jna-5.2.0.jar 
> --include 
> /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/log4j-1.2.16.jar 
> --include /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/proto
> buf-java-3.5.1.jar --include 
> /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/slf4j-api-1.6.1.jar 
> --include 
> /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/slf4j-log4j12-1.6.1.jar 
> --py thon lch_smart --build --install 
> com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory
> 
> I'm using --include instead of --jar and pass in 
> com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory as a 
> class I want to wrap. It seem fine and everything build fine but when 
> I do a print(dir(lch_smart)). It doesn't seem to wrap that 
> SMARTClientDataProviderFactory class
> 
> >>> print(dir(lch_smart))
> ['CLASSPATH', 'ConstVariableDescriptor', 'FinalizerClass', 
> 'FinalizerProxy', 'InvalidArgsError', 'JArray', 'JArray_bool', 
> 'JArray_byte', 'JArray_char', 'JArray_double', 'JArray_float', 
> 'JArray_int', 'JArray_long', 'JArray_object', 'JArray_short', 
> 'JArray_string', 'JCCEnv', 'JCC_VERSION', 'JObject', 'JavaError', 
> 'PrintWriter', 'StringWriter', 'VERSION', '__builtins__', 
> '__cached__', '__doc__', '__file__', '__loader__', '__module_dir__', 
> '__name__', '__package__', '__path__', '__spec__', '_lch_smart', 
> 'findClass', 'getVMEnv', 'initVM', 'makeClass', 'makeInterface', 'os']
> >>>

You're using --use_full_names, thus to access the wrapper for 
com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory
you need to say: 
  >>> from com.lchclearnet.swapclear.smart import SMARTClientDataProviderFactory

Andi..

> 
> If I use --jar option I will still get the "AttributeError: 'bool' object has 
> no attribute 'setdefault'" error.
> 
> Thanks,
> 
> Chee Yong
> 
> Chee Yong Teh​ 
> 27 Bush Lane, London, EC4R 0AN |   +44 203 929 3138 
> 
> OTC Infrastructure Service of the Year & ​Global Compression Service 
> of the Year -Original Message-
> From: Andi Vajda 
> Sent: 05 May 2020 23:30
> To: Chee Yong Teh 
> Cc: pylucene-dev@lucene.apache.org
> Subject: Re: AttributeError: 'bool' object has no attribute 'setdefault'
> 
> 
> On Tue, 5 May 2020, Chee Yong Teh wrote:
> 
> > Hi Andi,
> >
> > That’s third party library jar file that we try to wrap so we can call it 
> > from python.
> >
> > I don’t really know why they create a classes like that way.
> >
> > Would you able to add an option to just only wrap classes under a 
> > package like I want to wrap all public classes in package
> > com.lchclearnet.*
> >
> > So any public classes under com.lchclearnet.swapclear and 
> > com.lchclearnet.common will get wrapped? At the moment I think JCC 
> > try to wrap all the public classes found in the jar if I pass in the 
> > jar via -jar option.
> 
> I wonder why this isn't documented.
> JCC's __main__.py file lists all the options you can use with JCC.
> The one that doesn't seem listed is the non-option:
> if a command line argument doesn't start with '-', then it is assumed 
> to be a class name. Better yet, you can also use a 
> className:methodName syntax to only wrap that. There is a large 
> example of a JCC invocation
> here:
> https://svn.apache.org/viewvc/lucene/pylucene/trunk/Makefile?view=mark
> up look for org.apache.lucene.index.IndexWriter:getReader, for an 
> example.
> For controlling which dependencies are pulled in, the answer is none unless 
> you declare them via --jar, other classes, or --package.
> 
> In other words, depending on your use case, you may be able to just generate 
> wrappers for the actual entrypoints you wish to call from Python and the 
> 

Re: Fwd: [ANNOUNCE] Apache Lucene 7.7.3 released

[Bram Van Dam]

Thanks all, for making this release, much appreciated!

On 04/05/2020 15:16, Noble Paul wrote:
>
>
> -- Forwarded message -
> From: *Noble Paul* mailto:no...@apache.org>>
> Date: Tue, Apr 28, 2020, 4:51 PM
> Subject: [ANNOUNCE] Apache Lucene 7.7.3 released
> To: mailto:annou...@apache.org>>
>
>
>
> 28 April 2020, Apache Lucene™ 7.7.3 available
> 
> The Lucene PMC is pleased to announce the release of Apache Lucene 7.7.3.
> 
> Apache Lucene is a high-performance, full-featured text search engine
> library written entirely in Java. It is a technology suitable for nearly
> any application that requires full-text search, especially cross-platform.
> 
> This release contains 1 bugfix in Lucene. The release is available for
> immediate download at:
>   
> 
> Please read CHANGES.txt for a full list of changes:
>   
> 
> Note: The Apache Software Foundation uses an extensive mirroring network
> for distributing releases. It is possible that the mirror you are using
> may not have replicated the release yet. If that is the case, please try
> another mirror. This also applies to Maven access.
> 
> --Noble Paul
> 
> -
> Noble Paul
> www.lucidworks.com 

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Adrien Grand]

There are definitely pros and cons of splitting vs. being a single project.
The bigger pains for me until now have been the following ones:

Digging Solr failures

The theory is that Solr failures can help find Lucene bugs that Lucene bugs
wouldn't catch, and while this occurred a couple times, I found the
benefit-cost ratio to not be interesting as Solr tests can be especially
hard to debug being integration tests that use threading and usually don't
reproduce failing seeds.

Synchronized releases

Releasing at the same time has created interesting situations in the past.
For instance, we have had several Lucene patch releases with empty
changelogs. Another problem is that the more changes go into a release, the
more likely you would find last-minute blockers and need to respin.
Splitting would help keep the scope of each release smaller and reduce
chances of needing to respin.

The argument has been made that we would still need to coordinate major
releases because of backward compatibility guarantees, but to be clear
we're talking about something that would be much more lightweight than the
coordination that we require today. It would be totally fine if Solr
released new major versions several months after Lucene, the only
requirement is to have the same cadence.

Adapting Solr to Lucene changes

Lucene embraces its N-1 backward compatibility policy to move forward, but
Solr is reluctant to. For instance uninverting and numeric fields have been
deprecated more than 4 years ago (in favor of doc values and points
respectively), but they are still used in Solr, and the task of finding way
to keep the functionality working after removing the feature from Lucene
fell on the plate of the person who drove the deprecation/removal in
Lucene. While some might argue that a full split might move the cursor too
far in the other direction, I feel that this is something we should work on
addressing, even if the final decision is to not split.

In the end, I think that Lucene and Solr should keep a close relationship,
but reducing coupling would help. I wish the two projects had a
relationship that looked more like the relationship that we have with
OpenJDK, testing early-access builds, embracing new features and
deprecations, but without forcing tight coupling. I don't have strong
feelings about splitting PMCs and making Solr a TLP vs. remaining the same
project, but I wish we would at least make Solr depend on Lucene JARs and
decouple builds/releases.


On Mon, May 4, 2020 at 11:11 AM Dawid Weiss  wrote:

> Dear Lucene and Solr developers!
>
> A few days ago, I initiated a discussion among PMC members about
> potential pros and cons of splitting the project into separate Lucene
> and Solr entities by promoting Solr to its own top-level Apache
> project (TLP). Let me share with you the motivation for such an action
> and some follow-up thoughts I heard from other PMC members so far.
>
> Please read this e-mail carefully. Both the PMC and I look forward to
> hearing your opinion. This is a DISCUSS thread and it will be followed
> next week by a VOTE thread. This is our shared project and we should
> all shape its future responsibly.
>
> The big question is this: “Is this the right time to split Solr and
> Lucene into two independent projects?”.
>
> Here are several technical considerations that drove me to ask the
> question above (in no order of priorities):
>
> 1) Precommit/ test times. These are crazy high. If we split into two
> projects we can pretty much cut all of Lucene testing out of Solr (and
> likewise), making development a bit more fun again.
>
> 2) Build system itself and source release packaging. The current
> combined codebase is a *beast* to maintain. Working with gradle on
> both projects at once made me realise how little the two have in
> common. The code layout, the dependencies, even the workflow of people
>
> working on these projects... The build (both ant and gradle) is full
> of Solr and Lucene-specific exceptions and hooks that could be more
> elegantly solved if moved to each project independently.
>
> 3) Packaging. There is no single source distribution package for
> Solr+Lucene. They are already "independent" there. Why should Lucene
> and Solr always be released at the same pace? Does it always make
> sense?
>
> 4) Solr is essentially taking in Lucene and its dependencies as a
> whole (so is Elasticsearch and many other projects). In my opinion
> this makes Lucene eligible for refactoring and
>
> maintenance as a separate component. The learning curve for people
> coming to each project separately is going to be gentler than trying
> to dive into the combined codebase.
>
> 5) Mailing lists, build servers. Mailing lists for users are already
> separated. I think this is yet another indication that Solr is
> something more than a component within Lucene. It is perceived as an
> independent entity and used as an independent product. I would really
> like to have separate mailing lists for