[jira] [Commented] (PYLUCENE-51) "AttributeError: __module__" when running doctest

2019-10-16 Thread Andreas Vajda (Jira) 


[ 
https://issues.apache.org/jira/browse/PYLUCENE-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953272#comment-16953272
 ] 

Andreas Vajda commented on PYLUCENE-51:
---

I added the setting of type._ _ module_ _  in installType() (python 3 only).
This should fix the bug, please verify that the issue with doctest is resolved.
In python 3:

>>> from lucene import initVM
>>> initVM()

>>> from org.apache.lucene.document import Document
>>> Document.__module__
'org.apache.lucene.document'
 >>>


> "AttributeError: __module__" when running doctest
> -
>
> Key: PYLUCENE-51
> URL: https://issues.apache.org/jira/browse/PYLUCENE-51
> Project: PyLucene
>  Issue Type: Bug
> Environment: Ubuntu 19.04, Python 3.7
>Reporter: Clément Jonglez
>Priority: Major
>
> Dear all,
> I am using the Orekit Python wrapper by [~petrush] . I am running into errors 
> & warnings when trying to run tests with doctest. When collecting tests, it 
> analyzes the classes (all the 1000+ wrapped Java classes it seems) and runs 
> into the following error:
> {noformat}
> [...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:137: in collect
>  for test in finder.find(module):
>  [...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:425: in find
>  extraglobs)
>  [...]/lib/python3.7/doctest.py:932: in find
>  self._find(tests, obj, name, module, source_lines, globs, {})
>  [...]/lib/python3.7/doctest.py:993: in _find
>  self._from_module(module, val)):
>  [...]/lib/python3.7/doctest.py:960: in _from_module
>  return module._name_ == object._module_
>  E AttributeError: _module_{noformat}
>  
> In doctest 
> ([https://github.com/python/cpython/blob/master/Lib/doctest.py#L959]), the
> {code:java}
> inspect.isclass(object) {code}
> condition at line 959 returns `True`, and therefore doctest tries to access 
> the object's __module__ attribute, which does not seem to exist.
> Besides, pytest prints a warning for each Java class being wrapped, also 
> because they have no __module__ attribute (this is one example of 1000+ 
> warnings):
> {noformat}
> [...]/lib/python3.7/importlib/bootstrap.py:219: DeprecationWarning: builtin 
> type ExtendedKalmanFilter has no __module_ attribute
>  return f(*args, **kwds){noformat}
> This phenomenon is new because 6 months ago I could run pytest & doctest 
> successfully with Orekit. I could not find which module contains the change 
> that broke stuff since then though.
> To reproduce the phenomenon, you can check out 
> [https://github.com/GorgiAstro/poliastro/blob/orekit-validation/src/poliastro/tests/tests_twobody/test_propagation.py#L164]
>  I was trying to validate some poliastro features using the Orekit python 
> wrapper. So this code requires poliastro, it is available on conda-forge.
> Cheers
> Clément



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: 8.3 release

2019-10-16 Thread Jan Høydahl 
https://issues.apache.org/jira/browse/SOLR-13835 is merged.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 16. okt. 2019 kl. 22:15 skrev Cassandra Targett :
> 
> Done, Ishan, thanks!
> 
> Cassandra
> On Oct 16, 2019, 2:37 PM -0500, Ishan Chattopadhyaya 
> , wrote:
>> +1, Cassandra! Thanks.
>> 
>> On Wed, 16 Oct, 2019, 11:41 PM Cassandra Targett, > > wrote:
>> Sorry, I meant branch_8_3.
>> 
>> Cassandra
>> On Oct 16, 2019, 12:59 PM -0500, Cassandra Targett > >, wrote:
>>> I just committed to master and branch_8x 
>>> https://issues.apache.org/jira/browse/SOLR-12786 
>>>  to update the versions 
>>> of tools we use for building the Ref Guide. I’d like to commit that into 
>>> branch_8_x if you don’t mind, Ishan? It’s not urgent, though.
>>> 
>>> Cassandra
>>> On Oct 16, 2019, 11:36 AM -0500, Alan Woodward >> >, wrote:
 LUCENE-9005 is committed.
 
> On 16 Oct 2019, at 17:12, Jan Høydahl  > wrote:
> 
> SOLR-13835  is also 
> almost there.
> 
> Jan Høydahl
> 
>> 16. okt. 2019 kl. 16:53 skrev Adrien Grand > >:
>> 
>> Hi Ishan,
>> 
>> LUCENE-8920 needs more work indeed, but it is not blocking this release.
>> 
>> On Wed, Oct 16, 2019 at 3:54 PM Ishan Chattopadhyaya
>> mailto:ichattopadhy...@gmail.com>> wrote:
>>> 
>>> Hi,
>>> Here are the issues that remain to be resolved for 8.3.
>>> 
>>> LUCENE-8920: Committed, but not resolved. More work remains?
>>> LUCENE-9005: Patch available, not committed.
>>> SOLR-13677: Patch available, not committed. Need another day to
>>> complete cleanup and tests.
>>> 
>>> I'll wait until all of them are finished and then proceed to build the 
>>> RC1.
>>> Thanks and regards,
>>> Ishan
>>> 
>>> On Tue, Oct 15, 2019 at 2:58 PM Ishan Chattopadhyaya
>>> mailto:ichattopadhy...@gmail.com>> wrote:
 
 Sure, Noble, thanks! Next time, please use a single commit to revert
 such features (you just used up 3 commits). branch_8_3's history is
 now littered with SOLR-13821 commits and reverts that shouldn't have
 been there :-)
 
 Thanks, Jan!
 
 On Tue, Oct 15, 2019 at 12:17 AM Noble Paul >>> > wrote:
> 
> Hi,
> I'll revert the package store commits related to SOLR-13821 in the 8.3
> branch. It is supposed to be used by the (SOLR-13822) and it is not a
> part of the 8.3 release.
> --Noble
> 
> On Tue, Oct 15, 2019 at 5:22 AM Adrien Grand  > wrote:
>> 
>> Hi Ishan,
>> 
>> The release is no longer blocked on LUCENE-8920.
>> 
>> On Thu, Oct 10, 2019 at 6:18 PM Ishan Chattopadhyaya
>> mailto:ichattopadhy...@gmail.com>> wrote:
>>> 
>>> +1, Ignacio. Please feel free to do the needful, I'll wait until 
>>> this is resolved.
>>> 
>>> +1, Jan. Sure, I think we should get it in!
>>> 
>>> 
>>> On Thu, 10 Oct, 2019, 5:45 PM Đạt Cao Mạnh, 
>>> mailto:caomanhdat...@gmail.com>> wrote:
 
 Hi Ishan,
 
 I pushed the fix to branch_8_3.
 
 On Thu, Oct 10, 2019 at 11:27 AM Jan Høydahl 
 mailto:jan@cominvent.com>> wrote:
> 
> Ishan, I'd like to get 
> https://issues.apache.org/jira/browse/SOLR-13665 
>  included, 
> since without it Solr won't work with SSL against Zookeeper.
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
> 10. okt. 2019 kl. 11:45 skrev Ignacio Vera  >:
> 
> Hi Ishan,
> 
> Thanks for taking care of the release. We have a blocker in 
> Lucene (see https://issues.apache.org/jira/browse/LUCENE-8920 
> ). I remember 
> that was an issue for the 8.2.0 release and it was reverted and 
> naked as a blocker for this release. Maybe we should completely 
> reverted until we have a better solution? let see what Mike 
> thinks about it.
> 
> Thanks,
> 
> Ignacio
> 
> On Wed, Oct 9, 2019 at 4:51 PM Uwe Schindler  > wrote:

Re: [jira] [Commented] (PYLUCENE-51) "AttributeError: __module__" when running doctest

2019-10-16 Thread Andi Vajda 


On Wed, 16 Oct 2019, Andi Vajda wrote:


On Wed, 16 Oct 2019, Petrus Hyvönen (Jira) wrote:

Looks like the name in a PyTypeObject tp_name should be of form 
"module.name", and module is automagically assigned to __module__. I think 
this is done for some of the special classes but not for the wrapped 
classes if I understand correctly. I tried to add a "jcc." in front of the 
name and it seems to propagate to the __module__ parameter. However this 
should preferably be the wrapped module path instead of just "jcc", is 
there a good way to extract this path? One way could be to have a new 
parameter, module to the DEFINE_TYPE but that would require a bit of 
changes all around.


In other words, instead of generating
DEFINE_TYPE(SpanFirstBuilder, t_SpanFirstBuilder, SpanFirstBuilder);
JCC should generate something like
DEFINE_TYPE(org.apache.lucene.queryparser.xml.SpanFirstBuilder,
t_SpanFirstBuilder, SpanFirstBuilder);

That should simple enough to fix...
Let me give it a quick try.


Or, even simpler, just set in inside installType().

Andi..

Re: [jira] [Commented] (PYLUCENE-51) "AttributeError: __module__" when running doctest

2019-10-16 Thread Andi Vajda 


On Wed, 16 Oct 2019, Petrus Hyvönen (Jira) wrote:

Looks like the name in a PyTypeObject tp_name should be of form 
"module.name", and module is automagically assigned to __module__. I think 
this is done for some of the special classes but not for the wrapped 
classes if I understand correctly. I tried to add a "jcc." in front of the 
name and it seems to propagate to the __module__ parameter. However this 
should preferably be the wrapped module path instead of just "jcc", is 
there a good way to extract this path? One way could be to have a new 
parameter, module to the DEFINE_TYPE but that would require a bit of 
changes all around.


In other words, instead of generating
 DEFINE_TYPE(SpanFirstBuilder, t_SpanFirstBuilder, SpanFirstBuilder);
JCC should generate something like
 DEFINE_TYPE(org.apache.lucene.queryparser.xml.SpanFirstBuilder,
 t_SpanFirstBuilder, SpanFirstBuilder);

That should simple enough to fix...
Let me give it a quick try.

Andi..

[jira] [Commented] (PYLUCENE-51) "AttributeError: __module__" when running doctest

2019-10-16 Thread Jira 


[ 
https://issues.apache.org/jira/browse/PYLUCENE-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953191#comment-16953191
 ] 

Petrus Hyvönen commented on PYLUCENE-51:


Hi,

 

Looks like the name in a PyTypeObject tp_name should be of form "module.name", 
and module is automagically assigned to __module__. I think this is done for 
some of the special classes but not for the wrapped classes if I understand 
correctly. I tried to add a "jcc." in front of the name and it seems to 
propagate to the __module__ parameter. However this should preferably be the 
wrapped module path instead of just "jcc", is there a good way to extract this 
path? One way could be to have a new parameter, module to the DEFINE_TYPE but 
that would require a bit of changes all around.

from the macros.h file:

#define DEFINE_TYPE(name, t_name, javaClass) \
PyType_Def PY_TYPE_DEF(name) = { \
 { \
 "jcc." #name, \                                                                
                   /* default is #name added the "jcc." part
 sizeof(t_name), \
 0, \
 Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE, \
 PY_TYPE_SLOTS(name) \
 }, \
 NULL, \
 PY_TYPE_BASES(name), \
};

> "AttributeError: __module__" when running doctest
> -
>
> Key: PYLUCENE-51
> URL: https://issues.apache.org/jira/browse/PYLUCENE-51
> Project: PyLucene
>  Issue Type: Bug
> Environment: Ubuntu 19.04, Python 3.7
>Reporter: Clément Jonglez
>Priority: Major
>
> Dear all,
> I am using the Orekit Python wrapper by [~petrush] . I am running into errors 
> & warnings when trying to run tests with doctest. When collecting tests, it 
> analyzes the classes (all the 1000+ wrapped Java classes it seems) and runs 
> into the following error:
> {noformat}
> [...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:137: in collect
>  for test in finder.find(module):
>  [...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:425: in find
>  extraglobs)
>  [...]/lib/python3.7/doctest.py:932: in find
>  self._find(tests, obj, name, module, source_lines, globs, {})
>  [...]/lib/python3.7/doctest.py:993: in _find
>  self._from_module(module, val)):
>  [...]/lib/python3.7/doctest.py:960: in _from_module
>  return module._name_ == object._module_
>  E AttributeError: _module_{noformat}
>  
> In doctest 
> ([https://github.com/python/cpython/blob/master/Lib/doctest.py#L959]), the
> {code:java}
> inspect.isclass(object) {code}
> condition at line 959 returns `True`, and therefore doctest tries to access 
> the object's __module__ attribute, which does not seem to exist.
> Besides, pytest prints a warning for each Java class being wrapped, also 
> because they have no __module__ attribute (this is one example of 1000+ 
> warnings):
> {noformat}
> [...]/lib/python3.7/importlib/bootstrap.py:219: DeprecationWarning: builtin 
> type ExtendedKalmanFilter has no __module_ attribute
>  return f(*args, **kwds){noformat}
> This phenomenon is new because 6 months ago I could run pytest & doctest 
> successfully with Orekit. I could not find which module contains the change 
> that broke stuff since then though.
> To reproduce the phenomenon, you can check out 
> [https://github.com/GorgiAstro/poliastro/blob/orekit-validation/src/poliastro/tests/tests_twobody/test_propagation.py#L164]
>  I was trying to validate some poliastro features using the Orekit python 
> wrapper. So this code requires poliastro, it is available on conda-forge.
> Cheers
> Clément



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Capturing URL params for use within Streaming Expressions

2019-10-16 Thread Houston Putman 
Streaming expressions allow for users to pass in any arbitrary URL params
in the search streaming source. I'm looking to add the ability for certain
streaming functions, maybe just "search()" but possibly more, to extract
the extra URL params passed along in the streaming request.

For example sending a request:
http://localhost:8983/solr/example/stream?expr=search(collection1, q="*:*",
fl="id", sort="id")&
*shards.preference=shards.preference=replica.location:local*

would be equivalent to:
http://localhost:8983/solr/example/stream?expr=search(collection1, q="*:*",
fl="id", sort="id",
*shards.preference="shards.preference=replica.location:local"*)

The beauty of URL params is that they can easily be overridden and checked,
for example in a proxy between the user and solr. It is harder to do this
with streaming expressions as the proxy would need to parse the expression
and know the logic of the functions and sources.

I'm open to discussion on whether the params able to be captured by the
streaming function would need to be white-listed or black-listed. My idea
is that this would be generically implemented through something like the
StreamContext, so that any streaming function that wants to add this
functionality is able to do so.

Another option is to add a URL parameter such as
*=replica.location:local* (
*expr.override..=*). That way it's explicit
that the user is trying to send options to the streaming expression, and
extraneous URL params aren't accidentally captured when they were included
for a different purpose.

Anyways this would really help us for some uses cases, especially the
replica routing options used in the example above. Really interested to see
opinions on either of these options.

- Houston Putman

Re: 8.3 release

2019-10-16 Thread Cassandra Targett 
Done, Ishan, thanks!

Cassandra
On Oct 16, 2019, 2:37 PM -0500, Ishan Chattopadhyaya 
, wrote:
> +1, Cassandra! Thanks.
>
> > On Wed, 16 Oct, 2019, 11:41 PM Cassandra Targett,  
> > wrote:
> > > Sorry, I meant branch_8_3.
> > >
> > > Cassandra
> > > On Oct 16, 2019, 12:59 PM -0500, Cassandra Targett 
> > > , wrote:
> > > > I just committed to master and branch_8x 
> > > > https://issues.apache.org/jira/browse/SOLR-12786 to update the versions 
> > > > of tools we use for building the Ref Guide. I’d like to commit that 
> > > > into branch_8_x if you don’t mind, Ishan? It’s not urgent, though.
> > > >
> > > > Cassandra
> > > > On Oct 16, 2019, 11:36 AM -0500, Alan Woodward , 
> > > > wrote:
> > > > > LUCENE-9005 is committed.
> > > > >
> > > > > > On 16 Oct 2019, at 17:12, Jan Høydahl  wrote:
> > > > > >
> > > > > > SOLR-13835 is also almost there.
> > > > > >
> > > > > > Jan Høydahl
> > > > > >
> > > > > > > 16. okt. 2019 kl. 16:53 skrev Adrien Grand :
> > > > > > >
> > > > > > > Hi Ishan,
> > > > > > >
> > > > > > > LUCENE-8920 needs more work indeed, but it is not blocking this 
> > > > > > > release.
> > > > > > >
> > > > > > > On Wed, Oct 16, 2019 at 3:54 PM Ishan Chattopadhyaya
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > > Here are the issues that remain to be resolved for 8.3.
> > > > > > > >
> > > > > > > > LUCENE-8920: Committed, but not resolved. More work remains?
> > > > > > > > LUCENE-9005: Patch available, not committed.
> > > > > > > > SOLR-13677: Patch available, not committed. Need another day to
> > > > > > > > complete cleanup and tests.
> > > > > > > >
> > > > > > > > I'll wait until all of them are finished and then proceed to 
> > > > > > > > build the RC1.
> > > > > > > > Thanks and regards,
> > > > > > > > Ishan
> > > > > > > >
> > > > > > > > On Tue, Oct 15, 2019 at 2:58 PM Ishan Chattopadhyaya
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Sure, Noble, thanks! Next time, please use a single commit to 
> > > > > > > > > revert
> > > > > > > > > such features (you just used up 3 commits). branch_8_3's 
> > > > > > > > > history is
> > > > > > > > > now littered with SOLR-13821 commits and reverts that 
> > > > > > > > > shouldn't have
> > > > > > > > > been there :-)
> > > > > > > > >
> > > > > > > > > Thanks, Jan!
> > > > > > > > >
> > > > > > > > > On Tue, Oct 15, 2019 at 12:17 AM Noble Paul 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > > I'll revert the package store commits related to SOLR-13821 
> > > > > > > > > > in the 8.3
> > > > > > > > > > branch. It is supposed to be used by the (SOLR-13822) and 
> > > > > > > > > > it is not a
> > > > > > > > > > part of the 8.3 release.
> > > > > > > > > > --Noble
> > > > > > > > > >
> > > > > > > > > > On Tue, Oct 15, 2019 at 5:22 AM Adrien Grand 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Ishan,
> > > > > > > > > > >
> > > > > > > > > > > The release is no longer blocked on LUCENE-8920.
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Oct 10, 2019 at 6:18 PM Ishan Chattopadhyaya
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > +1, Ignacio. Please feel free to do the needful, I'll 
> > > > > > > > > > > > wait until this is resolved.
> > > > > > > > > > > >
> > > > > > > > > > > > +1, Jan. Sure, I think we should get it in!
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, 10 Oct, 2019, 5:45 PM Đạt Cao Mạnh, 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Ishan,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I pushed the fix to branch_8_3.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Oct 10, 2019 at 11:27 AM Jan Høydahl 
> > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Ishan, I'd like to get 
> > > > > > > > > > > > > > https://issues.apache.org/jira/browse/SOLR-13665 
> > > > > > > > > > > > > > included, since without it Solr won't work with SSL 
> > > > > > > > > > > > > > against Zookeeper.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Jan Høydahl, search solution architect
> > > > > > > > > > > > > > Cominvent AS - www.cominvent.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 10. okt. 2019 kl. 11:45 skrev Ignacio Vera 
> > > > > > > > > > > > > > :
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Ishan,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks for taking care of the release. We have a 
> > > > > > > > > > > > > > blocker in Lucene (see 
> > > > > > > > > > > > > > https://issues.apache.org/jira/browse/LUCENE-8920). 
> > > > > > > > > > > > > > I remember that was an issue for the 8.2.0 release 
> > > > > > > > > > > > > > and it was reverted and naked as a blocker for this 
> > > > > > > > > > > > > > release. Maybe we should completely reverted until 
> > > > > > > > > >

Re: 8.3 release

2019-10-16 Thread Ishan Chattopadhyaya 
+1, Cassandra! Thanks.

On Wed, 16 Oct, 2019, 11:41 PM Cassandra Targett, 
wrote:

> Sorry, I meant branch_8_3.
>
> Cassandra
> On Oct 16, 2019, 12:59 PM -0500, Cassandra Targett ,
> wrote:
>
> I just committed to master and branch_8x
> https://issues.apache.org/jira/browse/SOLR-12786 to update the versions
> of tools we use for building the Ref Guide. I’d like to commit that into
> branch_8_x if you don’t mind, Ishan? It’s not urgent, though.
>
> Cassandra
> On Oct 16, 2019, 11:36 AM -0500, Alan Woodward ,
> wrote:
>
> LUCENE-9005 is committed.
>
> On 16 Oct 2019, at 17:12, Jan Høydahl  wrote:
>
> SOLR-13835  is also
> almost there.
>
> Jan Høydahl
>
> 16. okt. 2019 kl. 16:53 skrev Adrien Grand :
>
> Hi Ishan,
>
> LUCENE-8920 needs more work indeed, but it is not blocking this release.
>
> On Wed, Oct 16, 2019 at 3:54 PM Ishan Chattopadhyaya
>  wrote:
>
>
> Hi,
>
> Here are the issues that remain to be resolved for 8.3.
>
>
> LUCENE-8920: Committed, but not resolved. More work remains?
>
> LUCENE-9005: Patch available, not committed.
>
> SOLR-13677: Patch available, not committed. Need another day to
>
> complete cleanup and tests.
>
>
> I'll wait until all of them are finished and then proceed to build the RC1.
>
> Thanks and regards,
>
> Ishan
>
>
> On Tue, Oct 15, 2019 at 2:58 PM Ishan Chattopadhyaya
>
>  wrote:
>
>
> Sure, Noble, thanks! Next time, please use a single commit to revert
>
> such features (you just used up 3 commits). branch_8_3's history is
>
> now littered with SOLR-13821 commits and reverts that shouldn't have
>
> been there :-)
>
>
> Thanks, Jan!
>
>
> On Tue, Oct 15, 2019 at 12:17 AM Noble Paul  wrote:
>
>
> Hi,
>
> I'll revert the package store commits related to SOLR-13821 in the 8.3
>
> branch. It is supposed to be used by the (SOLR-13822) and it is not a
>
> part of the 8.3 release.
>
> --Noble
>
>
> On Tue, Oct 15, 2019 at 5:22 AM Adrien Grand  wrote:
>
>
> Hi Ishan,
>
>
> The release is no longer blocked on LUCENE-8920.
>
>
> On Thu, Oct 10, 2019 at 6:18 PM Ishan Chattopadhyaya
>
>  wrote:
>
>
> +1, Ignacio. Please feel free to do the needful, I'll wait until this is
> resolved.
>
>
> +1, Jan. Sure, I think we should get it in!
>
>
>
> On Thu, 10 Oct, 2019, 5:45 PM Đạt Cao Mạnh, 
> wrote:
>
>
> Hi Ishan,
>
>
> I pushed the fix to branch_8_3.
>
>
> On Thu, Oct 10, 2019 at 11:27 AM Jan Høydahl 
> wrote:
>
>
> Ishan, I'd like to get https://issues.apache.org/jira/browse/SOLR-13665
> included, since without it Solr won't work with SSL against Zookeeper.
>
>
> --
>
> Jan Høydahl, search solution architect
>
> Cominvent AS - www.cominvent.com
>
>
> 10. okt. 2019 kl. 11:45 skrev Ignacio Vera :
>
>
> Hi Ishan,
>
>
> Thanks for taking care of the release. We have a blocker in Lucene (see
> https://issues.apache.org/jira/browse/LUCENE-8920). I remember that was
> an issue for the 8.2.0 release and it was reverted and naked as a blocker
> for this release. Maybe we should completely reverted until we have a
> better solution? let see what Mike thinks about it.
>
>
> Thanks,
>
>
> Ignacio
>
>
> On Wed, Oct 9, 2019 at 4:51 PM Uwe Schindler  wrote:
>
>
> Hi,
>
>
> I also had a customer complaining about this. I have the feeling it also
> happens from time to time during inter node comm, which uses solrj, too.
>
>
> Uwe
>
>
> Am October 9, 2019 1:38:00 PM UTC schrieb Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com>:
>
>
> +1, Dat! Please go ahead.
>
>
> On Wed, 9 Oct, 2019, 2:33 PM Andrzej Białecki,  wrote:
>
>
> It’s marked as Minor in Jira, but after reading the description it sounds
> scary - IMHO it should be at least well investigated before 8.3 in order to
> determine whether it causes real damage (apart from looking scary and
> filling the logs).
>
>
> +1 from me.
>
>
> On 9 Oct 2019, at 10:48, Đạt Cao Mạnh  wrote:
>
>
> Hi Ishan, guys
>
>
> I want to include the fix for
> https://issues.apache.org/jira/browse/SOLR-13293 in this release. Hoping
> that is ok!
>
>
> Thanks!
>
>
> On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler  wrote:
>
>
> ASF Jenkins Jobs also reconfigured.
>
>
> I left the 8.2 Refguide job in the queue (I cloned it), not sure if that
> one is still needed. All other jobs are 8.3 now.
>
>
> Uwe
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@thetaphi.de 
>
>
> 
>

PLEASE READ if you build the Ref Guide HTML locally

2019-10-16 Thread Cassandra Targett 
If you build the Ref Guide HTML files on your local machine, please note
the following changes to the build.

To build the Ref Guide HTML version locally, you must have several Ruby
gems installed as pre-requisites. I've just committed changes that require
newer versions of these gems.

You can update your existing gems with the "gem update" command:

gem update asciidoctor
gem update jekyll-asciidoc
gem update slim
gem update tilt

And a new dependency needs to be added:

gem install concurrent-ruby

* The version of Jekyll has not changed so that gem does not need to be
updated.

The versions we're now using are documented in the Ref Guide README:
https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/README.adoc

See also https://issues.apache.org/jira/browse/SOLR-12786 for details of
these changes.

As soon as we move to Gradle, you won't need any gems locally. The PDF
build downloads a .jar, so while it is also updated no local changes are
needed (and it's going away soon anyway).

Let me know if you have trouble with the new versions -
Cassandra

Re: [JENKINS] Solr-reference-guide-master - Build # 19516 - Failure

2019-10-16 Thread Cassandra Targett 
I pushed a fix for this and it’s fine now.

Cassandra
On Oct 16, 2019, 12:05 PM -0500, Apache Jenkins Server 
, wrote:
> Build: https://builds.apache.org/job/Solr-reference-guide-master/19516/
>
> Log:
> Started by timer
> Running as SYSTEM
> [EnvInject] - Loading node environment variables.
> Building remotely on websites (git-websites svn-websites) in workspace 
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
> No credentials specified
> > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
> > git config remote.origin.url 
> > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
> Cleaning workspace
> > git rev-parse --verify HEAD # timeout=10
> Resetting working tree
> > git reset --hard # timeout=10
> > git clean -fdx # timeout=10
> Fetching upstream changes from 
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> > git --version # timeout=10
> > git fetch --tags --progress -- 
> > https://gitbox.apache.org/repos/asf/lucene-solr.git 
> > +refs/heads/*:refs/remotes/origin/*
> > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
> Checking out Revision f7711d712472528b567ab975d0ed677bbd30ac12 
> (refs/remotes/origin/master)
> > git config core.sparsecheckout # timeout=10
> > git checkout -f f7711d712472528b567ab975d0ed677bbd30ac12
> Commit message: "LUCENE-9005: BooleanQuery.visit() pulls subvisitors from a 
> top-level MUST visitor"
> > git rev-list --no-walk b881a09592d44aa114794c07d9f9cca41b2fcb1c # timeout=10
> No emails were triggered.
> [Solr-reference-guide-master] $ /bin/bash -xe 
> /tmp/jenkins15449213170578971340.sh
> + bash dev-tools/scripts/jenkins.build.ref.guide.sh
> + set -e
> + RVM_PATH=/home/jenkins/.rvm
> + RUBY_VERSION=ruby-2.5.1
> + GEMSET=solr-refguide-gemset
> + curl -sSL https://get.rvm.io
> + bash -s -- --ignore-dotfiles stable
> Turning on ignore dotfiles mode.
> Downloading https://github.com/rvm/rvm/archive/1.29.9.tar.gz
> Downloading 
> https://github.com/rvm/rvm/releases/download/1.29.9/1.29.9.tar.gz.asc
> gpg: Signature made Wed 10 Jul 2019 08:31:02 AM UTC
> gpg: using RSA key 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
> gpg: Good signature from "Piotr Kuczynski " 
> [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg: There is no indication that the signature belongs to the owner.
> Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
> GPG verified '/home/jenkins/.rvm/archives/rvm-1.29.9.tgz'
> Upgrading the RVM installation in /home/jenkins/.rvm/
> Upgrade of RVM in /home/jenkins/.rvm/ is complete.
>
> Thanks for installing RVM 
> Please consider donating to our open collective to help us maintain RVM.
>
>  Donate: https://opencollective.com/rvm/donate
>
>
> + set +x
> Running 'source /home/jenkins/.rvm/scripts/rvm'
> Running 'rvm cleanup all'
> Cleaning up rvm archives
> Cleaning up rvm repos
> Cleaning up rvm src
> Cleaning up rvm log
> Cleaning up rvm tmp
> Cleaning up rvm gemsets
> Cleaning up rvm links
> Cleanup done.
> Running 'rvm autolibs disable'
> Running 'rvm install ruby-2.5.1'
> Already installed ruby-2.5.1.
> To reinstall use:
>
> rvm reinstall ruby-2.5.1
>
> Running 'rvm gemset create solr-refguide-gemset'
> ruby-2.5.1 - #gemset created 
> /home/jenkins/.rvm/gems/ruby-2.5.1@solr-refguide-gemset
> ruby-2.5.1 - #generating solr-refguide-gemset wrappers...
> Running 'rvm ruby-2.5.1@solr-refguide-gemset'
> Using /home/jenkins/.rvm/gems/ruby-2.5.1 with gemset solr-refguide-gemset
> Running 'gem install --force --version 3.5.0 jekyll'
> Successfully installed jekyll-3.5.0
> Parsing documentation for jekyll-3.5.0
> Done installing documentation for jekyll after 0 seconds
> 1 gem installed
> Running 'gem install --force --version 3.0.0 jekyll-asciidoc'
> Successfully installed jekyll-asciidoc-3.0.0
> Parsing documentation for jekyll-asciidoc-3.0.0
> Installing ri documentation for jekyll-asciidoc-3.0.0
> Done installing documentation for jekyll-asciidoc after 0 seconds
> 1 gem installed
> Running 'gem install --force --version 4.0.1 slim'
> Successfully installed slim-4.0.1
> Parsing documentation for slim-4.0.1
> Installing ri documentation for slim-4.0.1
> Done installing documentation for slim after 0 seconds
> 1 gem installed
> Running 'gem install --force --version 2.0.10 tilt'
> Successfully installed tilt-2.0.10
> Parsing documentation for tilt-2.0.10
> Installing ri documentation for tilt-2.0.10
> Done installing documentation for tilt after 0 seconds
> 1 gem installed
> Running 'gem install --force --version 1.1.5 concurrent-ruby'
> Successfully installed concurrent-ruby-1.1.5
> Parsing documentation for concurrent-ruby-1.1.5
> Installing ri documentation for concurrent-ruby-1.1.5
> Done installing documentation for concurrent-ruby after 4 seconds
> 1 gem installed
> + ant clean build-site build-pdf
> Buildfile: 
>

Re: The Visual Guide to Streaming Expressions and Math Expressions

2019-10-16 Thread Joel Bernstein 
Hi Pratik,

The visualizations are all done using Apache Zeppelin and the Zeppelin-Solr
interpreter. The getting started part of the user guide provides links for
Zeppelin-Solr. The install process in pretty quick. This is all open
source, freely available software. It's possible that Zepplin-Solr can be
incorporated into the Solr code eventually but the test frameworks are
quite different. I think some simple scripts can be included with the Solr
to automated the downloads for Zeppelin and Zeppelin-Solr.

Joel Bernstein
http://joelsolr.blogspot.com/


On Wed, Oct 16, 2019 at 11:27 AM Pratik Patel  wrote:

> Hi Joel,
>
> Looks like this is going to be very helpful, thank you! I am wondering
> whether the visualizations are generated through third party library or is
> it something which would be part of solr distribution?
>
> https://github.com/apache/lucene-solr/blob/visual-guide/solr/solr-ref-guide/src/visualization.adoc#visualization
>
>
> Thanks,
> Pratik
>
>
> On Wed, Oct 16, 2019 at 10:54 AM Joel Bernstein 
> wrote:
>
> > Hi,
> >
> > The Visual Guide to Streaming Expressions and Math Expressions is now
> > complete. It's been published to Github at the following location:
> >
> >
> >
> https://github.com/apache/lucene-solr/blob/visual-guide/solr/solr-ref-guide/src/math-expressions.adoc#streaming-expressions-and-math-expressions
> >
> > The guide will eventually be part of Solr's release when the RefGuide is
> > ready to accommodate it. In the meantime its been designed to be easily
> > read directly from Github.
> >
> > The guide contains close to 200 visualizations and examples showing how
> to
> > use Streaming Expressions and Math Expressions for data analysis and
> > visualization. The visual guide is also designed to guide users that are
> > not experts in math in how to apply the functions to analysis and
> visualize
> > data.
> >
> > The new visual data loading feature in Solr 8.3 is also covered in the
> > guide. This feature should cut down on the time it takes to load CSV
> files
> > so that more time can be spent on analysis and visualization.
> >
> >
> >
> https://github.com/apache/lucene-solr/blob/visual-guide/solr/solr-ref-guide/src/loading.adoc#loading-data
> >
> > Joel Bernstein
> >
>

Re: The Visual Guide to Streaming Expressions and Math Expressions

2019-10-16 Thread Pratik Patel 
Hi Joel,

Looks like this is going to be very helpful, thank you! I am wondering
whether the visualizations are generated through third party library or is
it something which would be part of solr distribution?
https://github.com/apache/lucene-solr/blob/visual-guide/solr/solr-ref-guide/src/visualization.adoc#visualization


Thanks,
Pratik


On Wed, Oct 16, 2019 at 10:54 AM Joel Bernstein  wrote:

> Hi,
>
> The Visual Guide to Streaming Expressions and Math Expressions is now
> complete. It's been published to Github at the following location:
>
>
> https://github.com/apache/lucene-solr/blob/visual-guide/solr/solr-ref-guide/src/math-expressions.adoc#streaming-expressions-and-math-expressions
>
> The guide will eventually be part of Solr's release when the RefGuide is
> ready to accommodate it. In the meantime its been designed to be easily
> read directly from Github.
>
> The guide contains close to 200 visualizations and examples showing how to
> use Streaming Expressions and Math Expressions for data analysis and
> visualization. The visual guide is also designed to guide users that are
> not experts in math in how to apply the functions to analysis and visualize
> data.
>
> The new visual data loading feature in Solr 8.3 is also covered in the
> guide. This feature should cut down on the time it takes to load CSV files
> so that more time can be spent on analysis and visualization.
>
>
> https://github.com/apache/lucene-solr/blob/visual-guide/solr/solr-ref-guide/src/loading.adoc#loading-data
>
> Joel Bernstein
>

The Visual Guide to Streaming Expressions and Math Expressions

2019-10-16 Thread Joel Bernstein 
Hi,

The Visual Guide to Streaming Expressions and Math Expressions is now
complete. It's been published to Github at the following location:

https://github.com/apache/lucene-solr/blob/visual-guide/solr/solr-ref-guide/src/math-expressions.adoc#streaming-expressions-and-math-expressions

The guide will eventually be part of Solr's release when the RefGuide is
ready to accommodate it. In the meantime its been designed to be easily
read directly from Github.

The guide contains close to 200 visualizations and examples showing how to
use Streaming Expressions and Math Expressions for data analysis and
visualization. The visual guide is also designed to guide users that are
not experts in math in how to apply the functions to analysis and visualize
data.

The new visual data loading feature in Solr 8.3 is also covered in the
guide. This feature should cut down on the time it takes to load CSV files
so that more time can be spent on analysis and visualization.

https://github.com/apache/lucene-solr/blob/visual-guide/solr/solr-ref-guide/src/loading.adoc#loading-data

Joel Bernstein

Re: 8.3 release

2019-10-16 Thread Adrien Grand 
Hi Ishan,

LUCENE-8920 needs more work indeed, but it is not blocking this release.

On Wed, Oct 16, 2019 at 3:54 PM Ishan Chattopadhyaya
 wrote:
>
> Hi,
> Here are the issues that remain to be resolved for 8.3.
>
> LUCENE-8920: Committed, but not resolved. More work remains?
> LUCENE-9005: Patch available, not committed.
> SOLR-13677: Patch available, not committed. Need another day to
> complete cleanup and tests.
>
> I'll wait until all of them are finished and then proceed to build the RC1.
> Thanks and regards,
> Ishan
>
> On Tue, Oct 15, 2019 at 2:58 PM Ishan Chattopadhyaya
>  wrote:
> >
> > Sure, Noble, thanks! Next time, please use a single commit to revert
> > such features (you just used up 3 commits). branch_8_3's history is
> > now littered with SOLR-13821 commits and reverts that shouldn't have
> > been there :-)
> >
> > Thanks, Jan!
> >
> > On Tue, Oct 15, 2019 at 12:17 AM Noble Paul  wrote:
> > >
> > > Hi,
> > > I'll revert the package store commits related to SOLR-13821 in the 8.3
> > > branch. It is supposed to be used by the (SOLR-13822) and it is not a
> > > part of the 8.3 release.
> > > --Noble
> > >
> > > On Tue, Oct 15, 2019 at 5:22 AM Adrien Grand  wrote:
> > > >
> > > > Hi Ishan,
> > > >
> > > > The release is no longer blocked on LUCENE-8920.
> > > >
> > > > On Thu, Oct 10, 2019 at 6:18 PM Ishan Chattopadhyaya
> > > >  wrote:
> > > > >
> > > > > +1, Ignacio. Please feel free to do the needful, I'll wait until this 
> > > > > is resolved.
> > > > >
> > > > > +1, Jan. Sure, I think we should get it in!
> > > > >
> > > > >
> > > > > On Thu, 10 Oct, 2019, 5:45 PM Đạt Cao Mạnh,  
> > > > > wrote:
> > > > >>
> > > > >> Hi Ishan,
> > > > >>
> > > > >> I pushed the fix to branch_8_3.
> > > > >>
> > > > >> On Thu, Oct 10, 2019 at 11:27 AM Jan Høydahl  
> > > > >> wrote:
> > > > >>>
> > > > >>> Ishan, I'd like to get 
> > > > >>> https://issues.apache.org/jira/browse/SOLR-13665 included, since 
> > > > >>> without it Solr won't work with SSL against Zookeeper.
> > > > >>>
> > > > >>> --
> > > > >>> Jan Høydahl, search solution architect
> > > > >>> Cominvent AS - www.cominvent.com
> > > > >>>
> > > > >>> 10. okt. 2019 kl. 11:45 skrev Ignacio Vera :
> > > > >>>
> > > > >>> Hi Ishan,
> > > > >>>
> > > > >>> Thanks for taking care of the release. We have a blocker in Lucene 
> > > > >>> (see https://issues.apache.org/jira/browse/LUCENE-8920). I remember 
> > > > >>> that was an issue for the 8.2.0 release and it was reverted and 
> > > > >>> naked as a blocker for this release. Maybe we should completely 
> > > > >>> reverted until we have a better solution? let see what Mike thinks 
> > > > >>> about it.
> > > > >>>
> > > > >>> Thanks,
> > > > >>>
> > > > >>> Ignacio
> > > > >>>
> > > > >>> On Wed, Oct 9, 2019 at 4:51 PM Uwe Schindler  
> > > > >>> wrote:
> > > > 
> > > >  Hi,
> > > > 
> > > >  I also had a customer complaining about this. I have the feeling 
> > > >  it also happens from time to time during inter node comm, which 
> > > >  uses solrj, too.
> > > > 
> > > >  Uwe
> > > > 
> > > >  Am October 9, 2019 1:38:00 PM UTC schrieb Ishan Chattopadhyaya 
> > > >  :
> > > > >
> > > > > +1, Dat! Please go ahead.
> > > > >
> > > > > On Wed, 9 Oct, 2019, 2:33 PM Andrzej Białecki,  
> > > > > wrote:
> > > > >>
> > > > >> It’s marked as Minor in Jira, but after reading the description 
> > > > >> it sounds scary - IMHO it should be at least well investigated 
> > > > >> before 8.3 in order to determine whether it causes real damage 
> > > > >> (apart from looking scary and filling the logs).
> > > > >>
> > > > >> +1 from me.
> > > > >>
> > > > >> On 9 Oct 2019, at 10:48, Đạt Cao Mạnh  
> > > > >> wrote:
> > > > >>
> > > > >> Hi Ishan, guys
> > > > >>
> > > > >> I want to include the fix for 
> > > > >> https://issues.apache.org/jira/browse/SOLR-13293 in this 
> > > > >> release. Hoping that is ok!
> > > > >>
> > > > >> Thanks!
> > > > >>
> > > > >> On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler  
> > > > >> wrote:
> > > > >>>
> > > > >>> ASF Jenkins Jobs also reconfigured.
> > > > >>>
> > > > >>> I left the 8.2 Refguide job in the queue (I cloned it), not 
> > > > >>> sure if that one is still needed. All other jobs are 8.3 now.
> > > > >>>
> > > > >>> Uwe
> > > > >>>
> > > > >>> -
> > > > >>> Uwe Schindler
> > > > >>> Achterdiek 19, D-28357 Bremen
> > > > >>> https://www.thetaphi.de
> > > > >>> eMail: u...@thetaphi.de
> > > > >>>
> > > > >>> > -Original Message-
> > > > >>> > From: Uwe Schindler 
> > > > >>> > Sent: Tuesday, October 8, 2019 4:49 PM
> > > > >>> > To: dev@lucene.apache.org
> > > > >>> > Subject: RE: 8.3 release
> > > > >>> >
> > > > >>> > Policeman Jenkins builds and tests 8.3 for Windows and Linux.
> > > > >>> >
> > > > >>> > Uwe

Re: 8.3 release

2019-10-16 Thread Ishan Chattopadhyaya 
Hi,
Here are the issues that remain to be resolved for 8.3.

LUCENE-8920: Committed, but not resolved. More work remains?
LUCENE-9005: Patch available, not committed.
SOLR-13677: Patch available, not committed. Need another day to
complete cleanup and tests.

I'll wait until all of them are finished and then proceed to build the RC1.
Thanks and regards,
Ishan

On Tue, Oct 15, 2019 at 2:58 PM Ishan Chattopadhyaya
 wrote:
>
> Sure, Noble, thanks! Next time, please use a single commit to revert
> such features (you just used up 3 commits). branch_8_3's history is
> now littered with SOLR-13821 commits and reverts that shouldn't have
> been there :-)
>
> Thanks, Jan!
>
> On Tue, Oct 15, 2019 at 12:17 AM Noble Paul  wrote:
> >
> > Hi,
> > I'll revert the package store commits related to SOLR-13821 in the 8.3
> > branch. It is supposed to be used by the (SOLR-13822) and it is not a
> > part of the 8.3 release.
> > --Noble
> >
> > On Tue, Oct 15, 2019 at 5:22 AM Adrien Grand  wrote:
> > >
> > > Hi Ishan,
> > >
> > > The release is no longer blocked on LUCENE-8920.
> > >
> > > On Thu, Oct 10, 2019 at 6:18 PM Ishan Chattopadhyaya
> > >  wrote:
> > > >
> > > > +1, Ignacio. Please feel free to do the needful, I'll wait until this 
> > > > is resolved.
> > > >
> > > > +1, Jan. Sure, I think we should get it in!
> > > >
> > > >
> > > > On Thu, 10 Oct, 2019, 5:45 PM Đạt Cao Mạnh,  
> > > > wrote:
> > > >>
> > > >> Hi Ishan,
> > > >>
> > > >> I pushed the fix to branch_8_3.
> > > >>
> > > >> On Thu, Oct 10, 2019 at 11:27 AM Jan Høydahl  
> > > >> wrote:
> > > >>>
> > > >>> Ishan, I'd like to get 
> > > >>> https://issues.apache.org/jira/browse/SOLR-13665 included, since 
> > > >>> without it Solr won't work with SSL against Zookeeper.
> > > >>>
> > > >>> --
> > > >>> Jan Høydahl, search solution architect
> > > >>> Cominvent AS - www.cominvent.com
> > > >>>
> > > >>> 10. okt. 2019 kl. 11:45 skrev Ignacio Vera :
> > > >>>
> > > >>> Hi Ishan,
> > > >>>
> > > >>> Thanks for taking care of the release. We have a blocker in Lucene 
> > > >>> (see https://issues.apache.org/jira/browse/LUCENE-8920). I remember 
> > > >>> that was an issue for the 8.2.0 release and it was reverted and naked 
> > > >>> as a blocker for this release. Maybe we should completely reverted 
> > > >>> until we have a better solution? let see what Mike thinks about it.
> > > >>>
> > > >>> Thanks,
> > > >>>
> > > >>> Ignacio
> > > >>>
> > > >>> On Wed, Oct 9, 2019 at 4:51 PM Uwe Schindler  wrote:
> > > 
> > >  Hi,
> > > 
> > >  I also had a customer complaining about this. I have the feeling it 
> > >  also happens from time to time during inter node comm, which uses 
> > >  solrj, too.
> > > 
> > >  Uwe
> > > 
> > >  Am October 9, 2019 1:38:00 PM UTC schrieb Ishan Chattopadhyaya 
> > >  :
> > > >
> > > > +1, Dat! Please go ahead.
> > > >
> > > > On Wed, 9 Oct, 2019, 2:33 PM Andrzej Białecki,  
> > > > wrote:
> > > >>
> > > >> It’s marked as Minor in Jira, but after reading the description it 
> > > >> sounds scary - IMHO it should be at least well investigated before 
> > > >> 8.3 in order to determine whether it causes real damage (apart 
> > > >> from looking scary and filling the logs).
> > > >>
> > > >> +1 from me.
> > > >>
> > > >> On 9 Oct 2019, at 10:48, Đạt Cao Mạnh  
> > > >> wrote:
> > > >>
> > > >> Hi Ishan, guys
> > > >>
> > > >> I want to include the fix for 
> > > >> https://issues.apache.org/jira/browse/SOLR-13293 in this release. 
> > > >> Hoping that is ok!
> > > >>
> > > >> Thanks!
> > > >>
> > > >> On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler  
> > > >> wrote:
> > > >>>
> > > >>> ASF Jenkins Jobs also reconfigured.
> > > >>>
> > > >>> I left the 8.2 Refguide job in the queue (I cloned it), not sure 
> > > >>> if that one is still needed. All other jobs are 8.3 now.
> > > >>>
> > > >>> Uwe
> > > >>>
> > > >>> -
> > > >>> Uwe Schindler
> > > >>> Achterdiek 19, D-28357 Bremen
> > > >>> https://www.thetaphi.de
> > > >>> eMail: u...@thetaphi.de
> > > >>>
> > > >>> > -Original Message-
> > > >>> > From: Uwe Schindler 
> > > >>> > Sent: Tuesday, October 8, 2019 4:49 PM
> > > >>> > To: dev@lucene.apache.org
> > > >>> > Subject: RE: 8.3 release
> > > >>> >
> > > >>> > Policeman Jenkins builds and tests 8.3 for Windows and Linux.
> > > >>> >
> > > >>> > Uwe
> > > >>> >
> > > >>> > -
> > > >>> > Uwe Schindler
> > > >>> > Achterdiek 19, D-28357 Bremen
> > > >>> > https://www.thetaphi.de
> > > >>> > eMail: u...@thetaphi.de
> > > >>> >
> > > >>> > > -Original Message-
> > > >>> > > From: Ishan Chattopadhyaya 
> > > >>> > > Sent: Tuesday, October 8, 2019 4:32 PM
> > > >>> > > To: Lucene Dev ; Uwe Schindler
> > > >>> > > ; Steve Rowe 
> > >

Why don't recycle dwpt by default?

2019-10-16 Thread 기준 
Hi expert!
I wonder what is the reason that Lucene don't recycle dwpt by default after
flushing.
I guess it's maybe good to release an used buffer to be garbage collected
so that JVM has less burden to have it.

Are there any related reporting or issues that I can learn?

Thank you!