[jira] [Commented] (SOLR-14781) Remove unused classes

2020-12-12 Thread Gaurav Agarwal (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-14781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248524#comment-17248524
 ] 

Gaurav Agarwal commented on SOLR-14781:
---

Hello David,

I am a developer and want myself to get involved and contribute. I am looking 
for tickets which are small and less impact and found this one interesting. 
Just wondering if I can share some of the work ?

> Remove unused classes
> -
>
> Key: SOLR-14781
> URL: https://issues.apache.org/jira/browse/SOLR-14781
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Minor
>  Labels: newdev
> Attachments: unused.xml
>
>
> There are a number of lingering classes in Solr that are not used anymore, 
> lingering after long-gone refactorings or who knows what.  They should be 
> removed, of course.



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

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



[jira] [Comment Edited] (SOLR-14788) Solr: The Next Big Thing

2020-12-12 Thread Mark Robert Miller (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248503#comment-17248503
 ] 

Mark Robert Miller edited comment on SOLR-14788 at 12/13/20, 3:25 AM:
--

Oh right, and the thing that happened at age 5 was they sent me to 
kindergarten, I cried and/or tantrum’d, don’t recall, until they took me out 
and tried again the next year. The first time I lost so much freedom for such a 
lousy trade. Point being, I won’t argue than I’m crazy now, but I was crazy 
then and every day in between, so it’s irrelevant. I can make this sing 
regardless of my taste for boring and normal and others assumed perceptions. So 
there was legitimate concern there, and I just want to say, I dislike that, 
because it’s a real thing, so I was sensitive to it, but at the same time, 
letting that dictate who and what I presented was exactly what I needed to 
escape to do this. So that’s all. Just, yeah, I was sensitive to those things, 
if anything I’m too sensitive unless I’m not sensitive at all, but I am who I 
am regardless, I had to tackle this, tackle something, before I tackled 
nothing. 


was (Author: markrmiller):
Oh right, and the thing that happened at age 5 was they sent me to 
kindergarten, I cried and/or tantrum’d, don’t recall, until they took me out 
and tried again the next year. The first time I lost so much freedom for such a 
lousy trade. Point being, I won’t argue than I’m crazy now, but I was crazy 
then and every day in between, so it’s irrelevant. I can make this sing 
regardless of my taste for boring and normal and others assumed perceptions. So 
there was legitimate concern there, and I just want to say, I dislike that, 
because it’s a real thing, so I was sensitive to it, but at the same time, 
letting that dictate who and what I presented was exactly what I needed to 
escape to do this. So that’s all. Just, yeah, I was sensitive to those things, 
if anything I’m too sensitive unless I’m not sensitive at all, but I am who I 
am regardless, I had to tackle this, tackle something, before u tackled 
nothing. 

> Solr: The Next Big Thing
> 
>
> Key: SOLR-14788
> URL: https://issues.apache.org/jira/browse/SOLR-14788
> Project: Solr
>  Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Critical
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> h3. 
> [!https://www.unicode.org/consortium/aacimg/1F46E.png!|https://www.unicode.org/consortium/adopted-characters.html#b1F46E]{color:#00875a}*The
>  Policeman is {color:#de350b}NOW{color} {color:#de350b}OFF{color} 
> duty!*{color}
> {quote}_{color:#de350b}*When The Policeman is on duty, sit back, relax, and 
> have some fun. Try to make some progress. Don't stress too much about the 
> impact of your changes or maintaining stability and performance and 
> correctness so much. Until the end of phase 1, I've got your back. I have a 
> variety of tools and contraptions I have been building over the years and I 
> will continue training them on this branch. I will review your changes and 
> peer out across the land and course correct where needed. As Mike D will be 
> thinking, "Sounds like a bottleneck Mark." And indeed it will be to some 
> extent. Which is why once stage one is completed, I will flip The Policeman 
> to off duty. When off duty, I'm always* *occasionally*{color} *down for some 
> vigilante justice, but I won't be walking the beat, all that stuff about sit 
> back and relax goes out the window.*_
> {quote}
>  
> I have stolen this title from Ishan or Noble and Ishan.
> This issue is meant to capture the work of a small team that is forming to 
> push Solr and SolrCloud to the next phase.
> I have kicked off the work with an effort to create a very fast and solid 
> base. That work is not 100% done, but it's ready to join the fight.
> Tim Potter has started giving me a tremendous hand in finishing up. Ishan and 
> Noble have already contributed support and testing and have plans for 
> additional work to shore up some of our current shortcomings.
> Others have expressed an interest in helping and hopefully they will pop up 
> here as well.
> Let's organize and discuss our efforts here and in various sub issues.



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

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



[jira] [Commented] (SOLR-14788) Solr: The Next Big Thing

2020-12-12 Thread Mark Robert Miller (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248503#comment-17248503
 ] 

Mark Robert Miller commented on SOLR-14788:
---

Oh right, and the thing that happened at age 5 was they sent me to 
kindergarten, I cried and/or tantrum’d, don’t recall, until they took me out 
and tried again the next year. The first time I lost so much freedom for such a 
lousy trade. Point being, I won’t argue than I’m crazy now, but I was crazy 
then and every day in between, so it’s irrelevant. I can make this sing 
regardless of my taste for boring and normal and others assumed perceptions. So 
there was legitimate concern there, and I just want to say, I dislike that, 
because it’s a real thing, so I was sensitive to it, but at the same time, 
letting that dictate who and what I presented was exactly what I needed to 
escape to do this. So that’s all. Just, yeah, I was sensitive to those things, 
if anything I’m too sensitive unless I’m not sensitive at all, but I am who I 
am regardless, I had to tackle this, tackle something, before u tackled 
nothing. 

> Solr: The Next Big Thing
> 
>
> Key: SOLR-14788
> URL: https://issues.apache.org/jira/browse/SOLR-14788
> Project: Solr
>  Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Critical
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> h3. 
> [!https://www.unicode.org/consortium/aacimg/1F46E.png!|https://www.unicode.org/consortium/adopted-characters.html#b1F46E]{color:#00875a}*The
>  Policeman is {color:#de350b}NOW{color} {color:#de350b}OFF{color} 
> duty!*{color}
> {quote}_{color:#de350b}*When The Policeman is on duty, sit back, relax, and 
> have some fun. Try to make some progress. Don't stress too much about the 
> impact of your changes or maintaining stability and performance and 
> correctness so much. Until the end of phase 1, I've got your back. I have a 
> variety of tools and contraptions I have been building over the years and I 
> will continue training them on this branch. I will review your changes and 
> peer out across the land and course correct where needed. As Mike D will be 
> thinking, "Sounds like a bottleneck Mark." And indeed it will be to some 
> extent. Which is why once stage one is completed, I will flip The Policeman 
> to off duty. When off duty, I'm always* *occasionally*{color} *down for some 
> vigilante justice, but I won't be walking the beat, all that stuff about sit 
> back and relax goes out the window.*_
> {quote}
>  
> I have stolen this title from Ishan or Noble and Ishan.
> This issue is meant to capture the work of a small team that is forming to 
> push Solr and SolrCloud to the next phase.
> I have kicked off the work with an effort to create a very fast and solid 
> base. That work is not 100% done, but it's ready to join the fight.
> Tim Potter has started giving me a tremendous hand in finishing up. Ishan and 
> Noble have already contributed support and testing and have plans for 
> additional work to shore up some of our current shortcomings.
> Others have expressed an interest in helping and hopefully they will pop up 
> here as well.
> Let's organize and discuss our efforts here and in various sub issues.



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

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



[jira] [Commented] (SOLR-14788) Solr: The Next Big Thing

2020-12-12 Thread Mark Robert Miller (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248496#comment-17248496
 ] 

Mark Robert Miller commented on SOLR-14788:
---

Oh, and what’s with all the dragons and Shonen? Well there were multiple large 
beasts I was trying to slay, having chilled in the village most of my life, 
leaving dragon slaying to those looking for high risk and training and effort. 
I knew I could beat this, I didn’t know if could beat me.

And Shonen stories tend to follow a fun loving, kind of dopey kid, surrounded 
by smarter and more talented comrades, but who perseveres more than anyone, 
until they are the Hokage or something. The will to get better and more 
training  is always the answer. The gutsy Ninja never gives up.

The hard part is over, but inspiration, motivation and god knows what the hell 
the dude I’ve been observing my whole life was doing to go against his nature, 
got me there. That and doing my best to lock myself into a do or die (hardly) 
position.

So yeah, confusing, annoying, who knows all feelings, but long short, the path 
from there to here. The future looks less dire. The Hokage does more paper work 
than missions or training when there are no Ninja wars. 

> Solr: The Next Big Thing
> 
>
> Key: SOLR-14788
> URL: https://issues.apache.org/jira/browse/SOLR-14788
> Project: Solr
>  Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Critical
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> h3. 
> [!https://www.unicode.org/consortium/aacimg/1F46E.png!|https://www.unicode.org/consortium/adopted-characters.html#b1F46E]{color:#00875a}*The
>  Policeman is {color:#de350b}NOW{color} {color:#de350b}OFF{color} 
> duty!*{color}
> {quote}_{color:#de350b}*When The Policeman is on duty, sit back, relax, and 
> have some fun. Try to make some progress. Don't stress too much about the 
> impact of your changes or maintaining stability and performance and 
> correctness so much. Until the end of phase 1, I've got your back. I have a 
> variety of tools and contraptions I have been building over the years and I 
> will continue training them on this branch. I will review your changes and 
> peer out across the land and course correct where needed. As Mike D will be 
> thinking, "Sounds like a bottleneck Mark." And indeed it will be to some 
> extent. Which is why once stage one is completed, I will flip The Policeman 
> to off duty. When off duty, I'm always* *occasionally*{color} *down for some 
> vigilante justice, but I won't be walking the beat, all that stuff about sit 
> back and relax goes out the window.*_
> {quote}
>  
> I have stolen this title from Ishan or Noble and Ishan.
> This issue is meant to capture the work of a small team that is forming to 
> push Solr and SolrCloud to the next phase.
> I have kicked off the work with an effort to create a very fast and solid 
> base. That work is not 100% done, but it's ready to join the fight.
> Tim Potter has started giving me a tremendous hand in finishing up. Ishan and 
> Noble have already contributed support and testing and have plans for 
> additional work to shore up some of our current shortcomings.
> Others have expressed an interest in helping and hopefully they will pop up 
> here as well.
> Let's organize and discuss our efforts here and in various sub issues.



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

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



[jira] [Comment Edited] (SOLR-14788) Solr: The Next Big Thing

2020-12-12 Thread Mark Robert Miller (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248383#comment-17248383
 ] 

Mark Robert Miller edited comment on SOLR-14788 at 12/12/20, 4:47 PM:
--

Whew, I honestly can't believe I could not con Mexico into building this thing, 
but plan B is still fire. I've got to spend some time shining a light on what 
this can do and on 9x/master, but once that is over, anyone that wants to 
challenge the very top distributed Java systems out there, let's go man, I've 
got the groundwork (I'll convince you first so we don't have to fight too much 
about groundwork), now I just need the team. We are going to build spectacular, 
if that's an exaggeration I'd forget this and go back to bad/bed, so you want 
to be aboard. Very satisfying. 


was (Author: markrmiller):
Whew, I honestly can't believe I could not con Mexico into building this thing, 
but plan B is still fire. I've got to spend some time shining a light on what 
this can do and on 9x/master, but once that is over, anyone that wants to 
challenge the very top distributed Java systems out there, let's go man, I've 
got the groundwork (I'll convince you first so we don't have to fight too much 
about groundwork), now I just need the team. We are going to build spectacular, 
if that's an exaggeration I'd forget this and go back to bad, so you want to be 
aboard. Very satisfying. 

> Solr: The Next Big Thing
> 
>
> Key: SOLR-14788
> URL: https://issues.apache.org/jira/browse/SOLR-14788
> Project: Solr
>  Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Critical
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> h3. 
> [!https://www.unicode.org/consortium/aacimg/1F46E.png!|https://www.unicode.org/consortium/adopted-characters.html#b1F46E]{color:#00875a}*The
>  Policeman is {color:#de350b}NOW{color} {color:#de350b}OFF{color} 
> duty!*{color}
> {quote}_{color:#de350b}*When The Policeman is on duty, sit back, relax, and 
> have some fun. Try to make some progress. Don't stress too much about the 
> impact of your changes or maintaining stability and performance and 
> correctness so much. Until the end of phase 1, I've got your back. I have a 
> variety of tools and contraptions I have been building over the years and I 
> will continue training them on this branch. I will review your changes and 
> peer out across the land and course correct where needed. As Mike D will be 
> thinking, "Sounds like a bottleneck Mark." And indeed it will be to some 
> extent. Which is why once stage one is completed, I will flip The Policeman 
> to off duty. When off duty, I'm always* *occasionally*{color} *down for some 
> vigilante justice, but I won't be walking the beat, all that stuff about sit 
> back and relax goes out the window.*_
> {quote}
>  
> I have stolen this title from Ishan or Noble and Ishan.
> This issue is meant to capture the work of a small team that is forming to 
> push Solr and SolrCloud to the next phase.
> I have kicked off the work with an effort to create a very fast and solid 
> base. That work is not 100% done, but it's ready to join the fight.
> Tim Potter has started giving me a tremendous hand in finishing up. Ishan and 
> Noble have already contributed support and testing and have plans for 
> additional work to shore up some of our current shortcomings.
> Others have expressed an interest in helping and hopefully they will pop up 
> here as well.
> Let's organize and discuss our efforts here and in various sub issues.



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

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



[jira] [Commented] (SOLR-14788) Solr: The Next Big Thing

2020-12-12 Thread Mark Robert Miller (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248383#comment-17248383
 ] 

Mark Robert Miller commented on SOLR-14788:
---

Whew, I honestly can't believe I could not con Mexico into building this thing, 
but plan B is still fire. I've got to spend some time shining a light on what 
this can do and on 9x/master, but once that is over, anyone that wants to 
challenge the very top distributed Java systems out there, let's go man, I've 
got the groundwork (I'll convince you first so we don't have to fight too much 
about groundwork), now I just need the team. We are going to build spectacular, 
if that's an exaggeration I'd forget this and go back to bad, so you want to be 
aboard. Very satisfying. 

> Solr: The Next Big Thing
> 
>
> Key: SOLR-14788
> URL: https://issues.apache.org/jira/browse/SOLR-14788
> Project: Solr
>  Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Critical
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> h3. 
> [!https://www.unicode.org/consortium/aacimg/1F46E.png!|https://www.unicode.org/consortium/adopted-characters.html#b1F46E]{color:#00875a}*The
>  Policeman is {color:#de350b}NOW{color} {color:#de350b}OFF{color} 
> duty!*{color}
> {quote}_{color:#de350b}*When The Policeman is on duty, sit back, relax, and 
> have some fun. Try to make some progress. Don't stress too much about the 
> impact of your changes or maintaining stability and performance and 
> correctness so much. Until the end of phase 1, I've got your back. I have a 
> variety of tools and contraptions I have been building over the years and I 
> will continue training them on this branch. I will review your changes and 
> peer out across the land and course correct where needed. As Mike D will be 
> thinking, "Sounds like a bottleneck Mark." And indeed it will be to some 
> extent. Which is why once stage one is completed, I will flip The Policeman 
> to off duty. When off duty, I'm always* *occasionally*{color} *down for some 
> vigilante justice, but I won't be walking the beat, all that stuff about sit 
> back and relax goes out the window.*_
> {quote}
>  
> I have stolen this title from Ishan or Noble and Ishan.
> This issue is meant to capture the work of a small team that is forming to 
> push Solr and SolrCloud to the next phase.
> I have kicked off the work with an effort to create a very fast and solid 
> base. That work is not 100% done, but it's ready to join the fight.
> Tim Potter has started giving me a tremendous hand in finishing up. Ishan and 
> Noble have already contributed support and testing and have plans for 
> additional work to shore up some of our current shortcomings.
> Others have expressed an interest in helping and hopefully they will pop up 
> here as well.
> Let's organize and discuss our efforts here and in various sub issues.



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

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



[jira] [Commented] (LUCENE-9021) QueryParser should avoid creating an LookaheadSuccess(Error) object with every instance

2020-12-12 Thread Mikhail Khludnev (Jira)


[ 
https://issues.apache.org/jira/browse/LUCENE-9021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248362#comment-17248362
 ] 

Mikhail Khludnev commented on LUCENE-9021:
--

Pushed to master. Thanks, [~pbruski_]. Would you mind to take care for PR 
against {{branch_8x}}?  

> QueryParser should avoid creating an LookaheadSuccess(Error) object with 
> every instance
> ---
>
> Key: LUCENE-9021
> URL: https://issues.apache.org/jira/browse/LUCENE-9021
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Przemek Bruski
>Priority: Major
> Attachments: LUCENE-9021.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This is basically the same as 
> https://issues.apache.org/jira/browse/SOLR-11242 , but for Lucene QueryParser



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

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



[jira] [Issue Comment Deleted] (LUCENE-9021) QueryParser should avoid creating an LookaheadSuccess(Error) object with every instance

2020-12-12 Thread Mikhail Khludnev (Jira)


 [ 
https://issues.apache.org/jira/browse/LUCENE-9021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev updated LUCENE-9021:
-
Comment: was deleted

(was: Commit 6dfb55d5956bb27a05a3bc184df10705fe835ad8 in lucene-solr's branch 
refs/heads/revert-962-jira/LUCENE-9021 from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6dfb55d ]

Revert "LUCENE-9021 QueryParser: re-use the LookaheadSuccess exception (#962)"

This reverts commit ccf3e604537e884e25d33dc9d921cc5e5e1fa284.
)

> QueryParser should avoid creating an LookaheadSuccess(Error) object with 
> every instance
> ---
>
> Key: LUCENE-9021
> URL: https://issues.apache.org/jira/browse/LUCENE-9021
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Przemek Bruski
>Priority: Major
> Attachments: LUCENE-9021.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This is basically the same as 
> https://issues.apache.org/jira/browse/SOLR-11242 , but for Lucene QueryParser



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

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



[jira] [Commented] (LUCENE-9021) QueryParser should avoid creating an LookaheadSuccess(Error) object with every instance

2020-12-12 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/LUCENE-9021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248361#comment-17248361
 ] 

ASF subversion and git services commented on LUCENE-9021:
-

Commit 6dfb55d5956bb27a05a3bc184df10705fe835ad8 in lucene-solr's branch 
refs/heads/revert-962-jira/LUCENE-9021 from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6dfb55d ]

Revert "LUCENE-9021 QueryParser: re-use the LookaheadSuccess exception (#962)"

This reverts commit ccf3e604537e884e25d33dc9d921cc5e5e1fa284.


> QueryParser should avoid creating an LookaheadSuccess(Error) object with 
> every instance
> ---
>
> Key: LUCENE-9021
> URL: https://issues.apache.org/jira/browse/LUCENE-9021
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Przemek Bruski
>Priority: Major
> Attachments: LUCENE-9021.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This is basically the same as 
> https://issues.apache.org/jira/browse/SOLR-11242 , but for Lucene QueryParser



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

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



[jira] [Commented] (LUCENE-9021) QueryParser should avoid creating an LookaheadSuccess(Error) object with every instance

2020-12-12 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/LUCENE-9021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248360#comment-17248360
 ] 

ASF subversion and git services commented on LUCENE-9021:
-

Commit ccf3e604537e884e25d33dc9d921cc5e5e1fa284 in lucene-solr's branch 
refs/heads/master from Przemek Bruski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ccf3e60 ]

LUCENE-9021 QueryParser: re-use the LookaheadSuccess exception (#962)

* LUCENE-9021 QueryParser: re-use the LookaheadSuccess exception
Authored-by: Przemek Bruski 


> QueryParser should avoid creating an LookaheadSuccess(Error) object with 
> every instance
> ---
>
> Key: LUCENE-9021
> URL: https://issues.apache.org/jira/browse/LUCENE-9021
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Przemek Bruski
>Priority: Major
> Attachments: LUCENE-9021.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This is basically the same as 
> https://issues.apache.org/jira/browse/SOLR-11242 , but for Lucene QueryParser



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

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



[jira] [Commented] (LUCENE-9021) QueryParser should avoid creating an LookaheadSuccess(Error) object with every instance

2020-12-12 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/LUCENE-9021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248359#comment-17248359
 ] 

ASF subversion and git services commented on LUCENE-9021:
-

Commit ccf3e604537e884e25d33dc9d921cc5e5e1fa284 in lucene-solr's branch 
refs/heads/master from Przemek Bruski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ccf3e60 ]

LUCENE-9021 QueryParser: re-use the LookaheadSuccess exception (#962)

* LUCENE-9021 QueryParser: re-use the LookaheadSuccess exception
Authored-by: Przemek Bruski 


> QueryParser should avoid creating an LookaheadSuccess(Error) object with 
> every instance
> ---
>
> Key: LUCENE-9021
> URL: https://issues.apache.org/jira/browse/LUCENE-9021
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Przemek Bruski
>Priority: Major
> Attachments: LUCENE-9021.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This is basically the same as 
> https://issues.apache.org/jira/browse/SOLR-11242 , but for Lucene QueryParser



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

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



[GitHub] [lucene-solr] mkhludnev merged pull request #962: LUCENE-9021 QueryParser: re-use the LookaheadSuccess exception

2020-12-12 Thread GitBox


mkhludnev merged pull request #962:
URL: https://github.com/apache/lucene-solr/pull/962


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[jira] [Commented] (SOLR-14923) Indexing performance is unacceptable when child documents are involved

2020-12-12 Thread Jira


[ 
https://issues.apache.org/jira/browse/SOLR-14923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248316#comment-17248316
 ] 

Thomas Wöckinger commented on SOLR-14923:
-

{quote}in RTG.getInputDocument, you added the potential open _before_ the check 
if the doc from the updateLog is null... ({{sid == null}}) but shouldn't we not 
if sid isn't null? Thus move it down right below, indented. Also, maybe in DUP, 
we can sometimes further restrict when this logic happens – perhaps only when 
the document coming in is an atomic update. I'll investigate that.
{quote}
This was my first intention, but 
org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test will fail if doing so, 
didn't find the cause yet.
{quote}Earlier in this issue, you tried modifying 
UpdateLog.openRealtimeSearcher to move the searcher re-open outside of the 
synchronized block. That makes sense to me; we should do that.
{quote}
This will require some test modification, because some extra commits are 
required or must be moved, so the behavior will definitely change.

> Indexing performance is unacceptable when child documents are involved
> --
>
> Key: SOLR-14923
> URL: https://issues.apache.org/jira/browse/SOLR-14923
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update, UpdateRequestProcessors
>Affects Versions: 8.3, 8.4, 8.5, 8.6, master (9.0)
>Reporter: Thomas Wöckinger
>Priority: Critical
>  Labels: performance, pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Parallel indexing does not make sense at moment when child documents are used.
> The org.apache.solr.update.processor.DistributedUpdateProcessor checks at the 
> end of the method doVersionAdd if Ulog caches should be refreshed.
> This check will return true if any child document is included in the 
> AddUpdateCommand.
> If so ulog.openRealtimeSearcher(); is called, this call is very expensive, 
> and executed in a synchronized block of the UpdateLog instance, therefore all 
> other operations on the UpdateLog are blocked too.
> Because every important UpdateLog method (add, delete, ...) is done using a 
> synchronized block almost each operation is blocked.
> This reduces multi threaded index update to a single thread behavior.
> The described behavior is not depending on any option of the UpdateRequest, 
> so it does not make any difference if 'waitFlush', 'waitSearcher' or 
> 'softCommit'  is true or false.
> The described behavior makes the usage of ChildDocuments useless, because the 
> performance is unacceptable.
>  
>  



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

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