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

[Andi Vajda]

> 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=markup
> 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 
> dependencies implied in the method signatures need to be declare manually via 
> other classes, --jar or --package. Also, be aware of --jar vs --include.
> See __main__.py for details:
> https://svn.apache.org/viewvc/lucene/pylucene/trunk/jcc/jcc3/__main__.py?view=markup
> 
> 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 
> > 
> > From: Andi Vajda 
> > Sent: Tuesday, May 5, 2020 10:17:18 PM
> > To: Chee Yong Teh 
> > Cc: va...@apache.org 
> > Subject: Re: AttributeError: 'bool' object has no attribute 'setdefault'
> >
> >
> > So if looks like you have classes and packages using the same names. 
> > This could be triggering a bug in jcc.
> > Let me try this locally.
> > Just curious, what are all 

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

[Chee Yong Teh]

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']
>>>

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=markup
   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 
dependencies implied in the method signatures need to be declare manually via 
other classes, --jar or --package. Also, be aware of --jar vs --include.
See __main__.py for details:
   
https://svn.apache.org/viewvc/lucene/pylucene/trunk/jcc/jcc3/__main__.py?view=markup

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 
> 
> From: Andi Vajda 
> Sent: Tuesday, May 5, 2020 10:17:18 PM
> To: Chee Yong Teh 
> Cc: va...@apache.org 
> Subject: Re: AttributeError: 'bool' object has no attribute 'setdefault'
>
>
> So if looks like you have classes and packages using the same names. 
> This could be triggering a bug in jcc.
> Let me try this locally.
> Just curious, what are all these 'a' classes ?
>
> Andi..
>
> On May 5, 2020, at 10:47, Chee Yong Teh  wrote:
>
> 
> HI Andi,
>
> Please see below print out
>
> -declares : {,  java.lang.Class>, ,  interface it.unimi.dsi.fastutil.h.au>,  it.unimi.dsi.fastutil.h.H>} --declareNames : ['it', 'unimi', 'dsi', 
> 'fastutil', 'h'] ---declareName : it ---namespace : {} ---declareName 
> : unimi ---namespace : {} ---declareName : dsi ---namespace : {} 
> ---declareName : fastutil ---namespace : {} --declareNames : ['java', 
> 'lang', 'Class'] 

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

[Andi Vajda]

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=markup
  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 
dependencies implied in the method signatures need to be declare manually 
via other classes, --jar or --package. Also, be aware of --jar vs --include.

See __main__.py for details:
  
https://svn.apache.org/viewvc/lucene/pylucene/trunk/jcc/jcc3/__main__.py?view=markup

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

From: Andi Vajda 
Sent: Tuesday, May 5, 2020 10:17:18 PM
To: Chee Yong Teh 
Cc: va...@apache.org 
Subject: Re: AttributeError: 'bool' object has no attribute 'setdefault'


So if looks like you have classes and packages using the
same names. This could be triggering a bug in jcc.
Let me try this locally.
Just curious, what are all these 'a' classes ?

Andi..

On May 5, 2020, at 10:47, Chee Yong Teh  wrote:


HI Andi,

Please see below print out

-declares : {, , 
, , 
}
--declareNames : ['it', 'unimi', 'dsi', 'fastutil', 'h']
---declareName : it
---namespace : {}
---declareName : unimi
---namespace : {}
---declareName : dsi
---namespace : {}
---declareName : fastutil
---namespace : {}
--declareNames : ['java', 'lang', 'Class']
---declareName : java
---namespace : {'it': {'unimi': {'dsi': {'fastutil': {'h': True}
---declareName : lang
---namespace : {}
--declareNames : ['it', 'unimi', 'dsi', 'fastutil', 'h', 'au']
---declareName : it
---namespace : {'it': {'unimi': {'dsi': {'fastutil': {'h': True, 'java': 
{'lang': {'Class': True}}}
---declareName : unimi
---namespace : {'unimi': {'dsi': {'fastutil': {'h': True
---declareName : dsi
---namespace : {'dsi': {'fastutil': {'h': True}}}
---declareName : fastutil
---namespace : {'fastutil': {'h': True}}
---declareName : h
---namespace : {'h': True}

Above is one of many classes that hit with the 'bool' object has no attribute 
'setdefault'. Another one

-declares : {, , 
, , , 
}
--declareNames : ['java', 'lang', 'Class']
---declareName : java
---namespace : {}
---declareName : lang
---namespace : {}
--declareNames : ['swapclear', 'com', 'lchclearnet', 'c', 'a', 'a', 'a', 'a']
---declareName : swapclear
---namespace : {'java': {'lang': {'Class': True}}}
---declareName : com
---namespace : {}
---declareName : lchclearnet
---namespace : {}
---declareName : c
---namespace : {}
---declareName : a
---namespace : {}
---declareName : a
---namespace : {}
---declareName : a
---namespace : {}
--declareNames : ['swapclear', 'com', 'lchclearnet', 'c', 'a', 'b', 'a', 'a']
---declareName : swapclear
---namespace : {'java': {'lang': {'Class': True}}, 'swapclear': {'com': 
{'lchclearnet': {'c': {'a': {'a': {'a': {'a': True
---declareName : com
---namespace : {'com': {'lchclearnet': {'c': {'a': {'a': {'a': {'a': True}}}
---declareName : lchclearnet
---namespace : {'lchclearnet': {'c': {'a': {'a': {'a': {'a': True}}
---declareName : c
---namespace : {'c': {'a': {'a': {'a': {'a': True}
---declareName : a
---namespace : {'a': {'a': {'a': {'a': True
---declareName : b
---namespace : {'a': {'a': {'a': True}}}
---declareName : a
---namespace : {}
--declareNames : ['swapclear', 'com', 'lchclearnet', 'c', 'a', 'b', 'a', 'a', 
'a', 'a', 'a', 'a']
---declareName : swapclear
---namespace : {'java': {'lang': {'Class': True}}, 'swapclear': {'com': 
{'lchclearnet': {'c': {'a': {'a': {'a': {'a': True}}, 'b': {'a': {'a': 
True
---declareName : com
---namespace : {'com': {'lchclearnet': {'c': {'a': {'a': {'a': {'a': True}}, 
'b': {'a': {'a': True}}}
---declareName : lchclearnet
---namespace : {'lchclearnet': 

Re: PLEASE READ! BadApple report. Last week was horrible!

[Erick Erickson]

OK, thanks Chris. 

The 24 hour rollup still shows many failures in the several classes, I’ll check 
tomorrow
to see if that’s a consequence of the disk full problem.

> On May 5, 2020, at 1:41 PM, Chris Hostetter  wrote:
> 
> 
> : And FWIW, I beasted one of the failing suites last night _without_ 
> : Mike’s changes and didn’t get any failures so I can’t say anything about 
> : whether Mike’s changes helped or not.
> 
> IIUC McCandless's failure only affects you if you use the "jenkins" test 
> data file (the really big wikipedia dump) ... see the jira he mentioned 
> for details.
> 
> 
> 
> -Hoss
> http://www.lucidworks.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


-
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)

[Tomás Fernández Löbbe]

On Tue, May 5, 2020 at 12:37 PM Dawid Weiss  wrote:

> > I read “promotion to TLP” as if this was some achievement that needs to
> be celebrated now.
>
> I honestly believe it is an achievement for a project to receive
> top-level status. It's a sign of having a community of users,
> committers and processes mature enough to empower its further
> development.
>

My point is that this is not something new. Solr is a mature product and
has had the community and process in place for a long time.


>
> > It’s technically true that Solr is a subproject of Lucene, but so is
> Lucene Core, and I don’t see Lucene Core being promoted to TLP
>
> I don't think these are same magnitude components, sorry. I can name
> at least a few projects that depend on Lucene alone (core + extras)
> and I can name companies using Solr as a product but I can't name a
> single project that would depend on lucene-core alone (without any
> other lucene-* dependency). Maybe there is something like this but
> it's definitely an outlier example of a typical use case.
>

If you go to lucene.apache.org, you'll see three things: Lucene Core
(Lucene with all it's modules), Solr and PyLucene. That's what I mean.


>
> Dawid
>
> -
> 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)

[Dawid Weiss]

> I read “promotion to TLP” as if this was some achievement that needs to be 
> celebrated now.

I honestly believe it is an achievement for a project to receive
top-level status. It's a sign of having a community of users,
committers and processes mature enough to empower its further
development.

> It’s technically true that Solr is a subproject of Lucene, but so is Lucene 
> Core, and I don’t see Lucene Core being promoted to TLP

I don't think these are same magnitude components, sorry. I can name
at least a few projects that depend on Lucene alone (core + extras)
and I can name companies using Solr as a product but I can't name a
single project that would depend on lucene-core alone (without any
other lucene-* dependency). Maybe there is something like this but
it's definitely an outlier example of a typical use case.

Dawid

-
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)

[Dawid Weiss]

> Question: When Lucene no longer has the Solr test suite to help catch bugs, 
> how long time would it take from a Lucene commit, before Solr/ES Jenkins 
> instances would have had time to produce a build and run tests? Would it be 
> possible to setup a trigger in Solr Jenkins?

It depends how the code is organized after Lucene becomes a
subcomponent. If it's a regular dependency (on a *-SNAPSHOT version)
then the trigger would have to be dual (any commit on Solr or any
commit on Lucene). If the code is organized around a git submodule
with Lucene then bumping a version on a submodule would effectively
trigger a CI build. This "bumping" can be automated on certain
branches (such as master) so effectively it'd be immediately ready for
testing...

It's not really that relevant to this discussion but if you're curious
what this looks like I created an example submodule setup reflecting
current master here, try it:

git clone g...@github.com:dweiss/lucene-solr.git -b split/solr
cd lucene-solr/

you'll see the 'lucene/ folder is empty. It is a  submodule. When you issue:

git submodule status

you'll see which git revision that submodule is on:

-e5092db7915ac49d0ade0591e7b52176657c380c lucene

You can get the sub repositories in their respective versions by doing:

git submodule init
git submodule update

When you cd into lucene now you'll see it is a separate repository
(that things can be committed to, branches switched, etc.).

git status
HEAD detached at e5092db791
nothing to commit, working tree clean

Submodules in git have an extra advantage over snapshot dependencies:
they always point at a given revision of a submodule *exactly* so each
and every commit in the parent repository has exact versions of each
submodule recorded in git history. Of course not everything is rosy -
working with submodule-organized repositories does have a darker side
too (new git workflows to be learned, switching incompatible branches
can be tricky, etc.).

D.

-
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'

[Chee Yong Teh]

HI Andi,

Please see below print out

-declares : {, , , , }
--declareNames : ['it', 'unimi', 'dsi', 'fastutil', 'h']
---declareName : it
---namespace : {}
---declareName : unimi
---namespace : {}
---declareName : dsi
---namespace : {}
---declareName : fastutil
---namespace : {}
--declareNames : ['java', 'lang', 'Class']
---declareName : java
---namespace : {'it': {'unimi': {'dsi': {'fastutil': {'h': True}
---declareName : lang
---namespace : {}
--declareNames : ['it', 'unimi', 'dsi', 'fastutil', 'h', 'au']
---declareName : it
---namespace : {'it': {'unimi': {'dsi': {'fastutil': {'h': True, 'java': 
{'lang': {'Class': True}}}
---declareName : unimi
---namespace : {'unimi': {'dsi': {'fastutil': {'h': True
---declareName : dsi
---namespace : {'dsi': {'fastutil': {'h': True}}}
---declareName : fastutil
---namespace : {'fastutil': {'h': True}}
---declareName : h
---namespace : {'h': True}

Above is one of many classes that hit with the 'bool' object has no attribute 
'setdefault'. Another one

-declares : {, , , , , }
--declareNames : ['java', 'lang', 'Class']
---declareName : java
---namespace : {}
---declareName : lang
---namespace : {}
--declareNames : ['swapclear', 'com', 'lchclearnet', 'c', 'a', 'a', 'a', 'a']
---declareName : swapclear
---namespace : {'java': {'lang': {'Class': True}}}
---declareName : com
---namespace : {}
---declareName : lchclearnet
---namespace : {}
---declareName : c
---namespace : {}
---declareName : a
---namespace : {}
---declareName : a
---namespace : {}
---declareName : a
---namespace : {}
--declareNames : ['swapclear', 'com', 'lchclearnet', 'c', 'a', 'b', 'a', 'a']
---declareName : swapclear
---namespace : {'java': {'lang': {'Class': True}}, 'swapclear': {'com': 
{'lchclearnet': {'c': {'a': {'a': {'a': {'a': True
---declareName : com
---namespace : {'com': {'lchclearnet': {'c': {'a': {'a': {'a': {'a': True}}}
---declareName : lchclearnet
---namespace : {'lchclearnet': {'c': {'a': {'a': {'a': {'a': True}}
---declareName : c
---namespace : {'c': {'a': {'a': {'a': {'a': True}
---declareName : a
---namespace : {'a': {'a': {'a': {'a': True
---declareName : b
---namespace : {'a': {'a': {'a': True}}}
---declareName : a
---namespace : {}
--declareNames : ['swapclear', 'com', 'lchclearnet', 'c', 'a', 'b', 'a', 'a', 
'a', 'a', 'a', 'a']
---declareName : swapclear
---namespace : {'java': {'lang': {'Class': True}}, 'swapclear': {'com': 
{'lchclearnet': {'c': {'a': {'a': {'a': {'a': True}}, 'b': {'a': {'a': 
True
---declareName : com
---namespace : {'com': {'lchclearnet': {'c': {'a': {'a': {'a': {'a': True}}, 
'b': {'a': {'a': True}}}
---declareName : lchclearnet
---namespace : {'lchclearnet': {'c': {'a': {'a': {'a': {'a': True}}, 'b': {'a': 
{'a': True}}
---declareName : c
---namespace : {'c': {'a': {'a': {'a': {'a': True}}, 'b': {'a': {'a': True}
---declareName : a
---namespace : {'a': {'a': {'a': {'a': True}}, 'b': {'a': {'a': True
---declareName : b
---namespace : {'a': {'a': {'a': True}}, 'b': {'a': {'a': True}}}
---declareName : a
---namespace : {'a': {'a': True}}
---declareName : a
---namespace : {'a': True}
---declareName : a
---namespace : True

So I'm not sure how many classes in the jar that causing this issue.

There is a similar code in python.py line 1547

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 17:50
To: pylucene-dev@lucene.apache.org
Subject: Re: AttributeError: 'bool' object has no attribute 'setdefault'


On Mon, 4 May 2020, Chee Yong Teh wrote:

> I'm in the processing of testing JCC to wrap third party library jar.
>
> When I run JCC 3.7 I got the following error
>
> Traceback (most recent call last):
>  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
>"__main__", mod_spec)
>  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
>exec(code, run_globals)
>  File 
> "/home/cheeyong.teh/venv/simm/lib/python3.6/site-packages/jcc/__main__.py", 
> line 107, in 
>cpp.jcc(sys.argv)
>  File "/home/cheeyong.teh/venv/simm/lib/python3.6/site-packages/jcc/cpp.py", 
> line 711, in jcc
>_dll_export)
>  File "/home/cheeyong.teh/venv/simm/lib/python3.6/site-packages/jcc/cpp.py", 
> line 937, in header
>namespace = namespace.setdefault(declareName, {})
> AttributeError: 'bool' object has no attribute 'setdefault'
>
> This line "namespace = namespace.setdefault(declareName, {})" assume 
> namespace.setdefault(declareName, {}) will return {} but somehow it 
> returns True. So namespace has True value and it errors in next 
> iteration in the loop. Not sure it's a bug or the jar is too 
> complicated to parse/convert due to a directory/structure. I can send 
> over the library if you need to debug/reproduce the error on your 
> machine

Could you please put a conditional breakpoint before the 

Re: PLEASE READ! BadApple report. Last week was horrible!

[Chris Hostetter]

: And FWIW, I beasted one of the failing suites last night _without_ 
: Mike’s changes and didn’t get any failures so I can’t say anything about 
: whether Mike’s changes helped or not.

IIUC McCandless's failure only affects you if you use the "jenkins" test 
data file (the really big wikipedia dump) ... see the jira he mentioned 
for details.



-Hoss
http://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)

[Tomás Fernández Löbbe]

I don’t agree with the argument “Solr outgrew being a subproject of
Lucene”. I read “promotion to TLP” as if this was some achievement that
needs to be celebrated now. Solr didn’t become a TLP years ago because the
decision then was to merge with Lucene development, thinking they would
progress better together than separated. It’s technically true that Solr is
a subproject of Lucene, but so is Lucene Core, and I don’t see Lucene Core
being promoted to TLP. They are both part of the same Apache project, which
for historical reasons is called Lucene.

> I would be curious if people can make the argument for keeping them
together...

I think the same arguments that were used 10 years ago to merge the
projects are as valid now, some of them presented in Dawid’s email. Faster
development, better coverage, code in the right places.[1]

IMO, if we need to say “we can’t release X because it breaks Y”, or “we
need to release X to be able to release Y”, the projects are not really
independent, and “the PMCs will overlap” won’t take us very far.

> The big question is this: “Is this the right time to split Solr and
Lucene into two independent projects?”.
This is not the question we should be asking ourselves right now. It
assumes the split is happening, and that’s what we are trying to discuss
here. The question in my mind is “Is splitting Lucene and Solr into
different project beneficial for them? Is this going to make them both
better?"

> As it is today, deveopers have had to do necessary Solr changes at the
same time when doing changes in Lucene. This is not really fair to the
(mainly) Lucene developers. It is not fair to Solr either, as such work
might be done in a hasty fashion and/or in a sub optimal way due to lack of
familiarity with Solr code base; like we unfortunately have seen a couple
of times in the past (not trying to blame anyone).

This, I agree, is a pain point for keeping them together. That said, while
not all, most currently active committers joined the project while this was
already a thing, it’s not something that was imposed later to the majority
of us.

> With Lucene as a dependency, Solr can choose to stay on same Lucene
version for a couple of releases while taking the time to work out the
proper way to adapt to changed Lucene APIs or to sort out performance
issues.

I agree with this and I believe it’s a point in favor of keeping them
together (and in part discussed 10 years ago when projects merged). Keeping
them on the same repo forces Solr to use the latest Lucene, helping find
issues/bugs soon, hopefully before they are released.


[1]
https://mail-archives.apache.org/mod_mbox/lucene-general/201002.mbox/%3c9ac0c6aa1002240832x1a8e3309k6799d75b8d19d...@mail.gmail.com%3e

On Tue, May 5, 2020 at 8:56 AM Michael McCandless 
wrote:

> On Tue, May 5, 2020 at 11:41 AM Jan Høydahl  wrote:
>
> As it is today, deveopers have had to do necessary Solr changes at the
>> same time when doing changes in Lucene. This is not really fair to the
>> (mainly) Lucene developers. It is not fair to Solr either, as such work
>> might be done in a hasty fashion and/or in a sub optimal way due to lack of
>> familiarity with Solr code base; like we unfortunately have seen a couple
>> of times in the past (not trying to blame anyone). With Lucene as a
>> dependency, Solr can choose to stay on same Lucene version for a couple of
>> releases while taking the time to work out the proper way to adapt to
>> changed Lucene APIs or to sort out performance issues.
>>
>
> +1, that is a great point, Jan.
>
> This will mean that the (any) necessary Solr source code changes that go
> along with a Lucene change will (sometimes) be done with higher quality,
> more thought, better expertise, etc., which I agree will be good for
> ongoing Solr development, help prevent accidental performance regressions,
> etc.  Net/net that's a big positive for Solr, in addition to having a
> stronger independent identity (https://solr.apache.org).
>
>
>> Question: When Lucene no longer has the Solr test suite to help catch
>> bugs, how long time would it take from a Lucene commit, before Solr/ES
>> Jenkins instances would have had time to produce a build and run tests?
>> Would it be possible to setup a trigger in Solr Jenkins?
>>
>
> That's a great question!
>
> Maybe Elasticsearch developers could chime in, since this already happened
> for them many times by now :)  I would think there are technical solutions
> to let the Solr CI build pull the latest Lucene snapshot build, to keep the
> latency lowish, but I do not know the details.
>
> Mike
>

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

[Andi Vajda]

On Mon, 4 May 2020, Chee Yong Teh wrote:


I'm in the processing of testing JCC to wrap third party library jar.

When I run JCC 3.7 I got the following error

Traceback (most recent call last):
 File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
   "__main__", mod_spec)
 File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
   exec(code, run_globals)
 File "/home/cheeyong.teh/venv/simm/lib/python3.6/site-packages/jcc/__main__.py", 
line 107, in 
   cpp.jcc(sys.argv)
 File "/home/cheeyong.teh/venv/simm/lib/python3.6/site-packages/jcc/cpp.py", 
line 711, in jcc
   _dll_export)
 File "/home/cheeyong.teh/venv/simm/lib/python3.6/site-packages/jcc/cpp.py", 
line 937, in header
   namespace = namespace.setdefault(declareName, {})
AttributeError: 'bool' object has no attribute 'setdefault'

This line "namespace = namespace.setdefault(declareName, {})" assume 
namespace.setdefault(declareName, {}) will return {} but somehow it returns True. So 
namespace has True value and it errors in next iteration in the loop. Not sure it's a bug 
or the jar is too complicated to parse/convert due to a directory/structure. I can send 
over the library if you need to debug/reproduce the error on your machine


Could you please put a conditional breakpoint before the line where this 
error happens and tell me what 'declares' is set to ?


Thanks !

Andi..



The commandline I use

python -m jcc \
--use_full_names \
--no-generics \
--jar lib/smart-swapclear-public-release_daru.12.jar \
--include lib/colt-1.2.0.jar \
--include lib/commons-math3-3.6.1.jar \
--include lib/jna-5.2.0.jar \
--include lib/log4j-1.2.16.jar \
--include lib/protobuf-java-3.5.1.jar \
--include lib/slf4j-api-1.6.1.jar \
--include lib/slf4j-log4j12-1.6.1.jar \
--python lch_smart --build -install

Another question,  --jar option seem to wrap all the public classes found 
inside the jar. Is there an option that only wrap certain public classes under 
package com.lchclearnet.* inside a jar? There is an option called exclude for 
classes but it will be nightmare to workout all the classes I don't want to 
wrap inside the jar.

Thanks,

Kinds regards,

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

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast Ltd, an innovator in Software as a Service 
(SaaS) for business. Providing a safer and more useful place for your human 
generated data. Specializing in; Security, archiving and compliance. To find 
out more visit the Mimecast website.

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

[Michael McCandless]

On Tue, May 5, 2020 at 11:41 AM Jan Høydahl  wrote:

As it is today, deveopers have had to do necessary Solr changes at the same
> time when doing changes in Lucene. This is not really fair to the (mainly)
> Lucene developers. It is not fair to Solr either, as such work might be
> done in a hasty fashion and/or in a sub optimal way due to lack of
> familiarity with Solr code base; like we unfortunately have seen a couple
> of times in the past (not trying to blame anyone). With Lucene as a
> dependency, Solr can choose to stay on same Lucene version for a couple of
> releases while taking the time to work out the proper way to adapt to
> changed Lucene APIs or to sort out performance issues.
>

+1, that is a great point, Jan.

This will mean that the (any) necessary Solr source code changes that go
along with a Lucene change will (sometimes) be done with higher quality,
more thought, better expertise, etc., which I agree will be good for
ongoing Solr development, help prevent accidental performance regressions,
etc.  Net/net that's a big positive for Solr, in addition to having a
stronger independent identity (https://solr.apache.org).


> Question: When Lucene no longer has the Solr test suite to help catch
> bugs, how long time would it take from a Lucene commit, before Solr/ES
> Jenkins instances would have had time to produce a build and run tests?
> Would it be possible to setup a trigger in Solr Jenkins?
>

That's a great question!

Maybe Elasticsearch developers could chime in, since this already happened
for them many times by now :)  I would think there are technical solutions
to let the Solr CI build pull the latest Lucene snapshot build, to keep the
latency lowish, but I do not know the details.

Mike

Re: Occasional compilation failures from gradle build

[David Smiley]

I see it often; I raised this in slack a few weeks ago.  Kevin & Mike Drob
responded.  It seems "gw clean" makes it go away.  Still, this is annoying
and points to a problem we should address.

~ David


On Tue, May 5, 2020 at 8:40 AM Erick Erickson 
wrote:

> I was doing quite a bit of building the assemble and dev tasks and never
> saw this. Of course I was bouncing between and and gradle a lot and
> habitually executed a "git clean -d -x -f”, don’t have a clue whether
> that’d be relevant, though I rather doubt it is.
>
> > On May 5, 2020, at 7:27 AM, Alan Woodward  wrote:
> >
> > Hi all,
> >
> > In about 50% of my gradle precommit runs, I get a Solr compilation error
> that looks like this:
> >
> >
> /Users/romseygeek/projects/lucene-solr/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsTestUtil.java:44:
> error: BlockPoolSlice is not public in
> org.apache.hadoop.hdfs.server.datanode.fsdataset.impl; cannot be accessed
> from outside package
> > import
> org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.BlockPoolSlice;
> >
> > From what I can tell, this class is designed to override classes from
> Hadoop to fix certain bugs, but it seems that gradle is sometimes putting
> the original Hadoop class files first in the class path, so the overridden
> class is not picked up.
> >
> > Is anyone else seeing this?
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> 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)

[Jan Høydahl]

Thanks for bringing it up Dawid.

I’ve asked myself the same question several times over the last couple of 
years, and have kind of been waiting for someone to make the proposal :)
In my head, Solr has out-grown being a sub project of Lucene, like hadoop, 
mahout, nutch and tika before it.

The move will promote Solr as a separate TLP with better visibility and more 
autonomy.
Simply put Solr will go from https://lucene.apache.org/solr/ to 
https://solr.apache.org/

Splitting will be lots of work for sure, but I am not worried about the future 
relationship between the two. The last couple of years most og us have already 
done LUCENE and SOLR changes in separate Jiras and separate patches, first 
committing changes to LUCENE before the related SOLR change. It will be more or 
less the same approach after the split, just that there will be a couple of 
days between the Lucene release and the next Solr release depending on it.

As it is today, deveopers have had to do necessary Solr changes at the same 
time when doing changes in Lucene. This is not really fair to the (mainly) 
Lucene developers. It is not fair to Solr either, as such work might be done in 
a hasty fashion and/or in a sub optimal way due to lack of familiarity with 
Solr code base; like we unfortunately have seen a couple of times in the past 
(not trying to blame anyone). With Lucene as a dependency, Solr can choose to 
stay on same Lucene version for a couple of releases while taking the time to 
work out the proper way to adapt to changed Lucene APIs or to sort out 
performance issues.

Question: When Lucene no longer has the Solr test suite to help catch bugs, how 
long time would it take from a Lucene commit, before Solr/ES Jenkins instances 
would have had time to produce a build and run tests? Would it be possible to 
setup a trigger in Solr Jenkins?

Jan

> 4. mai 2020 kl. 11:10 skrev Dawid Weiss :
> 
> Dear Lucene and Solr developers!


-
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)

[Doug Turnbull]

Personally I feel the burden of proof should not be why they should be
split up, but the other way - "what arguments can be made for keeping them
together?"

I would be curious if people can make the argument for keeping them
together...

-Doug

On Tue, May 5, 2020 at 10:29 AM Michael McCandless <
luc...@mikemccandless.com> wrote:

> On Mon, May 4, 2020 at 5:28 PM Gézapeti Cseh  wrote:
>
> I think separating the git repository and even the release schedules could
>> be done under the same TLP.
>>
> It would solve most of the technical issues reflected in the first mail
>> and there would be more time and data to
>>
>
> Hmm that is technically true, and in fact that is the way it was before 10
> years ago: Solr was a sub-project of Apache Lucene.
>
> But that is not the proposal here.
>
> Lucene and Solr have become such major efforts, in developers and users
> eyes and keyboard effort/time, that they really are very different entities
> now.  TLP makes sense to me for each project.
>
>>
>
>> see if creating Apache Solr again is something the PMC would want to do
>>
>
> Hmm, just to clarify, this is not an "again" sort of situation: Solr was
> not a top-level project before.  It was and still is a sub-project of
> Apache Lucene.
>
> And the proposal is to now split it out as its own (new) top-level
> project, Apache Solr.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>


-- 
*Doug Turnbull **| CTO* | OpenSource Connections
, LLC | 240.476.9983
Author: Relevant Search ; Contributor: *AI
Powered Search *
This e-mail and all contents, including attachments, is considered to be
Company Confidential unless explicitly stated otherwise, regardless
of whether attachments are marked as such.

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

[Michael McCandless]

On Mon, May 4, 2020 at 2:13 PM Dawid Weiss  wrote:

> This sounds like a decision has already been made.
>
> No. I plan to send a VOTE thread nonetheless. A vote thread is just
> that -- a vote. If majority decides both projects
> should stay together it's still a decision. A discussion without any
> resolution is going to dissolve over time into no resolution at all.
>

No decision has been made.

The point of a DISCUSS thread, prior to a VOTE thread, is for all
interested parties to voice their diverse reactions to this proposal, and
help the binding voters (Lucene/Solr committers) make up their minds about
how to vote on the VOTE thread.  We have a delightfully diverse community
here who will all contribute in choosing our path forward.


> Separately from that I think Solr has become older, larger and is an
> industry standard search component. It is time for it to mature and
> just be a top-level Apache project even from public-relations point of
> view.
>

+1

I feel Solr as its own Apache top-level project is actually long overdue:
Solr has clearly been a leading standard open-search distributed search
engine for quite some time already, with its own strong user and developer
identities and culture.  We long ago achieved the goals (paying down
open-source tech debt) of merging the two projects a decade ago.

Mike McCandless

http://blog.mikemccandless.com

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

[Michael McCandless]

On Mon, May 4, 2020 at 5:28 PM Gézapeti Cseh  wrote:

I think separating the git repository and even the release schedules could
> be done under the same TLP.
>
It would solve most of the technical issues reflected in the first mail and
> there would be more time and data to
>

Hmm that is technically true, and in fact that is the way it was before 10
years ago: Solr was a sub-project of Apache Lucene.

But that is not the proposal here.

Lucene and Solr have become such major efforts, in developers and users
eyes and keyboard effort/time, that they really are very different entities
now.  TLP makes sense to me for each project.

>

> see if creating Apache Solr again is something the PMC would want to do
>

Hmm, just to clarify, this is not an "again" sort of situation: Solr was
not a top-level project before.  It was and still is a sub-project of
Apache Lucene.

And the proposal is to now split it out as its own (new) top-level project,
Apache Solr.

Mike McCandless

http://blog.mikemccandless.com

Re: PLEASE READ! BadApple report. Last week was horrible!

[Erick Erickson]

Thanks Uwe and Mike. I’ll check Hoss’ rollups regularly this week, it’ll be 
tomorrow (Wednesday) before Uwe’s changes get a chance to be reflected there.

And FWIW, I beasted one of the failing suites last night _without_ Mike’s 
changes and didn’t get any failures so I can’t say anything about whether 
Mike’s changes helped or not.

Side note: I’m seeing about 40% of the tests throw an NPE in both before and 
after but the tests succeed, so I’d guess it’s totally unrelated, at  glance, 
the replica is being unloaded and the replication handler hasn’t stopped yet:

   [junit4]   2> 33676 INFO  (qtp1195412159-1051) [n:127.0.0.1:49614_solr ] 
o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/cores 
params={qt=/admin/cores=9929b23d-8505-48a5-841a-0992da1af4752119758844417043=REQUESTSTATUS=javabin=2}
 status=0 QTime=0
   [junit4]   2> 33746 INFO  
(parallelCoreAdminExecutor-541-thread-6-processing-n:127.0.0.1:49614_solr 
x:replicaTypesTestColl_shard3_replica_n12 
9929b23d-8505-48a5-841a-0992da1af4752119758845055723 UNLOAD) 
[n:127.0.0.1:49614_solrx:replicaTypesTestColl_shard3_replica_n12 ] 
o.a.s.m.SolrMetricManager Closing metric reporters for 
registry=solr.core.replicaTypesTestColl.shard3.replica_n12 tag=null
   [junit4]   2> 33746 INFO  
(parallelCoreAdminExecutor-541-thread-6-processing-n:127.0.0.1:49614_solr 
x:replicaTypesTestColl_shard3_replica_n12 
9929b23d-8505-48a5-841a-0992da1af4752119758845055723 UNLOAD) 
[n:127.0.0.1:49614_solrx:replicaTypesTestColl_shard3_replica_n12 ] 
o.a.s.m.r.SolrJmxReporter Closing reporter 
[org.apache.solr.metrics.reporters.SolrJmxReporter@57b06a4b: rootName = 
solr_49614, domain = solr.core.replicaTypesTestColl.shard3.replica_n12, service 
url = null, agent id = null] for registry 
solr.core.replicaTypesTestColl.shard3.replica_n12/com.codahale.metrics.MetricRegistry@6cceb313
   [junit4]   2> 33746 INFO  
(parallelCoreAdminExecutor-541-thread-4-processing-n:127.0.0.1:49614_solr 
x:replicaTypesTestColl_shard1_replica_n1 
9929b23d-8505-48a5-841a-0992da1af4752119758844417043 UNLOAD) 
[n:127.0.0.1:49614_solr ] o.a.s.c.SolrCore 
[replicaTypesTestColl_shard1_replica_n1]  CLOSING SolrCore 
org.apache.solr.core.SolrCore@55431ea6
   [junit4]   2> 33748 INFO  
(parallelCoreAdminExecutor-523-thread-6-processing-n:127.0.0.1:49612_solr 
x:replicaTypesTestColl_shard2_replica_t8 
9929b23d-8505-48a5-841a-0992da1af4752119758844946997 UNLOAD) 
[n:127.0.0.1:49612_solrx:replicaTypesTestColl_shard2_replica_t8 ] 
o.a.s.m.SolrMetricManager Closing metric reporters for 
registry=solr.core.replicaTypesTestColl.shard2.replica_t8 tag=null
   [junit4]   2> 33748 INFO  
(parallelCoreAdminExecutor-523-thread-4-processing-n:127.0.0.1:49612_solr 
x:replicaTypesTestColl_shard1_replica_t2 
9929b23d-8505-48a5-841a-0992da1af4752119758844761938 UNLOAD) 
[n:127.0.0.1:49612_solrx:replicaTypesTestColl_shard1_replica_t2 ] 
o.a.s.c.ZkController replicaTypesTestColl_shard1_replica_t2 stopping background 
replication from leader
   [junit4]   2> 33749 INFO  
(parallelCoreAdminExecutor-523-thread-6-processing-n:127.0.0.1:49612_solr 
x:replicaTypesTestColl_shard2_replica_t8 
9929b23d-8505-48a5-841a-0992da1af4752119758844946997 UNLOAD) 
[n:127.0.0.1:49612_solrx:replicaTypesTestColl_shard2_replica_t8 ] 
o.a.s.m.r.SolrJmxReporter Closing reporter 
[org.apache.solr.metrics.reporters.SolrJmxReporter@534a73a: rootName = 
solr_49612, domain = solr.core.replicaTypesTestColl.shard2.replica_t8, service 
url = null, agent id = null] for registry 
solr.core.replicaTypesTestColl.shard2.replica_t8/com.codahale.metrics.MetricRegistry@33c32317
   [junit4]   2> 33749 INFO  
(parallelCoreAdminExecutor-523-thread-4-processing-n:127.0.0.1:49612_solr 
x:replicaTypesTestColl_shard1_replica_t2 
9929b23d-8505-48a5-841a-0992da1af4752119758844761938 UNLOAD) 
[n:127.0.0.1:49612_solr ] o.a.s.c.SolrCore 
[replicaTypesTestColl_shard1_replica_t2]  CLOSING SolrCore 
org.apache.solr.core.SolrCore@1ce79412
   [junit4]   2> 33750 INFO  
(parallelCoreAdminExecutor-546-thread-5-processing-n:127.0.0.1:49613_solr 
x:replicaTypesTestColl_shard1_replica_p4 
9929b23d-8505-48a5-841a-0992da1af4752119758844836987 UNLOAD) 
[n:127.0.0.1:49613_solrx:replicaTypesTestColl_shard1_replica_p4 ] 
o.a.s.m.SolrMetricManager Closing metric reporters for 
registry=solr.core.replicaTypesTestColl.shard1.replica_p4 tag=null
   [junit4]   2> 33750 INFO  
(parallelCoreAdminExecutor-546-thread-4-processing-n:127.0.0.1:49613_solr 
x:replicaTypesTestColl_shard2_replica_n6 
9929b23d-8505-48a5-841a-0992da1af4752119758844903977 UNLOAD) 
[n:127.0.0.1:49613_solr ] o.a.s.c.SolrCore 
[replicaTypesTestColl_shard2_replica_n6]  CLOSING SolrCore 
org.apache.solr.core.SolrCore@36707173
   [junit4]   2> 33750 INFO  
(parallelCoreAdminExecutor-546-thread-5-processing-n:127.0.0.1:49613_solr 
x:replicaTypesTestColl_shard1_replica_p4 
9929b23d-8505-48a5-841a-0992da1af4752119758844836987 UNLOAD) 
[n:127.0.0.1:49613_solr

Re: Occasional compilation failures from gradle build

[Erick Erickson]

I was doing quite a bit of building the assemble and dev tasks and never saw 
this. Of course I was bouncing between and and gradle a lot and habitually 
executed a "git clean -d -x -f”, don’t have a clue whether that’d be relevant, 
though I rather doubt it is.

> On May 5, 2020, at 7:27 AM, Alan Woodward  wrote:
> 
> Hi all,
> 
> In about 50% of my gradle precommit runs, I get a Solr compilation error that 
> looks like this:
> 
> /Users/romseygeek/projects/lucene-solr/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsTestUtil.java:44:
>  error: BlockPoolSlice is not public in 
> org.apache.hadoop.hdfs.server.datanode.fsdataset.impl; cannot be accessed 
> from outside package
> import org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.BlockPoolSlice;
> 
> From what I can tell, this class is designed to override classes from Hadoop 
> to fix certain bugs, but it seems that gradle is sometimes putting the 
> original Hadoop class files first in the class path, so the overridden class 
> is not picked up.  
> 
> Is anyone else seeing this?
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Occasional compilation failures from gradle build

[Alan Woodward]

Hi all,

In about 50% of my gradle precommit runs, I get a Solr compilation error that 
looks like this:

/Users/romseygeek/projects/lucene-solr/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsTestUtil.java:44:
 error: BlockPoolSlice is not public in 
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl; cannot be accessed from 
outside package
import org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.BlockPoolSlice;

From what I can tell, this class is designed to override classes from Hadoop to 
fix certain bugs, but it seems that gradle is sometimes putting the original 
Hadoop class files first in the class path, so the overridden class is not 
picked up.  

Is anyone else seeing this?
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: PLEASE READ! BadApple report. Last week was horrible!

[Uwe Schindler]

Hi,

there was also a problem with the Windows Node. It ran out of disk space, 
because some test seem to have filled up all of the disk. All followup builds 
failed. I cleaned all Workspaces (8.x, master) and it freed 20 Gigabytes!

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Erick Erickson 
> Sent: Monday, May 4, 2020 1:54 PM
> To: dev@lucene.apache.org
> Subject: PLEASE READ! BadApple report. Last week was horrible!
> 
> I don’t know whether we had some temporary glitch that broke lots of tests
> and they’ve been fixed or we had a major regression, but this needs to be
> addressed ASAP if they’re still failing. See everything below the line "ALL OF
> THE TESTS BELOW HERE HAVE ONLY FAILED IN THE LAST WEEK!” in this e-mail.
> I’ll raise a JIRA if we can’t get some traction quickly here.
> 
> Hey, stuff happens. there’s no problem with tests going totally weird for a
> while. If you can say “Oh, yeah, all those failures for class XYZ are probably
> fixed” that’s fine.
> 
> Gosh-a-rooni, I hope my logging changes aren’t the culprit (gulp)….
> 
> Hoss’ rolllup for the last 24 hours is not encouraging in terms of the
> problem already being fixed. There are lots of failures in some
> classes, notably:
> 
> CloudHttp2SolrClientTest
> CollectionsAPIDistributedZkTest
> DeleteReplicaTest
> TestDocCollectionWatcher
> 
> Unfortunately, the failure rate is not very high so reliably
> reproducing is hard.
> 
> I’ve reproduced the last week’s failure in this e-mail, full
> report attached.
> 
> Here’s Hoss’ rollup:
> http://fucit.org/solr-jenkins-reports/failure-report.html
> 
> Usual synopsis:
> 
> Raw fail count by week totals, most recent week first (corresponds to bits):
> Week: 0  had  343 failures
> Week: 1  had  86 failures
> Week: 2  had  78 failures
> Week: 3  had  117 failures
> 
> 
> Failures in Hoss' reports for the last 4 rollups.
> 
> There were 497 unannotated tests that failed in Hoss' rollups. Ordered by the
> date I downloaded the rollup file, newest->oldest. See above for the dates the
> files were collected
> These tests were NOT BadApple'd or AwaitsFix’d
> 
> Failures in the last 4 reports..
>Report   Pct runsfails   test
>  0123   0.7 1617 11
> ConnectionManagerTest.testReconnectWhenZkDisappeared
>  0123   1.5 1606 12  ExecutePlanActionTest.testTaskTimeout
>  0123   1.6 1320 19  MultiThreadedOCPTest.test
>  0123   1.0 1620 13  RollingRestartTest.test
>  0123   1.2 1617 12  SearchRateTriggerTest.testWaitForElapsed
>  0123   3.8  119  7  ShardSplitTest.testSplitWithChaosMonkey
>  0123   0.3 1519  7  TestInPlaceUpdatesDistrib.test
>  0123   0.7 1629 14  
> TestIndexWriterDelete.testDeleteAllNoDeadLock
>  0123   2.4 1548 18  TestPackages.testPluginLoading
>  0123   0.3 1587  4  UnloadDistributedZkTest.test
> 
> 
> FAILURES IN THE LAST WEEK (343!)
> Look particularly at the ones with only a zero in the “Report” column, those 
> are
> failures that were _not_ in the previous 3 week’s rollups.
> 
>Report   Pct runsfails   test
>  0120.5 1165  4  CustomHighlightComponentTest.test
>  0121.0 1168  6
> NodeMarkersRegistrationTest.testNodeMarkersRegistration
>  0121.0 1170  8  TestCryptoKeys.test
>  01 3   0.7 1233 11  LeaderFailoverAfterPartitionTest.test
>  01 3  63.2  102 39  StressHdfsTest.test
>  01 0.3  709  2
> ScheduledTriggerIntegrationTest.testScheduledTrigger
>  01 0.2  768  2  ShardRoutingTest.test
>  01 2.6  807 22  TestAllFilesHaveChecksumFooter.test
>  01 2.6  808 22  TestAllFilesHaveCodecHeader.test
>  01 0.2  769  2  TestCloudSchemaless.test
>  01 0.2  769  2  TestDynamicLoading.testDynamicLoading
>  01 0.3  707  2  
> TestDynamicLoadingUrl.testDynamicLoadingUrl
>  01 0.5  767  4  TestPointFields.testFloatPointStats
>  0127.1   83 19  TestSQLHandler.doTest
>  01 0.2  794 12  TestSameScoresWithThreads.test
>  01 2.6  806 22  TestShardSearching.testSimple
>  01 0.5  726  4  TestSimScenario.testSplitShard
>  01 1.1  726  7  TestSimScenario.testSuggestions
>  01 0.3  771  2  TestWithCollection.testAddReplicaSimple
>  0 23   0.3 1223  4  
> CdcrVersionReplicationTest.testCdcrDocVersions
>  0 23   0.8 1172  6
> CloudHttp2SolrClientTest.testRetryUpdatesWhenClusterStateIsStale
>  0 23   1.4 1202  8  CollectionsAPISolrJTest.testColStatus
>  0 23   1.0