from:"Ryan Josal"

Re: Future of FieldCache in Solr

2016-11-24 Thread Ryan Josal

We use Toke's scenario in a couple places too. We are capable writing a URP
that does it, but it feels dirty, and replacing config with code seems like
something it makes sense to avoid.

Having top level support of some kind of analysis in URP or somewhere else
can also help in other situations where you want some analysis before it
goes in a non-TextField.

Ryan

On Thu, Nov 24, 2016 at 00:53 Toke Eskildsen  wrote:

> On Wed, 2016-11-23 at 13:23 +, David Smiley wrote:
> > This is supported at the Lucene level via SortedSetDocValues.  Solr
> > doesn't yet support this for its TextField
> > -- https://issues.apache.org/jira/browse/SOLR-8362
> >  however you could work around this with an URP or copyField
>
> copyfield does not help here as that copies the raw values. We need the
> normalised values for display when we do faceting.
>
> >  or perhaps subclassing TextField so that you can tokenize the text a
> > second time to generate a list of SortedSetDocValuesField.  Probably
> > least painless is to use another field.
>
> So to facet on the normalised (analyzed really) values on a Text field
> in a post-FieldCache Solr, I would need to write an URP or some other
> custom code. I can manage that or just do the normalisation as part of
> the pre-processing.
>
> Question is if my scenario (using analyzers for facet terms) is wide-
> spread? If so, I find this increase in implementation requirements
> problematic.
>
>
> I don't care for FieldCache as such - SOLR-8362 would be a better
> solution for the scenario I describe. Or maybe an URP that makes it
> easy to provide a list of analyzers? I am simply looking for a way
> that a random end-user can easily do faceting on analyzed terms,
> leveraging all the nice build-in filters in Solr.
>
> - Toke Eskildsen, State and University Library, Denmark
>

Re: Collection API for performance monitoring?

2016-11-15 Thread Ryan Josal

I haven't tried for 95th percentile, but generally with those collection
start stats you would monitor based on calculated deltas.  You can figure
out the average response time for any given window of time not smaller than
your snapshot polling interval.  I don't see why 95th percentile would be
any different.

Ryan

On Monday, November 14, 2016, Walter Underwood 
wrote:

> Because the current stats are not usable. They really should be removed
> from the code.
>
> They calculate percentiles since the last collection load. We need to know
> 95th percentile
> during the peak hour last night, not the 95th for the last month.
>
> Right now, we run eleven collections in our Solr 4 cluster. In each
> collection, we have
> several different handlers. Usually, one for autosuggest (instant
> results), one for the SRP,
> and one for mobile, though we also have SEO requests and so on. We can
> track performance
> for each of these.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> 
> http://observer.wunderwood.org/  (my blog)
>
>
> On Nov 14, 2016, at 3:54 PM, Erick Erickson  > wrote:
>
> Point taken, and thanks for the link. The stats I'm referring to in
> this thread are available now, and would (I think) be a quick win. I
> don't have a huge amount of investment in it though, more "why didn't
> we think of this before?" followed by "maybe there's a very good
> reason not to bother". This may be it since we now standardize on
> Jetty. My question of course is whether this would be supported moving
> forward to netty or whatever...
>
> Best,
> Erick
>
> On Mon, Nov 14, 2016 at 3:44 PM, Walter Underwood  > wrote:
>
> I’m not fond of polling for performance stats. I’d rather have the app
> report them.
>
> We could integrate existing Jetty monitoring:
>
> http://metrics.dropwizard.io/3.1.0/manual/jetty/
>
> From our experience with a similar approach, we might need some
> Solr-specific metric
> conflation. SolrJ sends a request to /solr/collection/handler as
> /solr/collection/select?qt=/handler.
> In our code, we fix that request to the intended path. We’ve been running a
> Tomcat metrics search
> filter for three years.
>
> Also, see:
>
> https://issues.apache.org/jira/browse/SOLR-8785
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> 
> http://observer.wunderwood.org/  (my blog)
>
>
> On Nov 14, 2016, at 3:25 PM, Erick Erickson  > wrote:
>
> What do people think about exposing a Collections API call (name TBD,
> but the sense is PERFORMANCESTATS) that would simply issue the
> admin/mbeans call to each replica of a collection and report them
> back. This would give operations monitors the ability to see, say,
> anomalous replicas that had poor average response times for the last 5
> minutes and the like.
>
> Seems like an easy enhancement that would make ops people's lives easier.
>
> I'll raise a JIRA if there's interest, but sure won't make progress on
> it until I clear my plate of some other JIRAs that I've let linger for
> far too long.
>
> Erick
>
> -
> 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
> 
>
>
>

[jira] [Commented] (SOLR-4736) Support group.mincount for Result Grouping

2016-10-03 Thread Ryan Josal (JIRA)


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

Ryan Josal commented on SOLR-4736:
--

I just came across a use case where this would be useful, like facet.mincount 
sometimes is.  I'm not sure Type: Bug is the correct classification though.

> Support group.mincount for Result Grouping
> --
>
> Key: SOLR-4736
> URL: https://issues.apache.org/jira/browse/SOLR-4736
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 4.2
>Reporter: jefferyyuan
>Priority: Minor
>  Labels: group, solr
> Fix For: 4.9, 6.0
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Result Grouping is a very useful feature: we can use it to find duplicate 
> data in index, but it lacks of one feature-group.mincount. 
> With group.mincount, we can specify that only groups that has equal or more 
> than ${mincount} for the group field will be returned.
> Specially, we can use group.mincount=2 to only return duplicate data.
> Could we add this in future release? Thanks. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module

2016-07-27 Thread Ryan Josal (JIRA)


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

Ryan Josal commented on LUCENE-2899:


Seconded, this is really useful stuff.

> Add OpenNLP Analysis capabilities as a module
> -
>
> Key: LUCENE-2899
> URL: https://issues.apache.org/jira/browse/LUCENE-2899
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 4.9, 6.0
>
> Attachments: LUCENE-2899-6.1.0.patch, LUCENE-2899-RJN.patch, 
> LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
> LUCENE-2899.patch, OpenNLPFilter.java, OpenNLPTokenizer.java
>
>
> Now that OpenNLP is an ASF project and has a nice license, it would be nice 
> to have a submodule (under analysis) that exposed capabilities for it. Drew 
> Farris, Tom Morton and I have code that does:
> * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
> would have to change slightly to buffer tokens)
> * NamedEntity recognition as a TokenFilter
> We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
> either payloads (PartOfSpeechAttribute?) on a token or at the same position.
> I'd propose it go under:
> modules/analysis/opennlp



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: lucene-solr:master: Move non-inner classes to separate files: This breaks IDEs and update checks by javac

2016-05-17 Thread Ryan Josal

Uwe, I agree keeping pkg private is the simplest and safest approach, and
yes a static inner class would solve the problem of JSONWriter, though for
consistency's sake, JSONWriter feels like it should become a top level
public class like it's counterpart XMLWriter.

Ryan

On Monday, May 16, 2016, Uwe Schindler <u...@thetaphi.de> wrote:

> Hi,
>
>
>
> I think there was an issue open about that years ago, but I did not catch
> all of those when fixing it. And the facet ones are new.
>
>
>
> When I have time, I will look into refactoring those classes, but there
> are 2 possibilities:
>
>
>
> -  Move them as static inner classes. This allows to make them
> public or otherwise visible (I think that is Ryan Josal’s problem).
>
> -  Just keep them pkg-private and move them to separate files.
> That’s easier and faster to do. This is what I have done because of the
> Eclipse problem.
>
>
>
> I prefer the second one, as it keeps API the same and does not change
> anything.
>
>
>
> I have no idea, if there is a way to detect those classes via a static
> tool.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de <javascript:_e(%7B%7D,'cvml','u...@thetaphi.de');>
>
>
>
> *From:* rjo...@gmail.com
> <javascript:_e(%7B%7D,'cvml','rjo...@gmail.com');> [mailto:
> rjo...@gmail.com <javascript:_e(%7B%7D,'cvml','rjo...@gmail.com');>] *On
> Behalf Of *Ryan Josal
> *Sent:* Monday, May 16, 2016 11:43 PM
> *To:* dev@lucene.apache.org
> <javascript:_e(%7B%7D,'cvml','dev@lucene.apache.org');>
> *Subject:* Re: lucene-solr:master: Move non-inner classes to separate
> files: This breaks IDEs and update checks by javac
>
>
>
> +1 it's a pain for plugin development too.  Extending JSONResponseWriter
> comes to mind.
>
> On Monday, May 16, 2016, Chris Hostetter <hossman_luc...@fucit.org
> <javascript:_e(%7B%7D,'cvml','hossman_luc...@fucit.org');>> wrote:
>
>
> : I found out that there are more of those in the facets module. Can we
> : change those to be real *inner* classes or put them in separate files?
>
> +1 ... it's a really obnoxiou missfeature of java in my opinion ... are
> there any static tools we can enable to fail the build for classes like
> these?
>
>
>
> : -
> : Uwe Schindler
> : H.-H.-Meier-Allee 63, D-28213 Bremen
> : http://www.thetaphi.de
> : eMail: u...@thetaphi.de
> :
> : > -Original Message-
> : > From: uschind...@apache.org [mailto:uschind...@apache.org]
> : > Sent: Monday, May 16, 2016 7:54 PM
> : > To: comm...@lucene.apache.org
> : > Subject: lucene-solr:master: Move non-inner classes to separate files:
> This
> : > breaks IDEs and update checks by javac
> : >
> : > Repository: lucene-solr
> : > Updated Branches:
> : >   refs/heads/master 6620fd142 -> ae93f4e7a
> : >
> : >
> : > Move non-inner classes to separate files: This breaks IDEs and update
> checks
> : > by javac
> : >
> : >
> : > Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> : > Commit: http://git-wip-us.apache.org/repos/asf/lucene-
> : > solr/commit/ae93f4e7
> : > Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/ae93f4e7
> : > Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/ae93f4e7
> : >
> : > Branch: refs/heads/master
> : > Commit: ae93f4e7ac6a3908046391de35d4f50a0d3c59ca
> : > Parents: 6620fd1
> : > Author: Uwe Schindler <uschind...@apache.org>
> : > Authored: Mon May 16 19:54:10 2016 +0200
> : > Committer: Uwe Schindler <uschind...@apache.org>
> : > Committed: Mon May 16 19:54:10 2016 +0200
> : >
> : > --
> : >  .../solr/search/facet/UniqueMultiDvSlotAcc.java |  86 ++
> : >  .../search/facet/UniqueMultivaluedSlotAcc.java  |  69 
> : >  .../search/facet/UniqueSinglevaluedSlotAcc.java |  81 +
> : >  .../apache/solr/search/facet/UniqueSlotAcc.java | 165
> ---
> : >  4 files changed, 236 insertions(+), 165 deletions(-)
> : > --
> : >
> : >
> : > http://git-wip-us.apache.org/repos/asf/lucene-
> : >
> solr/blob/ae93f4e7/solr/core/src/java/org/apache/solr/search/facet/Unique
> : > MultiDvSlotAcc.java
> : > --
> : > diff --git
> : >
> a/solr/core/src/java/org/apa

Re: lucene-solr:master: Move non-inner classes to separate files: This breaks IDEs and update checks by javac

2016-05-16 Thread Ryan Josal

+1 it's a pain for plugin development too.  Extending JSONResponseWriter
comes to mind.

On Monday, May 16, 2016, Chris Hostetter  wrote:

>
> : I found out that there are more of those in the facets module. Can we
> : change those to be real *inner* classes or put them in separate files?
>
> +1 ... it's a really obnoxiou missfeature of java in my opinion ... are
> there any static tools we can enable to fail the build for classes like
> these?
>
>
>
> : -
> : Uwe Schindler
> : H.-H.-Meier-Allee 63, D-28213 Bremen
> : http://www.thetaphi.de
> : eMail: u...@thetaphi.de 
> :
> : > -Original Message-
> : > From: uschind...@apache.org  [mailto:
> uschind...@apache.org ]
> : > Sent: Monday, May 16, 2016 7:54 PM
> : > To: comm...@lucene.apache.org 
> : > Subject: lucene-solr:master: Move non-inner classes to separate files:
> This
> : > breaks IDEs and update checks by javac
> : >
> : > Repository: lucene-solr
> : > Updated Branches:
> : >   refs/heads/master 6620fd142 -> ae93f4e7a
> : >
> : >
> : > Move non-inner classes to separate files: This breaks IDEs and update
> checks
> : > by javac
> : >
> : >
> : > Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> : > Commit: http://git-wip-us.apache.org/repos/asf/lucene-
> : > solr/commit/ae93f4e7
> : > Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/ae93f4e7
> : > Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/ae93f4e7
> : >
> : > Branch: refs/heads/master
> : > Commit: ae93f4e7ac6a3908046391de35d4f50a0d3c59ca
> : > Parents: 6620fd1
> : > Author: Uwe Schindler >
> : > Authored: Mon May 16 19:54:10 2016 +0200
> : > Committer: Uwe Schindler >
> : > Committed: Mon May 16 19:54:10 2016 +0200
> : >
> : > --
> : >  .../solr/search/facet/UniqueMultiDvSlotAcc.java |  86 ++
> : >  .../search/facet/UniqueMultivaluedSlotAcc.java  |  69 
> : >  .../search/facet/UniqueSinglevaluedSlotAcc.java |  81 +
> : >  .../apache/solr/search/facet/UniqueSlotAcc.java | 165
> ---
> : >  4 files changed, 236 insertions(+), 165 deletions(-)
> : > --
> : >
> : >
> : > http://git-wip-us.apache.org/repos/asf/lucene-
> : >
> solr/blob/ae93f4e7/solr/core/src/java/org/apache/solr/search/facet/Unique
> : > MultiDvSlotAcc.java
> : > --
> : > diff --git
> : >
> a/solr/core/src/java/org/apache/solr/search/facet/UniqueMultiDvSlotAcc.ja
> : > va
> : >
> b/solr/core/src/java/org/apache/solr/search/facet/UniqueMultiDvSlotAcc.ja
> : > va
> : > new file mode 100644
> : > index 000..4c29753
> : > --- /dev/null
> : > +++
> : >
> b/solr/core/src/java/org/apache/solr/search/facet/UniqueMultiDvSlotAcc.ja
> : > va
> : > @@ -0,0 +1,86 @@
> : > +/*
> : > + * Licensed to the Apache Software Foundation (ASF) under one or more
> : > + * contributor license agreements.  See the NOTICE file distributed
> with
> : > + * this work for additional information regarding copyright ownership.
> : > + * The ASF licenses this file to You under the Apache License,
> Version 2.0
> : > + * (the "License"); you may not use this file except in compliance
> with
> : > + * the License.  You may obtain a copy of the License at
> : > + *
> : > + * http://www.apache.org/licenses/LICENSE-2.0
> : > + *
> : > + * Unless required by applicable law or agreed to in writing, software
> : > + * distributed under the License is distributed on an "AS IS" BASIS,
> : > + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> : > implied.
> : > + * See the License for the specific language governing permissions and
> : > + * limitations under the License.
> : > + */
> : > +
> : > +package org.apache.solr.search.facet;
> : > +
> : > +import java.io.IOException;
> : > +
> : > +import org.apache.lucene.index.LeafReaderContext;
> : > +import org.apache.lucene.index.MultiDocValues;
> : > +import org.apache.lucene.index.SortedSetDocValues;
> : > +import org.apache.lucene.util.BytesRef;
> : > +import org.apache.lucene.util.FixedBitSet;
> : > +import org.apache.lucene.util.LongValues;
> : > +import org.apache.solr.search.SolrIndexSearcher;
> : > +
> : > +class UniqueMultiDvSlotAcc extends UniqueSlotAcc {
> : > +  final SortedSetDocValues topLevel;
> : > +  final SortedSetDocValues[] subDvs;
> : > +  final MultiDocValues.OrdinalMap ordMap;
> : > +  LongValues toGlobal;
> : > +  SortedSetDocValues subDv;
> : > +
> : > +  public UniqueMultiDvSlotAcc(FacetContext fcontext, String field, int
> : > numSlots, HLLAgg.HLLFactory factory) throws IOException {
> : > +super(fcontext, field, numSlots, factory);
> : > +SolrIndexSearcher searcher = fcontext.qcontext.searcher();
> : > +topLevel

Re: Schedule merges during off-peak hours?

2016-05-02 Thread Ryan Josal

I don't have a comment on whether or not it makes sense to have schedule
based merges, but I will say that search speed is impacted by segment
count, and if you're indexing constantly all day long, it's possible that
saving a merge until off peak hours may put more stress on your servers
than doing the merge.  Also, are you merging down to one segment?  I found
it to be a happy medium to merge down to 2 or 3 segments.

Ryan

On Monday, May 2, 2016, Bram Van Dam  wrote:

> On 02/05/16 06:45, Erick Erickson wrote:
> > If "commit intervals of around one minute" mean that you're taking 60
> > seconds for the commit to finish, then perhaps it's the opposite and
> > you're autowarming too much. I usually start my autowarm counts
> > around 16 or so for filterCache and queryResultCache...
>
> Hey Erick,
>
> I meant that a commit occurs every minute. Autowarming is disabled
> entirely, because with very frequent commits, searchers sometimes aren't
> used at all before another commit happens.
>
>  - Bram
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
>
>

Re: Jira Spam - And changes made as a result.

2016-04-22 Thread Ryan Josal

Thanks Anshum!  And yeah, a whitelist like that makes sense to me too.

On Friday, April 22, 2016, Ishan Chattopadhyaya <ichattopadhy...@gmail.com>
wrote:

> Btw, how about whitelisting everyone who has commented (a non-spam
> comment) at a Lucene/Solr issue before?
>
> On Sat, Apr 23, 2016 at 6:13 AM, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com
> <javascript:_e(%7B%7D,'cvml','ichattopadhy...@gmail.com');>> wrote:
>
>> Anshum, please add me as well. Thanks.
>>
>>
>> On Sat, Apr 23, 2016 at 6:01 AM, Anshum Gupta <ans...@anshumgupta.net
>> <javascript:_e(%7B%7D,'cvml','ans...@anshumgupta.net');>> wrote:
>>
>>> Hi Ryan,
>>>
>>> I've added you to the contributors group. You should be able to comment
>>> on JIRAs now.
>>>
>>> On Thu, Apr 21, 2016 at 8:51 PM, Ryan Josal <r...@josal.com
>>> <javascript:_e(%7B%7D,'cvml','r...@josal.com');>> wrote:
>>>
>>>> Woah, yeah, I have filed a few bugs as well as posted patches and
>>>> comments.  Indeed I don't seem to be able to comment anymore.  Anyone
>>>> want to add me (rjosal) to a role that can comment or create?
>>>>
>>>> Ryan
>>>>
>>>>
>>>> On Thursday, April 21, 2016, David Smiley <david.w.smi...@gmail.com
>>>> <javascript:_e(%7B%7D,'cvml','david.w.smi...@gmail.com');>> wrote:
>>>>
>>>>> Wow!  My reading of this is that the general public (i.e. not
>>>>> committers) won't be able to really do anything other than view JIRA 
>>>>> issues
>>>>> unless we expressly add individuals to a specific project group?  :-(
>>>>>  Clearly that sucks big time.  Is anyone reading this differently?
>>>>> Assuming this is true... at this point maybe there is nothing to do but
>>>>> wait until the inevitable requests come in for people to create/comment.
>>>>> Maybe send a message to the user lists?
>>>>>
>>>>> ~ David
>>>>>
>>>>> -- Forwarded message -
>>>>> From: Gav <gmcdon...@apache.org>
>>>>> Date: Fri, Apr 22, 2016 at 12:14 AM
>>>>> Subject: Jira Spam - And changes made as a result.
>>>>> To: infrastruct...@apache.org Infrastructure <
>>>>> infrastruct...@apache.org>
>>>>>
>>>>>
>>>>> Hi All,
>>>>>
>>>>> Apologies for notifying you after the fact.
>>>>>
>>>>> Earlier today (slowing down to a halt about 1/2 hr ago due to our
>>>>> changes) we had a
>>>>> big Spam attack directed at the ASF Jira instance.
>>>>>
>>>>> Many project were affected, including :-
>>>>>
>>>>> TM, ARROW ACCUMULO, ABDERA, JSPWIKI, QPIDIT, LOGCXX, HAWQ, AMQ, ATLAS,
>>>>> AIRFLOW, ACE, APEXCORE, RANGER and KYLIN .
>>>>>
>>>>> During the process we ended up banning 27 IP addresses , deleted well
>>>>> over 200 tickets, and about 2 dozen user accounts.
>>>>>
>>>>> The spammers were creating accounts using the normal system and going
>>>>> through the required captchas.
>>>>>
>>>>> In addition to the ban hammer and deletions and to prevent more spam
>>>>> coming in, we changed the 'Default Permissions Scheme' so that anyone in
>>>>> the 'jira-users' group are no longer allowed to 'Create' tickets and are 
>>>>> no
>>>>> longer allowed to 'Comment' on any tickets.
>>>>>
>>>>> Obviously that affects genuine users as well as the spammers, we know
>>>>> that.
>>>>>
>>>>> Replacement auth instead of jira-users group now includes allowing
>>>>> those in the 'Administrator, PMC, Committer, Contributor and Developer'
>>>>> ROLES in jira.
>>>>>
>>>>> Projects would you please assist in making this work - anyone that is
>>>>> not in any of those roles for your project; and needs access to be able to
>>>>> create issues and comment, please do add their jira id to one of the
>>>>> available roles. (Let us know if you need assistance in this area)
>>>>>
>>>>> This is a short term solution. For the medium to long term we are
>>>>> working on providing LDAP authentication for Jira and Confluence through
>>>>> Atlassian Crowd (likley).
>>>>>
>>>>> If any projects are still being affected, please notify us as you may
>>>>> be using another permissions scheme to the one altered. Notify us via 
>>>>> INFRA
>>>>> jira ticket or reply to this mail to infrastruct...@apache.org or
>>>>> join us on hipchat (https://www.hipchat.com/gIjVtYcNy)
>>>>>
>>>>> Any project seriously adversely impacted by our changes please do come
>>>>> talk to us and we'll see what we can work out.
>>>>>
>>>>> Thanks all for your patience and understanding.
>>>>>
>>>>> Gav... (ASF Infra)
>>>>> --
>>>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>>>> http://www.solrenterprisesearchserver.com
>>>>>
>>>>
>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>>
>>
>

Re: Jira Spam - And changes made as a result.

2016-04-21 Thread Ryan Josal

Woah, yeah, I have filed a few bugs as well as posted patches and
comments.  Indeed I don't seem to be able to comment anymore.  Anyone want
to add me (rjosal) to a role that can comment or create?

Ryan

On Thursday, April 21, 2016, David Smiley  wrote:

> Wow!  My reading of this is that the general public (i.e. not committers)
> won't be able to really do anything other than view JIRA issues unless we
> expressly add individuals to a specific project group?  :-(  Clearly that
> sucks big time.  Is anyone reading this differently?  Assuming this is
> true... at this point maybe there is nothing to do but wait until the
> inevitable requests come in for people to create/comment.  Maybe send a
> message to the user lists?
>
> ~ David
>
> -- Forwarded message -
> From: Gav  >
> Date: Fri, Apr 22, 2016 at 12:14 AM
> Subject: Jira Spam - And changes made as a result.
> To: infrastruct...@apache.org
> 
> Infrastructure  >
>
>
> Hi All,
>
> Apologies for notifying you after the fact.
>
> Earlier today (slowing down to a halt about 1/2 hr ago due to our changes)
> we had a
> big Spam attack directed at the ASF Jira instance.
>
> Many project were affected, including :-
>
> TM, ARROW ACCUMULO, ABDERA, JSPWIKI, QPIDIT, LOGCXX, HAWQ, AMQ, ATLAS,
> AIRFLOW, ACE, APEXCORE, RANGER and KYLIN .
>
> During the process we ended up banning 27 IP addresses , deleted well over
> 200 tickets, and about 2 dozen user accounts.
>
> The spammers were creating accounts using the normal system and going
> through the required captchas.
>
> In addition to the ban hammer and deletions and to prevent more spam
> coming in, we changed the 'Default Permissions Scheme' so that anyone in
> the 'jira-users' group are no longer allowed to 'Create' tickets and are no
> longer allowed to 'Comment' on any tickets.
>
> Obviously that affects genuine users as well as the spammers, we know
> that.
>
> Replacement auth instead of jira-users group now includes allowing those
> in the 'Administrator, PMC, Committer, Contributor and Developer' ROLES in
> jira.
>
> Projects would you please assist in making this work - anyone that is not
> in any of those roles for your project; and needs access to be able to
> create issues and comment, please do add their jira id to one of the
> available roles. (Let us know if you need assistance in this area)
>
> This is a short term solution. For the medium to long term we are working
> on providing LDAP authentication for Jira and Confluence through Atlassian
> Crowd (likley).
>
> If any projects are still being affected, please notify us as you may be
> using another permissions scheme to the one altered. Notify us via INFRA
> jira ticket or reply to this mail to infrastruct...@apache.org
>  or join us on
> hipchat (https://www.hipchat.com/gIjVtYcNy)
>
> Any project seriously adversely impacted by our changes please do come
> talk to us and we'll see what we can work out.
>
> Thanks all for your patience and understanding.
>
> Gav... (ASF Infra)
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>

Re: Term vs. token

2016-04-20 Thread Ryan Josal

My understanding is a Term is comprised of a "token" and a field.  So then
the documentation makes sense to me - return the count of tokens in a field
for example.  But there were a couple of references you had there that
don't match with that definition, like the number of tokens in a
collection.  Although maybe a Term doesn't have a whole token because what
about token attributes like payload.  I guess I've convinced myself I'm not
entirely clear about it either, but I do feel good about the concept that
tokens don't have fields.  You can tokenize a string without thinking about
fields, and they become terms with fields when you query.

Ryan

On Wednesday, April 20, 2016, Jack Krupansky 
wrote:

> Looking at the Lucene Similarity Javadoc, I see some references to tokens,
> but I am wondering if that is intentional or whether those should really be
> references to terms.
>
> For example:
>
>  *lengthNorm - computed
>  *when the document is added to the index in accordance with the
> number of tokens
>  *of this field in the document, so that shorter fields contribute
> more to the score.
>
> I think that should be terms, not tokens.
>
> See:
>
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/5.5.0/lucene/core/src/java/org/apache/lucene/search/similarities/TFIDFSimilarity.java#L466
>
> And this:
>
>* Returns the total number of tokens in the field.
>* @see Terms#getSumTotalTermFreq()
>*/
>   public long getNumberOfFieldTokens() {
> return numberOfFieldTokens;
>
> I think that should be terms as well:
>
> See:
>
> https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/search/similarities/BasicStats.java#L65
>
> And... this:
>
>   numberOfFieldTokens = sumTotalTermFreq;
>
> Where it is clearly starting with terms and treating them as tokens, but
> as in the previous example, I think that should be terms as well.
>
> See:
>
> https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/search/similarities/SimilarityBase.java#L128
>
> One last example:
>
>* Compute any collection-level weight (e.g. IDF, average document
> length, etc) needed for scoring a query.
>*
>* @param collectionStats collection-level statistics, such as the
> number of tokens in the collection.
>* @param termStats term-level statistics, such as the document
> frequency of a term across the collection.
>* @return SimWeight object with the information this Similarity needs
> to score a query.
>*/
>   public abstract SimWeight computeWeight(CollectionStatistics
> collectionStats, TermStatistics... termStats);
>
> See:
>
> https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/search/similarities/Similarity.java#L161
>
> In fact, CollectionStatistics uses term, not token:
>
>   /** returns the total number of tokens for this field
>* @see Terms#getSumTotalTermFreq() */
>   public final long sumTotalTermFreq() {
> return sumTotalTermFreq;
>
> Oops... it uses both, emphasizing my point about the confusion.
>
> There are other examples as well.
>
> My understanding is that tokens are merely a temporary transition in
> between the original raw source text for a field and then final terms to be
> indexed (or query terms from a parsed and analyzed query.) Yes, during and
> within TokenStream or the analyzer we speak of tokens and intermediate
> string values are referred to as tokens, but once the final string value is
> retrieved from the Token Stream (analyzer), it's a term.
>
> In any case, is there some distinction in any of these cited examples (or
> other examples in this or related code) where "token" is an important
> distinction to be made and "term" is not the proper... term... to be used?
>
> Unless the Lucene project fully intends that the terms token and term are
> absolutely synonymous, a clear distinction should be drawn... I think. Or
> at least the terms should be used consistently, which my last example
> highlights.
>
> Thanks.
>
> -- Jack Krupansky
>

[jira] [Commented] (SOLR-8812) ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND

2016-03-19 Thread Ryan Josal (JIRA)


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

Ryan Josal commented on SOLR-8812:
--

On the topic of SOLR-2649, I just upgraded to 5.5 yesterday and SOLR-2649 broke 
one of our test cases which was "hair ties -barbie" should return hair ties but 
not barbie hair ties, and now it matches nothing.  I assume this is intended, 
but if not, maybe this ticket also addresses it?

> ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND
> 
>
> Key: SOLR-8812
> URL: https://issues.apache.org/jira/browse/SOLR-8812
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 5.5
>Reporter: Ryan Steinberg
>Priority: Blocker
> Fix For: 6.0, 5.5.1
>
> Attachments: SOLR-8812.patch
>
>
> The edismax parser ignores Boolean OR in queries when q.op=AND. This behavior 
> is new to Solr 5.5.0 and an unexpected major change.
> Example:
>   "q": "id:12345 OR zz",
>   "defType": "edismax",
>   "q.op": "AND",
> where "12345" is a known document ID and "zz" is a string NOT present 
> in my data
> Version 5.5.0 produces zero results:
> "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+((id:12345 
> DisjunctionMaxQuery((text:zz)))~2))/no_coord",
> "parsedquery_toString": "+((id:12345 (text:zz))~2)",
> "explain": {},
> "QParser": "ExtendedDismaxQParser"
> Version 5.4.0 produces one result as expected
>   "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+(id:12345 
> DisjunctionMaxQuery((text:zz/no_coord",
> "parsedquery_toString": "+(id:12345 (text:zz))"
> "explain": {},
> "QParser": "ExtendedDismaxQParser"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: An unusual (new?) multi term synonym bug?

2016-02-26 Thread Ryan Josal

Is this by design or is there a Jira to track it?  It makes it a little
difficult to use my own synonyms with wordnet.  Other use cases:
*) SynonymFilters separated by other filters
*) SynonymFilters with different analyzers configured
*) SynonymFilters with different case sensitivity

Expansion wouldn't be an issue since you can control it with file format.

Would it be ok to update some documentation about this?  The
AnalyzersTokenizersTokenFilters page comes to mind (by the way, the
tokenizerFactory search-lucene.com link is throwing an exception).

Ryan

On Friday, February 26, 2016, Michael McCandless <luc...@mikemccandless.com>
wrote:

> You can't put a SynonymFilter in front of another one, because the 2nd
> one is unable to properly consume an arbitrary graph..
>
> For the same reason, you can't put e.g. JapaneseTokenizer before a
> SynonymFilter and expect it to always work.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Thu, Feb 25, 2016 at 6:10 PM, Ryan Josal <rjo...@gmail.com
> <javascript:;>> wrote:
> > I know, there's a ton of documentation about the query parser whitespace
> > issue, and there's also a fair bit of info on the positionLengthAttribute
> > issue, but I seem to have stumbled upon a new issue with multi term
> > synonyms: it doesn't seem to play well with a bunch of tokens in the same
> > position.
> >
> > I have a synonym filter with this expansion:
> > side table,end table
> >
> > I can see the synonym is applied when looking at the token stream output
> for
> > "side table".  Today I decided to throw an additional synonymFilter
> > immediately before that one with wordnet synonym expansions.  Wordnet
> > expectedly bloats the tokenstream, but all of a sudden the original end
> > table expansion doesn't get applied.  I see "side" followed by a bunch of
> > tokens in the same position, followed by a couple new tokens in the next
> > position, followed by "table" in the same token position, followed by
> some
> > more new tokens in the same position.  Since side is still adjacent to
> table
> > in token positions, I would expect the synonym to hit.  Is this a known
> > issue (what's the Jira)?  The impact seems significant.  Since wordnet
> is so
> > comprehensive, it's likely going to cause this issue with most of my
> multi
> > term synonyms.  Maybe the workaround is to apply multi term synonyms
> first
> > as best is possible, although I don't know if you have that kind of
> control
> > if all your synonyms are applied by a single SynonymFilter.
> >
> > Thanks,
> > Ryan
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org <javascript:;>
> For additional commands, e-mail: dev-h...@lucene.apache.org <javascript:;>
>
>

An unusual (new?) multi term synonym bug?

2016-02-25 Thread Ryan Josal

I know, there's a ton of documentation about the query parser whitespace
issue, and there's also a fair bit of info on the positionLengthAttribute
issue, but I seem to have stumbled upon a new issue with multi term
synonyms: it doesn't seem to play well with a bunch of tokens in the same
position.

I have a synonym filter with this expansion:
side table,end table

I can see the synonym is applied when looking at the token stream output
for "side table".  Today I decided to throw an additional synonymFilter
immediately before that one with wordnet synonym expansions.  Wordnet
expectedly bloats the tokenstream, but all of a sudden the original end
table expansion doesn't get applied.  I see "side" followed by a bunch of
tokens in the same position, followed by a couple new tokens in the next
position, followed by "table" in the same token position, followed by some
more new tokens in the same position.  Since side is still adjacent to
table in token positions, I would expect the synonym to hit.  Is this a
known issue (what's the Jira)?  The impact seems significant.  Since
wordnet is so comprehensive, it's likely going to cause this issue with
most of my multi term synonyms.  Maybe the workaround is to apply multi
term synonyms first as best is possible, although I don't know if you have
that kind of control if all your synonyms are applied by a single
SynonymFilter.

Thanks,
Ryan

QueryReplacement token handling

2016-01-15 Thread Ryan Josal

I ran into an issue that seems to be undesirable behavior to me, but
considering how long query elevation has been around, maybe there are use
cases for it as is.

I set the QE analyzer to WhitespaceTokenizer -> LowercaseFilter.

When QE loads the xml file and it analyzes the queries into keys, it
appends tokens with no separators.  As a result "foo bar" and "foobar"
process into the same key "foobar".  The reason this is unexpected to me is
because the query "foobar" would not match "foobar" with that analyzer.  So
it breaks if I put both in my XML file.  So my thought would be to insert a
NUL char or something between the chars to detect the difference.  This
issue could potentially make two queries with very different meanings
become ambiguous: "rights now" and "right snow".

I think I may be able to work around this by using a charfilter alone with
keywordtokenizer.

Is this a bug, or desired?

Ryan

Re: JSON "fields" vs defaults

2015-12-16 Thread Ryan Josal

To respond to your last question Yonik, the "fl" in the query params
behaves the same as the "fl" in the JSON params block, so no bug there.
There is a difference though, between those and the top level "fields"
param, as Jack pointed out it appends to the defaults instead of overriding
them like "fl" does.  To me it seems natural for fields to behave like fl,
and I also agree that "filter" overriding defaults is a more questionable
use case.  But it's good to bring up to consider for consistency with fq.

On Tuesday, December 15, 2015, Jack Krupansky <jack.krupan...@gmail.com>
wrote:

> In a normal query multiple fl parameters are additive, but they
> collectively override whatever fl parameter(s) may have been specified in
> "defaults", right? I mean, that's why Solr has "appends" in addition to
> "defaults", right"?
>
> Ah, but I see in the JSON Request API doc that it says "Multi-valued
> elements like fields and filter are appended", seeming to imply that the
> "defaults" section will be treated as if it were "appends", it would seem,
> at least for how "fields" is treated.
>
> See:
> https://cwiki.apache.org/confluence/display/solr/JSON+Request+API
>
> Filter seems to make sense for this auto-appends mode, but fields/fl don't
> seem to benefit from appending rather than treating the defaults section in
> the traditional manner, I think.
>
> -- Jack Krupansky
>
> On Tue, Dec 15, 2015 at 9:06 PM, Yonik Seeley <ysee...@gmail.com
> <javascript:_e(%7B%7D,'cvml','ysee...@gmail.com');>> wrote:
>
>> Multiple "fl" parameters are additive, so it would make sense that
>> "fields" is also (for fl and field in the same request).  If that's
>> true for "fl" as a default and "fl" as a query param, then it seems
>> like that should be true for the other variants.
>>
>> If "fl" as a query param and "fl" in a JSON params block don't act the
>> same, that should probably be a bug?
>>
>> -Yonik
>>
>>
>> On Tue, Dec 15, 2015 at 7:55 PM, Jack Krupansky
>> <jack.krupan...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','jack.krupan...@gmail.com');>> wrote:
>> > Yonik? The doc is weak in this area. In fact, I see a comment on it from
>> > Cassandra directed to you to verify the JSON to parameter mapping. It
>> would
>> > be nice to have a clear statement of the semantics for JSON "fields"
>> > parameter and how it may or may not interact with the Solr fl parameter.
>> >
>> > -- Jack Krupansky
>> >
>> > On Thu, Dec 10, 2015 at 3:55 PM, Ryan Josal <rjo...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','rjo...@gmail.com');>> wrote:
>> >>
>> >> I didn't see a Jira open in this, so I wanted to see if it's expected.
>> If
>> >> you pass "fields":[...] in a SOLR JSON API request, it does not
>> override
>> >> what's the default in the handler config.  I had fl=* as a default, so
>> I saw
>> >> "fields" have no effect, while "params":{"fl":...} worked as expected.
>> >> After stepping through the debugger I noticed it was just appending
>> "fields"
>> >> at the end of everything else (including after solr config appends, if
>> it
>> >> makes a difference).
>> >>
>> >> If this is not expected I will create a Jira and maybe have time to
>> >> provide a patch.
>> >>
>> >> Ryan
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> <javascript:_e(%7B%7D,'cvml','dev-unsubscr...@lucene.apache.org');>
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> <javascript:_e(%7B%7D,'cvml','dev-h...@lucene.apache.org');>
>>
>>
>

JSON "fields" vs defaults

2015-12-10 Thread Ryan Josal

I didn't see a Jira open in this, so I wanted to see if it's expected. If
you pass "fields":[...] in a SOLR JSON API request, it does not override
what's the default in the handler config.  I had fl=* as a default, so I
saw "fields" have no effect, while "params":{"fl":...} worked as expected.
After stepping through the debugger I noticed it was just appending
"fields" at the end of everything else (including after solr config
appends, if it makes a difference).

If this is not expected I will create a Jira and maybe have time to provide
a patch.

Ryan

[jira] [Commented] (SOLR-8175) Wordbreak spellchecker throws IOOBE with Occur.MUST term

2015-11-30 Thread Ryan Josal (JIRA)


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

Ryan Josal commented on SOLR-8175:
--

Thanks for picking it up!

> Wordbreak spellchecker throws IOOBE with Occur.MUST term
> 
>
> Key: SOLR-8175
> URL: https://issues.apache.org/jira/browse/SOLR-8175
> Project: Solr
>  Issue Type: Bug
>    Reporter: Ryan Josal
>Assignee: James Dyer
> Attachments: solr8175.patch
>
>
> Using the WordBreakSolrSpellChecker, if a user queries for "+foo barbaz" and 
> "bar baz" is a suggestion for "barbaz", Solr will throw an 
> IndexOutOfBoundsException.  As a result, a server driven by user queries 
> might throw a certain percentage of HTTP 500 responses as users hit this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Custom Facet Scoring

2015-11-23 Thread Ryan Josal

+1 for making new facet sorts easier to implement.  I implemented an order
where the come back in order they are first seen in the doclist, but it
didn't come out very clean.  My approach was to extend FacetComponent, and
resort the facets by pulling them out of the results and putting them back
(after hacking facet.limit to get them all).  Some sort of plugin behavior
for it would be great, but I expect there are some complexities with it.
Anyway I'd be interested to hear about good ways to do this.

On Monday, November 23, 2015, Johannes Riedl <
johannes.ri...@uni-tuebingen.de> wrote:

> Hi all,
>
> we would like to add a custom sorting for facets in addition to the
> existing 'index' and 'count' that can be passed by a new value for the
> facet.sort parameter. The aim is to achieve a prefix based sorting for all
> the terms of a complex field with entries of the form  /  / 
> and sorting can be triggered by specifying something like
> facet.sort=mysortorder.
> We added a new searchComponent in solrconfig.xml that overrides the
> default "facet" component and currently use a skeleton FacetComponent in a
> different namespace. Is there a clean way to access and extend the
> dependencies the default FacetComponent uses - especially extending the
> FacetParam class by a new value FACET_SORT_MYSORTORDER - without having to
> touch the orginal Solr code?
>
> Thanks a lot for your information, best regards
>
> Johannes
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Custom Facet Scoring

2015-11-23 Thread Ryan Josal

I don't have the time to work on this issue right now, but I can definitely
help test it and port my facet sort to it if somebody works on it to see
how it works.

On Monday, November 23, 2015, Mikhail Khludnev <mkhlud...@griddynamics.com>
wrote:

> Hello Colleagues,
>
> I'll commit if you provide a patch, attached to the jira of course. But it
> should work with SolrCloud too.
>
> On Mon, Nov 23, 2015 at 9:05 PM, Ryan Josal <r...@josal.com
> <javascript:_e(%7B%7D,'cvml','r...@josal.com');>> wrote:
>
>> +1 for making new facet sorts easier to implement.  I implemented an
>> order where the come back in order they are first seen in the doclist, but
>> it didn't come out very clean.  My approach was to extend FacetComponent,
>> and resort the facets by pulling them out of the results and putting them
>> back (after hacking facet.limit to get them all).  Some sort of plugin
>> behavior for it would be great, but I expect there are some complexities
>> with it.  Anyway I'd be interested to hear about good ways to do this.
>>
>>
>> On Monday, November 23, 2015, Johannes Riedl <
>> johannes.ri...@uni-tuebingen.de
>> <javascript:_e(%7B%7D,'cvml','johannes.ri...@uni-tuebingen.de');>> wrote:
>>
>>> Hi all,
>>>
>>> we would like to add a custom sorting for facets in addition to the
>>> existing 'index' and 'count' that can be passed by a new value for the
>>> facet.sort parameter. The aim is to achieve a prefix based sorting for all
>>> the terms of a complex field with entries of the form  /  / 
>>> and sorting can be triggered by specifying something like
>>> facet.sort=mysortorder.
>>> We added a new searchComponent in solrconfig.xml that overrides the
>>> default "facet" component and currently use a skeleton FacetComponent in a
>>> different namespace. Is there a clean way to access and extend the
>>> dependencies the default FacetComponent uses - especially extending the
>>> FacetParam class by a new value FACET_SORT_MYSORTORDER - without having to
>>> touch the orginal Solr code?
>>>
>>> Thanks a lot for your information, best regards
>>>
>>> Johannes
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
>
> <http://www.griddynamics.com>
> <javascript:_e(%7B%7D,'cvml','mkhlud...@griddynamics.com');>
>

[jira] [Commented] (SOLR-8175) Wordbreak spellchecker throws IOOBE with Occur.MUST term

2015-10-26 Thread Ryan Josal (JIRA)


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

Ryan Josal commented on SOLR-8175:
--

BTW, this patch passes "ant test" and "ant precommit".

> Wordbreak spellchecker throws IOOBE with Occur.MUST term
> 
>
> Key: SOLR-8175
> URL: https://issues.apache.org/jira/browse/SOLR-8175
> Project: Solr
>  Issue Type: Bug
>Reporter: Ryan Josal
> Attachments: solr8175.patch
>
>
> Using the WordBreakSolrSpellChecker, if a user queries for "+foo barbaz" and 
> "bar baz" is a suggestion for "barbaz", Solr will throw an 
> IndexOutOfBoundsException.  As a result, a server driven by user queries 
> might throw a certain percentage of HTTP 500 responses as users hit this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-8175) Wordbreak spellchecker throws IOOBE with Occur.MUST term

2015-10-20 Thread Ryan Josal (JIRA)

Ryan Josal created SOLR-8175:


 Summary: Wordbreak spellchecker throws IOOBE with Occur.MUST term
 Key: SOLR-8175
 URL: https://issues.apache.org/jira/browse/SOLR-8175
 Project: Solr
  Issue Type: Bug
Reporter: Ryan Josal


Using the WordBreakSolrSpellChecker, if a user queries for "+foo barbaz" and 
"bar baz" is a suggestion for "barbaz", Solr will throw an 
IndexOutOfBoundsException.  As a result, a server driven by user queries might 
throw a certain percentage of HTTP 500 responses as users hit this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8175) Wordbreak spellchecker throws IOOBE with Occur.MUST term

2015-10-20 Thread Ryan Josal (JIRA)


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

Ryan Josal updated SOLR-8175:
-
Attachment: solr8175.patch

Uploaded solr8175.patch, which includes an updated unit test which would throw 
the exception without the fix.  Let me know what else I can do to help.

> Wordbreak spellchecker throws IOOBE with Occur.MUST term
> 
>
> Key: SOLR-8175
> URL: https://issues.apache.org/jira/browse/SOLR-8175
> Project: Solr
>  Issue Type: Bug
>    Reporter: Ryan Josal
> Attachments: solr8175.patch
>
>
> Using the WordBreakSolrSpellChecker, if a user queries for "+foo barbaz" and 
> "bar baz" is a suggestion for "barbaz", Solr will throw an 
> IndexOutOfBoundsException.  As a result, a server driven by user queries 
> might throw a certain percentage of HTTP 500 responses as users hit this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6842) No way to limit the fields cached in memory and leads to OOM when there are thousand of fields (thousands)

2015-10-19 Thread Ryan Josal (JIRA)


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

Ryan Josal commented on LUCENE-6842:


FWIW, I have seen an OOME due to a large number of fields before.  I had an 
index with millions of documents and I wanted to experiment with ways to reduce 
full indexing time, and there was a way to reorganize the data that would 
reduce the number of docs by a factor of 2000 by adding 2000 fields (using a 
solr dynamic multivalued String with ~2-3 values on average).  The idea was 
quickly canned after seeing an OOME during full indexing.  This piece of data 
we may eventually move out of Lucene and into a datastore more suited like 
Cassandra.

> No way to limit the fields cached in memory and leads to OOM when there are 
> thousand of fields (thousands)
> --
>
> Key: LUCENE-6842
> URL: https://issues.apache.org/jira/browse/LUCENE-6842
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 4.6.1
> Environment: Linux, openjdk 1.6.x
>Reporter: Bala Kolla
> Attachments: HistogramOfHeapUsage.png
>
>
> I am opening this defect to get some guidance on how to handle a case of 
> server running out of memory and it seems like it's something to do how we 
> index. But want to know if there is anyway to reduce the impact of this on 
> memory usage before we look into the way of reducing the number of fields. 
> Basically we have many thousands of fields being indexed and it's causing a 
> large amount of memory being used (25GB) and eventually leading to 
> application to hang and force us to restart every few minutes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Forking Lucene/Solr

2015-10-16 Thread Ryan Josal

Hi guys, new subscriber here, so as a bit of an intro, I'm a long time user
of Lucene/Solr from Lucene 1.x.  I've plugged everything pluggable and am
quite familiar with the core Lucene and solr code.  Looks like I should
have sent this to dev instead of solr-user:

I'd like to get your tips on how to run a Solr fork at my company.  I know
Yonik has a "heliosearch" fork, and I'm sure many others have a fork.
There have been times where I want to add features to an existing core
plugin, and subclassing isn't possible so I end up copying the source code
into my repo, then using some crazy reflection to get it to work.
Sometimes there's a little bug in something and I have to do the same
thing.  Sometimes there's something I want to do deeper in core Solr code
that isn't pluggable and I end up doing an interesting workaround.
Sometimes I want to apply a patch from JIRA.  I also think forking solr
will make it easier for me to contribute patches back.  So here are my
questions:

*) how do I properly fork it outside of github to my own company's git
system?
*) how do I pull new changes?  I think I would expect to sync new changes
when there is a new public release.  What branches do I need to work
with/on?
*) how do I test my changes?  What part of the test suites do I run for
what changes?
*) how do I build a new version when I'm ready to go to prod?  This is
slightly more unclear to me now that it isn't just a war.

Thanks,
Ryan

Re: Forking Lucene/Solr

2015-10-16 Thread Ryan Josal

Thanks a lot for the info Shawn.  HowToContribute also had a ton of good
info.  A couple other questions:

*) what version of Java is best to run the test suite with?
*) What branch is best to create a patch from so that it doesn't cause
conflict for who applies it?  I guess if it's from the 5.3 branch
and I mark it as 5.3.0 in Jira that will help?
*) After I log a Jira and submit a patch, what next to make it get noticed,
if anything?

Ryan

On Friday, October 16, 2015, Shawn Heisey <apa...@elyograg.org> wrote:

> Replying on dev, but with the text from solr-user, since I wrote most of
> this before you sent to dev.
>
> General info:  The canonical and official repository for Lucene/Solr is
> in SVN.  There are two public git mirrors.  One at git.apache.org, one
> is at github.
>
> On 10/16/2015 11:07 AM, Ryan Josal wrote:
> > *) how do I properly fork it outside of github to my own company's git
> > system?
>
> I am not familiar with how to do this.  I imagine that there are ways to
> use the .git directory in a cloned repository to put a project into a
> local git server, or maybe use the github repo directly to populate your
> own server.  Once you figure out exactly what to do, here's where
> Lucene/Solr lives on github:
>
> https://github.com/apache/lucene-solr
>
> Here's Apache's git mirror:
>
> git://git.apache.org/lucene-solr.git
>
> You could simply maintain a fork on github in your own github account,
> and do whatever is required there to keep it current with the apache
> github repo.
>
> https://help.github.com/articles/fork-a-repo/
>
> > *) how do I pull new changes?  I think I would expect to sync new changes
> > when there is a new public release.  What branches do I need to work
> > with/on?
>
> If you want to closely track what's going into the next release, you
> want the stable branch, which is currently branch_5x.  Eventually
> branch_5x will disappear and branch_6x will be created.  There is a
> branch for each minor version, and a tag for each release.
>
> https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x/
> https://svn.apache.org/repos/asf/lucene/dev/branches/
> https://svn.apache.org/repos/asf/lucene/dev/tags/
>
> Bleeding edge development happens in trunk.  Most commits that happen on
> trunk are merged to the stable branch, usually a short time after the
> trunk commit, but some changes are trunk-only.
>
> https://svn.apache.org/repos/asf/lucene/dev/trunk/
>
> The git and github mirrors should have all branches and tags that live
> in SVN.
>
> > *) how do I test my changes?  What part of the test suites do I run for
> > what changes?
>
> The build system has extensive testing capability built in.  At the top
> level of your local working copy, type "ant test-help" for some
> comprehensive info.  Exactly what tests to run will depend on the nature
> of the change you've made, and whether you've built any new tests
> specifically for your change.  Running all of the tests (maybe after
> changing to the solr directory) is prudent in most situations.
>
> > *) how do I build a new version when I'm ready to go to prod?  This is
> > slightly more unclear to me now that it isn't just a war.
>
> Change to the solr directory and type "ant server" to get a runnable
> server, complete with start scripts, right in the local working copy.
> Type "ant package" to get .tgz and .zip files that are similar to what
> you actually download from the Solr website.
>
> The following wiki page has some additional information:
>
> http://wiki.apache.org/solr/HowToContribute
>
> In response to your latest message on the solr-user thread:
>
> You don't need to fork Solr to maintain local patches.  You can check
> out branch_5x (and maybe the minor version branch) from svn or git and
> just do "svn up" or "git pull" to download the latest from upstream.  If
> there are any conflicts between your changes and upstream work, you'll
> need to resolve those.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org <javascript:;>
> For additional commands, e-mail: dev-h...@lucene.apache.org <javascript:;>
>
>

[jira] [Created] (SOLR-7953) BaseEditorialTransformer (elevated) doesn't work with LazyField

2015-08-20 Thread Ryan Josal (JIRA)

Ryan Josal created SOLR-7953:


 Summary: BaseEditorialTransformer (elevated) doesn't work with 
LazyField
 Key: SOLR-7953
 URL: https://issues.apache.org/jira/browse/SOLR-7953
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.2, 4.10.2
Reporter: Ryan Josal


When using the QueryElevationComponent, using the [elevated] docTransformer 
doesn't always work.  In the case the document is a LazyDocument, 
BaseEditorialTransformer#getKey will return the LazyField.toString() which is 
Object#toString() which of course isn't going to match any of the uniqueKeys.  
The fix is to change getKey to check instanceof IndexableField instead of just 
Field.  I'm not sure the impact of this bug because I don't know how often 
LazyDocuments get used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6234) Scoring modes for query time join

2015-07-10 Thread Ryan Josal (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14622449#comment-14622449
 ] 

Ryan Josal commented on SOLR-6234:
--

It seems like the parser can find out if it's multivalued for itself by 
checking the otherCore's Schema.

I think multivalued to field should be a separate ticket since it is not a 
feature of the qparser

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Timothy Potter
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, 
 otherHandler.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-6234) Scoring modes for query time join

2015-07-10 Thread Ryan Josal (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14622449#comment-14622449
 ] 

Ryan Josal edited comment on SOLR-6234 at 7/10/15 3:22 PM:
---

It seems like the parser can find out if it's multivalued for itself by 
checking the otherCore's Schema.

I think multivalued to field on the current core should be a separate ticket 
since it is not a feature of the qparser, it's an improvement to JoinUtil.  I 
can have a patch for that later; I have it working.


was (Author: rjosal):
It seems like the parser can find out if it's multivalued for itself by 
checking the otherCore's Schema.

I think multivalued to field should be a separate ticket since it is not a 
feature of the qparser

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Timothy Potter
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, 
 otherHandler.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6234) Scoring modes for query time join

2015-07-09 Thread Ryan Josal (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14621658#comment-14621658
 ] 

Ryan Josal commented on SOLR-6234:
--

That makes a lot of sense David, I would prefer this as it would reduce 
confusion, some similar code, and make implementation changes in the future 
more flexible.

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Timothy Potter
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, 
 otherHandler.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6234) Scoring modes for query time join

2015-07-08 Thread Ryan Josal (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14619385#comment-14619385
 ] 

Ryan Josal commented on SOLR-6234:
--

That will be great Tim! For my personal use case, I added a feature to the 
qparser that, after constructing the LocalSolrQueryRequest, would apply the 
handler config (defaults, appends, invariants) from the otherCore (say 
/select handler) to the request so that in a nutshell your other query could 
be a simple string and it would follow whatever edismax rules you had 
configured for the other core.  That instead of the more strict db style lucene 
query syntax.  If there's interest I am happy to share the patch.

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Timothy Potter
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-6234) Scoring modes for query time join

2015-07-08 Thread Ryan Josal (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14619521#comment-14619521
]

Ryan Josal edited comment on SOLR-6234 at 7/8/15 10:47 PM:
---

I've attached otherHandler.patch, which is a patch on top of the existing
ScoreJoinQParserPlugin.java from the Dec 14 patch, which shows changes to add a
feature where the user can supply handler=/select (for example) in localparams,
to apply the config from the handler in the other core. You'll notice that the
request is built from localParams instead of params so that whatever your
current core params are don't override the other core configured params. If
this breaks something, it could be changed to only do that when the handler
localParam is present. This patch is quick and dirty because it uses
reflection to get the defaults,appends,invariants config from the
BaseRequestHandler class. Really, the access level of those variables should
change, or the method should be moved there.

Personally I'm using this feature to join my deals core with my products core
as the othercore, and I wanted it to do a regular search against the products
core. This approach could actually be used in the \!join qparser too. If this
patch is useful for somebody, great!

was (Author: rjosal):
I've attached otherHandler.patch, which is a patch on top of the existing
ScoreJoinQParserPlugin.java from the Dec 14 patch, which shows changes to add a
feature where the user can supply handler=/select (for example) in localparams,
to apply the config from the handler in the other core. You'll notice that the
request is built from localParams instead of params so that whatever your
current core params are don't override the other core configured params. If
this breaks something, it could be changed to only do that when the handler
localParam is present. This patch is quick and dirty because it uses
reflection to get the defaults,appends,invariants config from the
BaseRequestHandler class. Really, the access level of those variables should
change, or the method should be moved there.

Personally I'm using this feature to join my deals core with my products core
as the othercore, and I wanted it to do a regular search against the products
core. This approach could actually be used in the !join qparser too. If this
patch is useful for somebody, great!

Scoring modes for query time join
--

Key: SOLR-6234
URL: https://issues.apache.org/jira/browse/SOLR-6234
Project: Solr
Issue Type: New Feature
Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Timothy Potter
Labels: features, patch, test
Fix For: 5.3

Attachments: SOLR-6234.patch, SOLR-6234.patch, otherHandler.patch

it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath.
It supports:
- {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
- {{score=none}} is *default*, eg if you *omit* this localparam
- supports {{b=100}} param to pass {{Query.setBoost()}}.
- {{multiVals=true|false}} is introduced
- there is a test coverage for cross core join case.
- so far it joins string and multivalue string fields (Sorted, SortedSet,
Binary), but not Numerics DVs. follow-up LUCENE-5868
-there was a bug in cross core join, however there is a workaround for it-
it's fixed in Dec'14 patch.
Note: the development of this patch was sponsored by an anonymous contributor
and approved for release under Apache License.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6234) Scoring modes for query time join

2015-07-08 Thread Ryan Josal (JIRA)


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

Ryan Josal updated SOLR-6234:
-
Attachment: otherHandler.patch

I've attached otherHandler.patch, which is a patch on top of the existing 
ScoreJoinQParserPlugin.java from the Dec 14 patch, which shows changes to add a 
feature where the user can supply handler=/select (for example) in localparams, 
to apply the config from the handler in the other core.  You'll notice that the 
request is built from localParams instead of params so that whatever your 
current core params are don't override the other core configured params.  If 
this breaks something, it could be changed to only do that when the handler 
localParam is present.  This patch is quick and dirty because it uses 
reflection to get the defaults,appends,invariants config from the 
BaseRequestHandler class.  Really, the access level of those variables should 
change, or the method should be moved there.

Personally I'm using this feature to join my deals core with my products core 
as the othercore, and I wanted it to do a regular search against the products 
core.  This approach could actually be used in the !join qparser too.  If this 
patch is useful for somebody, great!

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Timothy Potter
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch, otherHandler.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-7726) CodecFactory plugins are double informed of SolrCore

2015-06-26 Thread Ryan Josal (JIRA)

Ryan Josal created SOLR-7726:


 Summary: CodecFactory plugins are double informed of SolrCore
 Key: SOLR-7726
 URL: https://issues.apache.org/jira/browse/SOLR-7726
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.2.1, 5.0, 4.10
Reporter: Ryan Josal
Priority: Minor


During the SolrCore#initCodec initialization phase, it initializes the the 
CodecFactory by using ResourceLoader#newInstance, which will call 
inform(SolrCore), and then a few lines later it calls inform again.  The 
SchemaCodecFactory, for example, does not break due to this because it has no 
effect to inform it multiple times.  But any extensions or other CodecFactories 
may need to work around this by checking for a second inform call to prevent 
errors or just from running potentially complex init code twice.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6234) Scoring modes for query time join

2015-06-15 Thread Ryan Josal (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586444#comment-14586444
 ] 

Ryan Josal commented on SOLR-6234:
--

I've been using this for a few days now, and here are my comments:
*) it's more functionally useful to have the scores returned with this than the 
!join parser.
*) basing it off JoinUtil is a clean solution that centralizes this type of 
logic.
*) That being said, scorejoin has performed worse than !join in my tests, 
usually almost twice as slow.  It's not an exhaustive test by any means, just 
an observation.  So it doesn't seem fit to replace !join as it is, although it 
does feel like this is the right direction to be going for joins.
*) JoinUtil does not currently support multivalue fields for the to index.  
It chooses one of the matching values instead of applying the ScoreMode for all 
matching documents.  It's a fairly small change to TermsIncludingScoreQuery to 
add this feature.

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6234) Scoring modes for query time join

2015-06-15 Thread Ryan Josal (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586457#comment-14586457
 ] 

Ryan Josal commented on SOLR-6234:
--

[~neerajlajpal], glad you got it working.  There might be a caution with using 
!scorejoin this way.  The scores coming back from !scorejoin are from the query 
to the fromIndex, and so they're not really related to the score coming from 
the important_category matches.  The matches from the scorejoin might have a 
really high max score, while the matches from the important_category might have 
a really low max_score, in a relative sense.  Or vice versa.  I think this use 
case is workable but it's something to keep in mind.

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-6234) Scoring modes for query time join

2015-06-12 Thread Ryan Josal (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583437#comment-14583437
 ] 

Ryan Josal edited comment on SOLR-6234 at 6/12/15 2:15 PM:
---

[~neerajlajpal] Solr parses the value of q with a single parser, which will be 
whatever your defType is.  In order to do something like that you can use 
nested queries:
{noformat}
important_category:322^4 _query_:{!scorejoin from=_root_ to=id score=avg 
multiVals=false v=$jq}jq=(brandid:1398^4 OR brandid:237^4.5)
{noformat}


was (Author: rjosal):
[~neerajlajpal] Solr parses the value of q with a single parser, which will be 
whatever your defType is.  In order to do something like that you can use 
nested queries:

important_category:322^4 _query_:{!scorejoin from=_root_ to=id score=avg 
multiVals=false v=$jq}jq=(brandid:1398^4 OR brandid:237^4.5) 

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6234) Scoring modes for query time join

2015-06-12 Thread Ryan Josal (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583437#comment-14583437
 ] 

Ryan Josal commented on SOLR-6234:
--

[~neerajlajpal] Solr parses the value of q with a single parser, which will be 
whatever your defType is.  In order to do something like that you can use 
nested queries:

important_category:322^4 _query_:{!scorejoin from=_root_ to=id score=avg 
multiVals=false}

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-6234) Scoring modes for query time join

2015-06-12 Thread Ryan Josal (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583437#comment-14583437
 ] 

Ryan Josal edited comment on SOLR-6234 at 6/12/15 2:13 PM:
---

[~neerajlajpal] Solr parses the value of q with a single parser, which will be 
whatever your defType is.  In order to do something like that you can use 
nested queries:

important_category:322^4 _query_:{!scorejoin from=_root_ to=id score=avg 
multiVals=false v=$jq}jq=(brandid:1398^4 OR brandid:237^4.5) 


was (Author: rjosal):
[~neerajlajpal] Solr parses the value of q with a single parser, which will be 
whatever your defType is.  In order to do something like that you can use 
nested queries:

important_category:322^4 _query_:{!scorejoin from=_root_ to=id score=avg 
multiVals=false}

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6234) Scoring modes for query time join

2015-06-09 Thread Ryan Josal (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579608#comment-14579608
 ] 

Ryan Josal commented on SOLR-6234:
--

This is awesome, the normal !join qparser is mainly only good for fq, but with 
scoring, this is good as a q or subquery.

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 4.10.3, Trunk
Reporter: Mikhail Khludnev
  Labels: features, patch, test
 Fix For: 5.0, Trunk

 Attachments: SOLR-6234.patch, SOLR-6234.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-7152) Cannot override default rq with no rankquery

2015-02-24 Thread Ryan Josal (JIRA)

Ryan Josal created SOLR-7152:


 Summary: Cannot override default rq with no rankquery
 Key: SOLR-7152
 URL: https://issues.apache.org/jira/browse/SOLR-7152
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.10.2
Reporter: Ryan Josal
Priority: Minor


In your update handler, if you put a default parameter for rq=, you cannot 
override it with no rankquery.  You can try passing rq=, which will override 
the default value to an empty string, but the QueryComponent will complain that 
it isn't a valid RankQuery.  Looks like a simple fix to not only check for null 
but also isEmpty.

Possible workaround for now:
Check for empty rq string in the prepare method of an earlier search component 
and remove it.  This isn't a workable solution though if your rankquery param 
uses a {!switch ...} that can set to empty in a default case for example.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-3015) QParserPlugins can not be SolrCoreAware

2014-09-24 Thread Ryan Josal (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146798#comment-14146798
 ] 

Ryan Josal commented on SOLR-3015:
--

I ran into a problem with this today.  I have a QParserPlugin that would like 
to get some info from the index at startup, but without having it 
SolrCoreAware, I can't getSolrConfig().getDataDir().  Having run into the 
circular init problem before in the past, I understand the motive to reduce 
risk of problems.  On a related note, I have a SearchComponent that wants to 
(but isn't allow to) be ResourceLoaderAware so it can load some data file from 
the config dir.  Interestingly, QParserPlugin CAN be ResourceLoaderAware.  At 
least with that one I can put the instanceDir in my config because that 
property is automatically populated, but I can't work around the data.dir 
problem that way because it is left blank.  My personal feeling is that it 
would be great if these artificial limitations could be safely lifted somehow.

 QParserPlugins can not be SolrCoreAware
 ---

 Key: SOLR-3015
 URL: https://issues.apache.org/jira/browse/SOLR-3015
 Project: Solr
  Issue Type: New Feature
Reporter: Karl Wright
  Labels: closehook, qparserplugin, solrcoreaware
 Fix For: 3.6, 4.0-ALPHA

 Attachments: SOLR-3015.patch


 QParserPlugin cannot be made SolrCoreAware:
 {code}
 [junit] org.apache.solr.common.SolrException: Invalid 'Aware' object: 
 org.apache.solr.mcf.ManifoldCFQParserPlugin@18941f7 -- 
 org.apache.solr.util.plugin.SolrCoreAware must be an instance of: 
 [org.apache.solr.request.SolrRequestHandler]
 [org.apache.solr.response.QueryResponseWriter] 
 [org.apache.solr.handler.component.SearchComponent] 
 [org.apache.solr.update.processor.UpdateRequestProcessorFactory] 
 [org.apache.solr.handler.component.ShardHandlerFactory]
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6396) Allow the name of core.properties file used in discovery to be specified by an environment variable

2014-08-21 Thread Ryan Josal (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105662#comment-14105662
 ] 

Ryan Josal commented on SOLR-6396:
--

Confirmed it does work the way Hoss suggests; using property expansion in 
core.properties meets the need.

 Allow the name of core.properties file used in discovery to be specified by 
 an environment variable
 ---

 Key: SOLR-6396
 URL: https://issues.apache.org/jira/browse/SOLR-6396
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.9, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor

 This was brought up on the user's list. I haven't thought this through, but 
 it seems reasonable.
 This has some interesting implications in the core rename case, i.e. The 
 unloaded props file will have the different name as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3083) all JMX Mbeans are identified as java.lang.String even if numeric

2012-12-17 Thread Ryan Josal (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13534434#comment-13534434
 ] 

Ryan Josal commented on SOLR-3083:
--

I applied this patch to Solr 3.6 - I noticed it missed the hitratio mbean 
attribute from [Fast]LRUCache.  Looks like that attribute is actually 
calculated into a String and so would have to be fixed by itself.  I'm not sure 
if this is still present in the latest builds though.

 all JMX Mbeans are identified as java.lang.String even if numeric
 -

 Key: SOLR-3083
 URL: https://issues.apache.org/jira/browse/SOLR-3083
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 4.0-ALPHA
Reporter: Tagged Siteops
Assignee: Ryan McKinley
Priority: Minor
  Labels: interoperability,, jmx, monitoring, statistics
 Fix For: 4.0-ALPHA

 Attachments: Screen shot 2012-01-31 at 2.19.06 PM.png, 
 SOLR-3083-Made-JMX-Mbean-information-use-numeric-typ.patch


 When trying to monitor our Solr instances with JMXtrans 
 (https://github.com/lookfirst/jmxtrans), we discovered that all the Mbeans 
 were identifying themselves as java.lang.String.   This breaks the 
 GangliaWriter in JMXtrans because the software decides it's a string instead 
 of a numeric values and you can't graph a string.   Other software we are 
 monitoring with JMXtrans (e.g. Kafka) correctly identify their numeric values 
 as numbers (doubles in this case).
 For example, avgTimePerRequest in Solr is identified as a string which makes 
 no sense.  This behavior makes Solr less interoperable with the rest of the 
 Java ecosystem.
 The problem code is in JmxMonitoredMap.java
 NamedList dynamicStats = infoBean.getStatistics();
 if (dynamicStats != null) {
   for (int i = 0; i  dynamicStats.size(); i++) {
 String name = dynamicStats.getName(i);
 if (!staticStats.contains(name))
   attrInfoList.add(new MBeanAttributeInfo(dynamicStats.getName(i),
   String.class.getName(), null, true, false, false));
   }
 I will try to attach a screenshot. 
 Thanks for Solr!  We use the heck out of it, it's awesome.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3866) CoreAdmin SWAP and RENAME need fixed/defined when using SolrCloud

2012-11-13 Thread Ryan Josal (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496352#comment-13496352
 ] 

Ryan Josal commented on SOLR-3866:
--

The use case I (and it appears the author of the instigating thread for this 
issue: http://osdir.com/ml/solr-user.lucene.apache.org/2012-09/msg00893.html) 
have for CoreAdmin SWAP is to support a backup core (on deck core) that I can 
rebuild the index from scratch on.

 CoreAdmin SWAP and RENAME need fixed/defined when using SolrCloud
 -

 Key: SOLR-3866
 URL: https://issues.apache.org/jira/browse/SOLR-3866
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0
Reporter: Hoss Man

 We need to define what the expected behavior of using the CoreAdminHandler's 
 SWAP and RENAME commands is if you are running in SolrCloud mode.
 At the moment, it seems to introduce a disconnect between which collection 
 the SolrCore thinks it's a part of (and what appears in the persisted 
 solr.xml) vs what collection ZooKeeper thinks the SolrCore(s) that were 
 swaped/renamed are a part of.  We should either fix this, or document it if 
 it as actually consistent and intentional for low level controls, or disable 
 commands like SWAP/RENAME in SolrCloud mode
 https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201209.mbox/%3CCALB4QrP2GZAwLeAiy%3DfcmOLYbc5r0i9Tp1DquyPS8mMJPwCgnw%40mail.gmail.com%3E

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

44 matches

Mail list logo