Re: Welcome Tim Potter as Lucene/Solr committer

2014-04-08 Thread Noble Paul നോബിള്‍ नोब्ळ् 
Welcome Tim,








On Tue, Apr 8, 2014 at 3:04 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> Welcome Tim!
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Tue, Apr 8, 2014 at 12:40 AM, Steve Rowe  wrote:
> > I'm pleased to announce that Tim Potter has accepted the PMC's
> invitation to become a committer.
> >
> > Tim, it's tradition that you introduce yourself with a brief bio.
> >
> > Once your account has been created - could take a few days - you'll be
> able to add yourself to the committers section of the Who We Are page on
> the website:  (use the ASF CMS
> bookmarklet at the bottom of the page here: <
> https://cms.apache.org/#bookmark> - more info here <
> http://www.apache.org/dev/cms.html>).
> >
> > Check out the ASF dev page - lots of useful links: <
> http://www.apache.org/dev/>.
> >
> > Congratulations and welcome!
> >
> > Steve
> > -
> > 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
>
>


-- 
-
Noble Paul

Re: Solr Ref Guide vs. Wiki

2014-04-07 Thread Noble Paul നോബിള്‍ नोब्ळ् 
How do we plan to redirect? If I reached a specific page in the wiki after
searching in Google and now tog forward me to the home page of cwiki ?
Isn't it better to give links at the top of the page to relevant sections
in cwiki (as much add possible)
I'm +1 for locking the old wiki down
On 7 Apr 2014 13:13, "Toke Eskildsen"  wrote:

> On Mon, 2014-04-07 at 08:35 +0200, Shalin Shekhar Mangar wrote:
> > On Mon, Apr 7, 2014 at 9:58 AM, Alexandre Rafalovitch
> >  wrote:
> > > 5. Do something about JavaDocs polluting Google Index. At minimum,
> > > create /latest/ as a stable URL path and have it very Google visible.
> > > Make the rest of the versions in archive, non-crawlable. There is a
> > > lot more that can be done here, but probably not as part of this
> > > cleanup (see my older post about it)
> >
> > I am not sure if that is a big problem for Solr. How many people look
> > at our javadocs? How many of us actually write them?
>
> Non-existing JavaDocs is a problem in itself, but even with the current
> state, I expect to be able to find the current JavaDocs (i.e. for the
> latest stable release) through a generic search on the Internet.
>
> If the result is a page with just the auto-generated stuff and no real
> explanations, then I at least know that I can stop searching.
>
> - Toke Eskildsen, State and University Library, Denmark
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once officially released)

2014-03-10 Thread Noble Paul നോബിള്‍ नोब्ळ् 
Solr/Lucene 4.8 -> Java 7
+1

I'm not too sure about moving trunk to java 8 . Let's keep it at java 7 and
make a call when we are closer to Lecene-Solr 5.0. Organizations move to
newer versions of java very slowly.


On Mon, Mar 10, 2014 at 6:30 PM, Uwe Schindler  wrote:

> Hi Robert,
>
> > the vote must be held open for 72 hours. I haven't even had a chance to
> > formulate my VOTE+reasoning yet, and i dont agree with this crap here.
>
> Indeed, there is no need to hurry! I just wanted more discussions coming
> in.
> The merges I prepared already are stable and pass all tests, smokers,...
> So no problem to wait 2 more days, it is not urgent to commit my branch_4x
> checkout.
>
> As said in the thread already, I expected the reaction from our
> company-users/company-committers. I disagree, too, but it looks like more
> people are against this and that won't change anymore.
> I agree with you: "trunk" is our development branch, I see no problem with
> making it Java 8 only. From the other issue, we have no important news to
> actually release this as 5.0 soon, so we can for sure play with it for long
> time. To me it looks like some of our committers have forks off trunk they
> want to sell to their customers.
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> > -Original Message-
> > From: Robert Muir [mailto:rcm...@gmail.com]
> > Sent: Monday, March 10, 2014 1:34 PM
> > To: dev@lucene.apache.org
> > Subject: Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in
> trunk
> > (once officially released)
> >
> > On Mon, Mar 10, 2014 at 5:46 AM, Uwe Schindler 
> > wrote:
> > > Hi,
> > >
> > > it looks like we all agree on the same:
> > >
> > > +1 for Lucene 4.x requirement on Java 7.
> > > -1 to not change trunk (keep it on Java 7,too).
> > >
> > > I will keep this vote open until this evening, but I don't expect any
> other
> > change. Indeed, there are no real technical reasons to not move.
> >
> > the vote must be held open for 72 hours. I haven't even had a chance to
> > formulate my VOTE+reasoning yet, and i dont agree with this crap here.
> >
> > -
> > 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
>
>


-- 
-
Noble Paul

Re: [VOTE] Lucene / Solr 4.7.0 RC4

2014-02-24 Thread Noble Paul നോബിള്‍ नोब्ळ् 
We should switch to not storing the scheme with base_url or how about
completely relying on nodename (and eliminating base_url eventually)


On Mon, Feb 24, 2014 at 2:25 AM, Mark Miller  wrote:

> No, it’s a different issue than " urlScheme property should be
> whitelisted”. The issue is that you can't setup a cluster with http and
> then later switch it to https without some manual workaround steps. You can
> create a fresh cluster with SSL with no manual workaround steps though.
>
> - Mark
>
> http://about.me/markrmiller
>
> On Feb 23, 2014, at 2:04 PM, Simon Willnauer 
> wrote:
>
> > mark, I am a bit confused - the issue you are mentioning here is not
> > fixed yet, right? It's not part of
> >
> > r1570798 | noble | 2014-02-22 07:50:02 +0100 (Sat, 22 Feb 2014) | 1 line
> > SOLR-3854 urlScheme property should be whitelisted
> >
> > ?
> >
> > On Sat, Feb 22, 2014 at 10:44 PM, Mark Miller 
> wrote:
> >> I have simliar feelings to the white list issue (which looks like it
> did make it in). You can still use the feature, it’s a new feature and so
> no regression, and so I’d vote to document the limitation around migrating
> from http to https (you have to start with https without manual work) and
> address this in a 4.7.1 or 4.8.
> >>
> >> I do think its something we should address if a more serious issue
> causes a respin - it’s a straightforward fix - we should always be using
> the coreNodeName to match state - never the url or address.
> >>
> >> - Mark
> >>
> >> http://about.me/markrmiller
> >>
> >> On Feb 22, 2014, at 8:19 AM, Steve Davids  wrote:
> >>
> >>> Hate to bring this up, though it must have gotten lost in the shuffle.
> When migrating from http -> https in SOLR-3854 shards aren’t obtaining
> their old core node name and resuming their prior assignments. This is
> because the base_url is being compared instead (which changed) instead of
> something more constant like the node_name. A patch was attached yesterday:
> https://issues.apache.org/jira/browse/SOLR-3854?focusedCommentId=13908014&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13908014.
> It is a quick patch that hasn’t really been tested yet, will do so later
> this evening.
> >>>
> >>> The current work-around would be that if clients want to migrate to
> https, they will need to shutdown their servers, migrate the cluster
> state’s base_url from http to https and bring the server back up.
> >>>
> >>> -Steve
> >>>
> >>> On Feb 22, 2014, at 5:46 AM, Simon Willnauer <
> simon.willna...@gmail.com> wrote:
> >>>
>  Please vote for the forth Release Candidate for Lucene/Solr 4.7.0
> 
>  you can download it here:
> 
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC4-rev1570806/
>  or run the smoke tester directly with this commandline (don't forget
>  to set JAVA6_HOME etc.):
> 
>  $ python3.2 -u dev-tools/scripts/smokeTestRelease.py
> 
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC4-rev1570806/
>  1570806 4.7.0 /tmp/smoke_test_4_7
> 
>  Smoketester said: SUCCESS!
> 
>  here is my +1
> 
>  This RC includes the following fixes compared to RC3
> 
> 
> 
>  r1570798 | noble | 2014-02-22 07:50:02 +0100 (Sat, 22 Feb 2014) | 1
> line
>  SOLR-3854 urlScheme property should be whitelisted
> 
> 
>  r1570795 | noble | 2014-02-22 07:42:22 +0100 (Sat, 22 Feb 2014) | 1
> line
>  SOLR-5762 broke backward compatibility of Javabin format
> 
> 
>  r1570772 | sarowe | 2014-02-22 01:49:11 +0100 (Sat, 22 Feb 2014) | 1
> line
>  Fix CHANGES.txt to reflect the twisted evolution and current state of
>  the Admin UI "Files" conf directory File Browser.  (merged branch_4x
>  r1570771)
> 
> 
>  r1570741 | sarowe | 2014-02-21 23:51:47 +0100 (Fri, 21 Feb 2014) | 1
> line
>  LUCENE-5465: Solr Contrib map-reduce breaks Manifest of all other JAR
>  files by adding a broken Main-Class attribute (merged trunk r1570738)
> 
> 
>  r1570628 | sarowe | 2014-02-21 17:38:59 +0100 (Fri, 21 Feb 2014) | 1
> line
>  SOLR-5729: intellij config (merge trunk r1570626)
> 
> 
>  r1570576 | mvg | 2014-02-21 15:06:41 +0100 (Fri, 21 Feb 2014) | 2
> lines
>  Fixed typo in CHANGES.txt for issue LUCENE-5399 and moved that issue
>  under optimizations.
> 
> 
>  r1570562 | mikemccand | 2014-02-21 13:49:47 +0100 (Fri, 21 Feb 2014)
> | 1 line
>  LUCENE-5461: fix thread ha

RE: svn commit: r1570793 - in /lucene/dev/trunk/solr/solrj/src: java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java test-files/solrj/updateReq_4_5.bin test/org/apache/solr/client/

2014-02-22 Thread Noble Paul നോബിള്‍ नोब्ळ् 
Sure.
let's change the location one we identify the right place.
I hope we don't need to block 4.7 for this
On 22 Feb 2014 14:32, "Uwe Schindler"  wrote:

> Hi,
>
> your commit is likely to fail when we start to restructure directory
> layouts. Tests should (whenever possible) always use the classpath to find
> the files in test-files (which is part of the classpath).
> Attached is a patch with the "recommended way". I suggest to fix this.
> ExternalPaths.SOURCE_HOME is unused in Solr test, the constant is just a
> relict and only used internally on setup of test infrastructure. Real tests
> should not use it.
>
> There are more usages of this constant in test with "absolute" paths
> (including "contrib/foobar/src/test-files" to the contrib modules, I will
> open issue to fix those.
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> > -Original Message-
> > From: no...@apache.org [mailto:no...@apache.org]
> > Sent: Saturday, February 22, 2014 7:19 AM
> > To: comm...@lucene.apache.org
> > Subject: svn commit: r1570793 - in /lucene/dev/trunk/solr/solrj/src:
> > java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
> > test-files/solrj/updateReq_4_5.bin
> > test/org/apache/solr/client/solrj/request/TestUpdateRequestCodec.java
> >
> > Author: noble
> > Date: Sat Feb 22 06:19:16 2014
> > New Revision: 1570793
> >
> > URL: http://svn.apache.org/r1570793
> > Log:
> > SOLR-5762 broke backward compatibility of Javabin format
> >
> > Added:
> > lucene/dev/trunk/solr/solrj/src/test-files/solrj/updateReq_4_5.bin
> (with
> > props)
> > Modified:
> >
> >
> lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
> > vaBinUpdateRequestCodec.java
> >
> >
> lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
> > estUpdateRequestCodec.java
> >
> > Modified:
> >
> lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
> > vaBinUpdateRequestCodec.java
> > URL:
> >
> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/java/org/apa
> > che/solr/client/solrj/request/JavaBinUpdateRequestCodec.java?rev=157079
> > 3&r1=1570792&r2=1570793&view=diff
> > ==
> > 
> > ---
> >
> lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
> > vaBinUpdateRequestCodec.java (original)
> > +++ lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/re
> > +++ quest/JavaBinUpdateRequestCodec.java Sat Feb 22 06:19:16 2014
> > @@ -184,7 +184,13 @@ public class JavaBinUpdateRequestCodec {
> >  delByIdMap = (Map>)
> > namedList[0].get("delByIdMap");
> >  delByQ = (List) namedList[0].get("delByQ");
> >  doclist = (List) namedList[0].get("docs");
> > -docMap =  (List>>)
> > namedList[0].get("docsMap");
> > +Object docsMapObj = namedList[0].get("docsMap");
> > +
> > +if (docsMapObj instanceof Map) {//SOLR-5762
> > +  docMap =  new ArrayList(((Map)docsMapObj).entrySet());
> > +} else {
> > +  docMap = (List>>)
> > docsMapObj;
> > +}
> >
> >
> >  // we don't add any docs, because they were already processed
> >
> > Added: lucene/dev/trunk/solr/solrj/src/test-files/solrj/updateReq_4_5.bin
> > URL: http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/test-
> > files/solrj/updateReq_4_5.bin?rev=1570793&view=auto
> > ==
> > 
> > Binary file - no diff available.
> >
> > Modified:
> >
> lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
> > estUpdateRequestCodec.java
> > URL:
> >
> http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/test/org/apa
> > che/solr/client/solrj/request/TestUpdateRequestCodec.java?rev=1570793&r
> > 1=1570792&r2=1570793&view=diff
> > ==
> > 
> > ---
> >
> lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
> > estUpdateRequestCodec.java (original)
> > +++ lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/re
> > +++ quest/TestUpdateRequestCodec.java Sat Feb 22 06:19:16 2014
> > @@ -18,6 +18,9 @@ package org.apache.solr.client.solrj.req
> >
> >  import java.io.ByteArrayInputStream;
> >  import java.io.ByteArrayOutputStream;
> > +import java.io.File;
> > +import java.io.FileInputStream;
> > +import java.io.FileOutputStream;
> >  import java.io.IOException;
> >  import java.util.ArrayList;
> >  import java.util.Collection;
> > @@ -31,6 +34,7 @@ import junit.framework.Assert;  import
> > org.apache.lucene.util.LuceneTestCase;
> >  import org.apache.solr.common.SolrInputDocument;
> >  import org.apache.solr.common.SolrInputField;
> > +import org.apache.solr.util.ExternalPaths;
> >  import org.junit.Test;
> >
> >  /**
> > @@ -160,6 +164,75 @@ public class TestUpdateRequestCodec exte
>

Re: [VOTE] Lucene / Solr 4.7.0 RC3

2014-02-21 Thread Noble Paul നോബിള്‍ नोब्ळ् 
Backward incompatibility is something that should be considered as a
blocker.

Anyway , I have fixed the issue in 4.7 branch. I have also fixed the
SOLR-3854 omission


You can respin a build

On Sat, Feb 22, 2014 at 1:10 AM, Simon Willnauer
wrote:

> Thanks nobel! can you please ping me here so I can kick off another RC.
>
> Regarding the bugs that should / should not block a release I think
> it's hard to say which one should and that is my biggest problem here.
> I think with more frequent releases and more point releases we can
> make the intervals shorter and bugs get fixed quicker. I think it's
> also the responsibility of the other committers to maybe go back a
> step and ask themself if a bug should block a release and only if the
> are absolutely +1 on respin mention it on the release thread? To me as
> a RM it's really hard to draw the line. I also think we should not
> push stuff into the release branch unless it's the cause of the
> respin, we should work towards a stable branch an every change makes
> it less stable again IMO.
>
> just my $0.05
>
> On Fri, Feb 21, 2014 at 6:35 PM, Noble Paul നോബിള്‍  नोब्ळ्
>  wrote:
> > I'm working on a test case for 5762 I'll commit it tomorrow IST
> >
> > On 21 Feb 2014 20:05, "Simon Willnauer" 
> wrote:
> >>
> >> So the problem here is where to draw the line. I think in a setup like
> >> we have with lucene and solr in one codebase the chance to hit a bug
> >> within these 72h is huge. This means the Release process is a huge
> >> pain each time. Then we have bugs that justify a respin and some who
> >> don't. I looked at SOLR-5762 and it seems this one should cause a
> >> respin but the LUCENE-5461 doesn't. It's hard to draw that line since
> >> its pretty much up to the RM and then you get heat if you draw that
> >> line. IMO we should improve our release process and release a point
> >> release every week shortening the vote period for that to maybe 24h.
> >> That way we can get stuff out quickly and don't spend weeks on the
> >> release process.
> >>
> >> I will call this vote here as failed and build a new RC once SOLR-5762
> is
> >> in.
> >>
> >> simon
> >>
> >> On Fri, Feb 21, 2014 at 3:23 PM, Steve Rowe  wrote:
> >> > I volunteer to be 4.7.1 RM.
> >> >
> >> > I’d prefer to delay the 4.7.0 release to include all known bugfixes,
> >> > though.
> >> >
> >> > Simon, if you’re okay with it, I could take over as 4.7.0 RM and
> handle
> >> > any respins.  If not, it’s your prerogative to continue with the
> current RC
> >> > vote; others can express their opinions by voting.  I’m sure it’ll be
> fine
> >> > either way.
> >> >
> >> > Steve
> >> >
> >> > On Feb 21, 2014, at 8:19 AM, Simon Willnauer <
> simon.willna...@gmail.com>
> >> > wrote:
> >> >
> >> >> Guys, I don't think we will ever get to the point where there is not
> a
> >> >> bug. But we have to draw a line here. If we respin I have to step
> back
> >> >> as the RM since I just can't spend more than 7 days on this. I think
> >> >> there should be a 4.7.1 at some point where you can get your bugs
> >> >> fixed as everybody else but we have to draw a line here. I think I am
> >> >> going to draw it here with the 3 +1 I am having.
> >> >>
> >> >> simon
> >> >>
> >> >> On Fri, Feb 21, 2014 at 2:12 PM, Tomás Fernández Löbbe
> >> >>  wrote:
> >> >>> Question here. Shouldn't SOLR-5762 be fixed before 4.7? My
> >> >>> understanding is
> >> >>> that if not, Solr 4.7 won't be able to work with SolrJ from 4.6.1 or
> >> >>> earlier?
> >> >>>
> >> >>>
> >> >>> On Fri, Feb 21, 2014 at 5:01 AM, Robert Muir 
> wrote:
> >> >>>>
> >> >>>>
> >> >>>> And I think it should be under optimizations not changes in
> behavior.
> >> >>>>
> >> >>>> On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen
> >> >>>>  wrote:
> >> >>>>>
> >> >>>>>
> >> >>>>> Only spotted a small docs typo in the Lucene CHANGES.txt, the
> second
> >> >>>>> issue under "Changes in Runtime Behavior" should be LUCENE-5399
> >> >>>>> instead of
> >> >>>>> LUCENE-4399.
> >> >>>>>
> >> >>>>>
> >> >>>
> >> >>
> >> >> -
> >> >> 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
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
-
Noble Paul

Re: [VOTE] Lucene / Solr 4.7.0 RC3

2014-02-21 Thread Noble Paul നോബിള്‍ नोब्ळ् 
I'm working on a test case for 5762 I'll commit it tomorrow IST
On 21 Feb 2014 20:05, "Simon Willnauer"  wrote:

> So the problem here is where to draw the line. I think in a setup like
> we have with lucene and solr in one codebase the chance to hit a bug
> within these 72h is huge. This means the Release process is a huge
> pain each time. Then we have bugs that justify a respin and some who
> don't. I looked at SOLR-5762 and it seems this one should cause a
> respin but the LUCENE-5461 doesn't. It's hard to draw that line since
> its pretty much up to the RM and then you get heat if you draw that
> line. IMO we should improve our release process and release a point
> release every week shortening the vote period for that to maybe 24h.
> That way we can get stuff out quickly and don't spend weeks on the
> release process.
>
> I will call this vote here as failed and build a new RC once SOLR-5762 is
> in.
>
> simon
>
> On Fri, Feb 21, 2014 at 3:23 PM, Steve Rowe  wrote:
> > I volunteer to be 4.7.1 RM.
> >
> > I’d prefer to delay the 4.7.0 release to include all known bugfixes,
> though.
> >
> > Simon, if you’re okay with it, I could take over as 4.7.0 RM and handle
> any respins.  If not, it’s your prerogative to continue with the current RC
> vote; others can express their opinions by voting.  I’m sure it’ll be fine
> either way.
> >
> > Steve
> >
> > On Feb 21, 2014, at 8:19 AM, Simon Willnauer 
> wrote:
> >
> >> Guys, I don't think we will ever get to the point where there is not a
> >> bug. But we have to draw a line here. If we respin I have to step back
> >> as the RM since I just can't spend more than 7 days on this. I think
> >> there should be a 4.7.1 at some point where you can get your bugs
> >> fixed as everybody else but we have to draw a line here. I think I am
> >> going to draw it here with the 3 +1 I am having.
> >>
> >> simon
> >>
> >> On Fri, Feb 21, 2014 at 2:12 PM, Tomás Fernández Löbbe
> >>  wrote:
> >>> Question here. Shouldn't SOLR-5762 be fixed before 4.7? My
> understanding is
> >>> that if not, Solr 4.7 won't be able to work with SolrJ from 4.6.1 or
> >>> earlier?
> >>>
> >>>
> >>> On Fri, Feb 21, 2014 at 5:01 AM, Robert Muir  wrote:
> 
> 
>  And I think it should be under optimizations not changes in behavior.
> 
>  On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen
>   wrote:
> >
> >
> > Only spotted a small docs typo in the Lucene CHANGES.txt, the second
> > issue under "Changes in Runtime Behavior" should be LUCENE-5399
> instead of
> > LUCENE-4399.
> >
> >
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Lucene / Solr 4.7.0 RC2

2014-02-20 Thread Noble Paul നോബിള്‍ नोब्ळ् 
Yeah, -0 for a respin






On Thu, Feb 20, 2014 at 11:58 PM, Simon Willnauer  wrote:

> this makes sense mark - I will keep on building the RC3
>
> On Thu, Feb 20, 2014 at 7:27 PM, Mark Miller 
> wrote:
> > Nice last minute catch!
> >
> > Since we have not doc’d SSL support yet, a user could work around via
> just setting the scheme manually in zk.
> >
> > As it’s not a regression and there is a fairly simple workaround, I’d be
> -0 on a respin for it. SSL becomes possible for the few that need it and we
> can improve / fix it in a future release.
> >
> >
> > - Mark
> >
> > http://about.me/markrmiller
> >
> > On Feb 20, 2014, at 1:13 PM, Noble Paul നോബിള്‍ नोब्ळ् <
> noble.p...@gmail.com> wrote:
> >
> >> SOLR-3854 seems to be incomplete . It relies on a CLuster-wide property
> called urlScheme. These properties needs to be whitelisted at the
> OverseerCollectionProcessor.KNOWN_CLUSTER_PROPS
> >>
> >>
> >> The testcase directly writes the property to ZK . A norma user would
> only use the API
> >>
> >>
> >> On Thu, Feb 20, 2014 at 10:55 PM, Simon Willnauer <
> simon.willna...@gmail.com> wrote:
> >> yeah we manually do svn merge per commit so at this stage only bugs
> >> should be ported. Feature wise we are set!
> >>
> >> thanks
> >>
> >> simon
> >>
> >> On Thu, Feb 20, 2014 at 6:23 PM, Benson Margulies <
> bimargul...@gmail.com> wrote:
> >> > I get it. You're cherry-picking changes onto the rel branch. No,
> >> > there's absolutely no reason to imagine grabbing 5449.
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >>
> >>
> >>
> >> --
> >> -
> >> Noble Paul
> >
> >
> > -
> > 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
>
>


-- 
-
Noble Paul

Re: [VOTE] Lucene / Solr 4.7.0 RC2

2014-02-20 Thread Noble Paul നോബിള്‍ नोब्ळ् 
SOLR-3854 seems to be incomplete . It relies on a CLuster-wide property
called urlScheme. These properties needs to be whitelisted at the
OverseerCollectionProcessor.KNOWN_CLUSTER_PROPS


The testcase directly writes the property to ZK . A norma user would only
use the API


On Thu, Feb 20, 2014 at 10:55 PM, Simon Willnauer  wrote:

> yeah we manually do svn merge per commit so at this stage only bugs
> should be ported. Feature wise we are set!
>
> thanks
>
> simon
>
> On Thu, Feb 20, 2014 at 6:23 PM, Benson Margulies 
> wrote:
> > I get it. You're cherry-picking changes onto the rel branch. No,
> > there's absolutely no reason to imagine grabbing 5449.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
-
Noble Paul

Re: Welcome Anshum Gupta as Lucene/Solr Committer!

2014-02-16 Thread Noble Paul നോബിള്‍ नोब्ळ् 
Welcome on board Anshum, Looking forward to more exciting days

--Noble


On Mon, Feb 17, 2014 at 8:44 AM, Anshum Gupta wrote:

> Thanks Mark.
>
> I spent most of my life in New Delhi, India other than short stints in
> different parts of the country (including living in a beach house on a
> tropical island for 3 years when I was young). After spending the last 3
> years in Bangalore, I just relocated to San Francisco to be at the
> LucidWorks office in the Bay Area. Prior to this I've been a part of the
> search teams at A9 (CloudSearch), Cleartrip.com and Naukri.com where I was
> involved in designing and developing search and recommendation engines.
>
> These days, I love contributing stuff to Solr, primarily around SolrCloud
> and hope to continue to be at least as active towards it.
>
> In my free time I love photography, traveling, eating out and drinking my
> beer.
>
>
> On Sun, Feb 16, 2014 at 2:33 PM, Mark Miller wrote:
>
>> Hey everybody!
>>
>> The Lucene PMC is happy to welcome Anshum Gupta as a committer on the
>> Lucene / Solr project.  Anshum has contributed to a number of issues for
>> the project, especially around SolrCloud.
>>
>> Welcome Anshum!
>>
>> It's tradition to introduce yourself with a short bio :)
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>>
>
>
>
> --
>
> Anshum Gupta
> http://www.anshumgupta.net
>



-- 
-
Noble Paul

Re: The Old Git Discussion

2014-01-03 Thread Noble Paul നോബിള്‍ नोब्ळ् 
I personally have -0

I don't have any preference. Minus because it would change my comfortable
workflow. Is there any pressing need to switch? Or, if someone has to give
one real reason for the switch, what would it be ?
On 3 Jan 2014 20:49, "Mark Miller"  wrote:

> Just to answer some of your questions:
>
> On Jan 3, 2014, at 8:18 AM, Uwe Schindler  wrote:
>
> > Hi,
> >
> > I fully agree with Robert: I don't want to move to GIT. In addition,
> unless there is some tool that works as good as Windows' TortoiseSVN also
> for GIT, so I can merge in milliseconds(TM), I won't commit anything.
>
> SmartGit is way better than TortoiseSVN IMO. Your favorite tool is a silly
> way to decide something like this IMO as well though.
>
> >
> > I just note: I was working as committer for the PHP project (maintaining
> the SAPI module for Oracle iPlanet Webserver), but since they moved to GIT
> 2 years ago, I never contributed anything anymore. I just don't understand
> how it works and its completely unusable to me. E.g. look at this bullshit:
> https://wiki.php.net/vcs/gitworkflow - Sorry this is a no-go. And I have
> no idea what all these cryptic commands mean and I don't want to learn
> that. If we move to GIT, somebody else have to commit my patches.
>
> Others committed your patches in the past and I’m sure they will continue
> to do so in the future if you desire.
>
> >
> > And the other comment that was given here is not true: Merging with SVN
> works perfectly fine and is easy to do, unless you use the command line or
> Eclipse's bullshit SVN client (that never works correctly). With a good GUI
> (like the fantastic TortoiseSVN), merging is so simple and conflicts can be
> processed in milliseconds(TM). And it is much easier to understand.
>
> An opinion not commonly shared by my reading. At a minimum, simply opinion
> though.
>
> >
> > Also Subversion is an Apache Project and I want to add: We should eat
> our own dog food. Just to move to something with a crazy license and a
> broken user interface, just because it's cool, is a no-go to me.
>
> Certainly not because it’s cool! Who argued that?
>
> > We would also need to rewrite all our checking tasks (like the
> check-svn-working-copy ANT task) to work with GIT. Is there a pure Java
> library that works for GIT? I assume: No.
>
> You assume wrong. JGit is used by many projects, I’ve used it myself.
>
> > So this is another no-go for me. The checks we do cannot be done by
> command line.
>
> I guess it’s not a no go then, because your assumption was wrong…
>
> - Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

RE: Collections API

2013-11-29 Thread Noble Paul നോബിള്‍ नोब्ळ् 
If the patch is applied the work around must not be required
On 29 Nov 2013 08:17, "Steve Molloy"  wrote:

> Thanks, I already had the genericCoreNodeNames=true in solrcloud section
> of solr.xml, new format. But I had a "str" entry instead of a "bool", which
> apparently is simply treated as false. Anyhow, in my case the fix works if
> I move the bit setting the coreNodeName after the publish, not before. If
> it's before, I get a timeout error while it waits for a replica that is
> never set in waitForShardId.
>
> I'll both apply the modified patch and switch from str to bool. :)
>
> Thanks for the help,
> Steve
>
>
> From: Alexey Serba [ase...@gmail.com]
>
> Sent: November 28, 2013 2:10 AM
>
> To: dev@lucene.apache.org
>
> Subject: Re: Collections API
>
>
>
>
>
>
> https://issues.apache.org/jira/browse/SOLR-5510
>
>
>
>
> I don't really understand all the details why is that happening, but the
> workaround is to add genericCoreNodeNames="${genericCoreNodeNames:true}
>  attribute to cores element in your solr.xml file.
>
>
>
>
>
> On Tue, Nov 26, 2013 at 10:10 PM, Steve Molloy
>  wrote:
>
>
> I'm trying to reconcile our fork with 4.6 tag and I'm getting weird
> behaviour in Collections API, more specifically in ZkController's
> preRegister method after calling the create method of the collections API.
> When it checks if a slice has a replica for current
>  node name, there is never any because at this stage, the slice has no
> replica. This is the new code that seems to be causing my issue, I can
> force the "autoCreated" to be always true to avoid the issue, but would
> like a cleaner way if there is one.
>
>
>
>   if(cd.getCloudDescriptor().getCollectionName() !=null &&
> cd.getCloudDescriptor().getCoreNodeName() != null ) {
>
> //we were already registered
>
>
> if(zkStateReader.getClusterState().hasCollection(cd.getCloudDescriptor().getCollectionName())){
>
> DocCollection coll =
> zkStateReader.getClusterState().getCollection(cd.getCloudDescriptor().getCollectionName());
>
>  if(!"true".equals(coll.getStr("autoCreated"))){
>
>Slice slice =
> coll.getSlice(cd.getCloudDescriptor().getShardId());
>
>if(slice != null){
>
> ==>  if(slice.getReplica(cd.getCloudDescriptor().getCoreNodeName()) ==
> null) {
>
>log.info("core_removed This core is removed from ZK");
>
>throw new SolrException(ErrorCode.NOT_FOUND,coreNodeName +"
> is removed");
>
>  }
>
>}
>
>  }
>
> }
>
>   }
>
>
>
> Thanks.
>
> Steve
>
> -
>
> To unsubscribe, e-mail:
> dev-unsubscr...@lucene.apache.org
>
> For additional commands, e-mail:
> dev-h...@lucene.apache.org
>
>
>
>
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Release Lucene/Solr 4.5.0

2013-09-19 Thread Noble Paul നോബിള്‍ नोब्ळ् 
I see a commit message on branch_4x for the changes I made . Isn't it the
same branch?
On 19 Sep 2013 19:00, "Adrien Grand"  wrote:

> Hi,
>
> On Thu, Sep 19, 2013 at 3:10 PM, Yonik Seeley 
> wrote:
> > It looks like the last commit on SOLR-4221 didn't make it on the 45
> > branch.  This is a change to a new API and hence needs to make it into
> > 4.5
>
> Thanks for noticing this issue, I will backport the commit.
>
> Hoss, do you want to take advantage of the fact that we need to respin
> to backport LUCENE-5223?
>
> Thanks.
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Release Lucene/Solr 4.5.0

2013-09-19 Thread Noble Paul നോബിള്‍ नोब्ळ् 
+1
On 19 Sep 2013 16:38, "Marcelo Costa"  wrote:

> +1
>
> Marcelo Costa
> -
> http://www.infoq.com/br/author/Marcelo-Costa
>
>
>
>
> On Wed, Sep 18, 2013 at 7:41 PM, Jack Krupansky 
> wrote:
>
>> +1 for my quick test. Even tried the UI on IE10.
>>
>> -- Jack Krupansky
>>
>> -Original Message- From: Adrien Grand
>> Sent: Wednesday, September 18, 2013 5:46 PM
>> To: dev@lucene.apache.org
>> Subject: [VOTE] Release Lucene/Solr 4.5.0
>>
>>
>> Hi all,
>>
>> Please test and vote to release the following Lucene and Solr 4.5.0
>> artifacts:
>> http://people.apache.org/~**jpountz/staging_area/lucene-**
>> solr-4.5.0-RC0-rev1524484/
>>
>> This vote is open until monday.
>>
>> Smoke tester passed and Elasticsearch tests ran successfully with
>> these artifacts, so here is my +1.
>>
>> --
>> Adrien
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@lucene.apache.**org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@lucene.apache.**org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>

Re: [jira] [Commented] (SOLR-4221) Custom sharding

2013-09-13 Thread Noble Paul നോബിള്‍ नोब्ळ् 
Yes,
It is resolved.
On 12 Sep 2013 21:22, "Chris Hostetter"  wrote:

>
> : just grand me edit access
>
> Are you talking about edit access for the ref guide?
>
> there's a well documented process for that...
>
>
> https://cwiki.apache.org/confluence/display/solr/Internal+-+Maintaining+Documentation#Internal-MaintainingDocumentation-WhoCanEditThisDocumentation
> https://cwiki.apache.org/confluence/display/solr/Internal+-+CWIKI+ACLs
>
> That doesn't answer my first question however: is SOLR-4221 complete?
> should the issue be resolved as "fixed in 4.5" ?
>
>
> : On Thu, Sep 12, 2013 at 5:11 AM, Hoss Man (JIRA) 
> wrote:
> :
> : >
> : > [
> : >
> https://issues.apache.org/jira/browse/SOLR-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764968#comment-13764968
> ]
> : >
> : > Hoss Man commented on SOLR-4221:
> : > 
> : >
> : > Is this feature complete? (all of the subtasks are marked resolved and
> : > several commits associated with this isue are in branch 4x)
> : >
> : >
> : > Can someone who understands all of the various changes made in these
> : > issues please update the ref guide (or post a comment suggestion what
> : > additions should be made)...
> : >
> : > https://cwiki.apache.org/confluence/display/solr/Collections+API
> : >
> : >
> : >
> : >
> : > > Custom sharding
> : > > ---
> : > >
> : > > Key: SOLR-4221
> : > > URL: https://issues.apache.org/jira/browse/SOLR-4221
> : > > Project: Solr
> : > >  Issue Type: New Feature
> : > >Reporter: Yonik Seeley
> : > >Assignee: Noble Paul
> : > > Attachments: SOLR-4221.patch, SOLR-4221.patch,
> SOLR-4221.patch,
> : > SOLR-4221.patch, SOLR-4221.patch
> : > >
> : > >
> : > > Features to let users control everything about sharding/routing.
> : >
> : > --
> : > 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
> : >
> : >
> :
> :
> : --
> : -
> : Noble Paul
> :
>
> -Hoss
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [jira] [Commented] (SOLR-4221) Custom sharding

2013-09-11 Thread Noble Paul നോബിള്‍ नोब्ळ् 
just grand me edit access


On Thu, Sep 12, 2013 at 5:11 AM, Hoss Man (JIRA)  wrote:

>
> [
> https://issues.apache.org/jira/browse/SOLR-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764968#comment-13764968]
>
> Hoss Man commented on SOLR-4221:
> 
>
> Is this feature complete? (all of the subtasks are marked resolved and
> several commits associated with this isue are in branch 4x)
>
>
> Can someone who understands all of the various changes made in these
> issues please update the ref guide (or post a comment suggestion what
> additions should be made)...
>
> https://cwiki.apache.org/confluence/display/solr/Collections+API
>
>
>
>
> > Custom sharding
> > ---
> >
> > Key: SOLR-4221
> > URL: https://issues.apache.org/jira/browse/SOLR-4221
> > Project: Solr
> >  Issue Type: New Feature
> >Reporter: Yonik Seeley
> >Assignee: Noble Paul
> > Attachments: SOLR-4221.patch, SOLR-4221.patch, SOLR-4221.patch,
> SOLR-4221.patch, SOLR-4221.patch
> >
> >
> > Features to let users control everything about sharding/routing.
>
> --
> 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
>
>


-- 
-
Noble Paul

Re: lazily-loaded cores and SolrCloud

2013-08-13 Thread Noble Paul നോബിള്‍ नोब्ळ् 
It is worth doing it. A lot of people will need it  . Let's open an issue
and come up with a design for the same .
On 14 Aug 2013 02:16, "Yonik Seeley"  wrote:

> At a high level, I think the idea is fine (and I've seen a number of
> people that wanted it).
> The question is more around one of implementation... would it make a
> mess of things or not.
> The answer to that I think is probably mostly related to issues around
> how zookeeper is currently handled.
> I don't see any issues with other things like spinning up a core when
> a request comes in for it.
>
> -Yonik
> http://lucidworks.com
>
> On Tue, Aug 13, 2013 at 4:26 PM, Erick Erickson 
> wrote:
> > There was a question on the user's list today about making lazily-loaded
> > (aka transient) cores work with SolrCloud where I basically punted and
> said
> > "not designed with that in mind". I've kind of avoided thinking about
> this
> > as the use-case; the transient code wasn't written with SolrCloud in
> mind.
> >
> > But what is the general reaction to that pairing? Mostly I'm looking for
> > feedback at the level of "no way that could work without invasive
> changes to
> > SolrCloud, don't even go there" or "sure, just allow ZK to get a list of
> all
> > cores and it'll be fine, the user is responsible for the quirks though".
> > Some questions that come to my mind:
> >
> >> Is a core that's not loaded be considered "live" by ZK? Would simply
> >> returning a list of all cores (both loaded and not loaded) be
> sufficient for
> >> ZK? (this list is already available so the admin UI can list all cores).
> >
> >> Does SolrCloud distributed update processing go through (or could be
> made
> >> to go through) the path that autoloads a core?
> >
> >> Ditto for querying. I suspect the answer to both is that it'll "just
> >> happen".
> >
> >> Would the idea of waiting for all the cores to load on all the nodes for
> >> an update be totally unacceptable? We already have the distributed
> deadlock
> >> potential, this seems to make that more likely by lengthening out the
> time
> >> the semaphore in question is held.
> >
> >> Would re-synching/leader election be an absolute nightmare? I can
> imagine
> >> that if all the cores for a particular shard weren't loaded at startup,
> >> there'd be a terrible time waiting for leader election for instance.
> >
> >> Stuff I haven't thought of
> >
> > Mostly I'm trying to get a "sense of the community" here about whether
> > supporting transient cores in SolrCloud mode would be something that
> would
> > be easy/do-able/really_hard/totally_unacceptable.
> >
> > Thanks,
> > Erick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Threshold Checks for Replication in solrconfig.xml

2013-08-05 Thread Noble Paul നോബിള്‍ नोब्ळ् 
I'm feeling , you are concerned about bad index. Don't you think we should
be trying to avoid replicating bad index instead of thresholds?


On Mon, Aug 5, 2013 at 11:55 AM, Kranti Parisa wrote:

> Yes, we can disable replication and perform the checks manually, that is
> what we are doing currently. And yes, the idea of configuring threshold
> checks is to delay the replication in case of bad index (if threshold
> checks are not needed, we can avoid configuring the same). It would give us
> control over a bad index especially in the cases of frequent
> deletes/updates for the expired assets.
>
>
>
> Thanks & Regards,
> Kranti K Parisa
> http://www.linkedin.com/in/krantiparisa
>
>
>
> On Mon, Aug 5, 2013 at 2:12 AM, Noble Paul നോബിള്‍ नोब्ळ् <
> noble.p...@gmail.com> wrote:
>
>> What is the objective here?
>>
>> Now you can disable replication with a command on the master and re
>> enable it later. Do you wish to make it a bit easier with this?
>>
>>
>> the threshold check according to your example will delay the replication
>> forever if the threshold is not reached at all
>>
>> This is only useful if you are doing a fresh reindex
>>
>>
>>
>> On Mon, Aug 5, 2013 at 9:44 AM, Kranti Parisa wrote:
>>
>>> Hi,
>>>
>>> I think, it would be nice to configure Solr for the threshold checks
>>> before doing the index replication. This would stop a bad index to be
>>> copied over to the slaves which are ideally the ones serving the user
>>> requests.
>>>
>>> In our case, we will have Solr Indexer which will index the documents.
>>> Before starting the indexing process we disable the replication and then
>>> index the documents. Then perform the threshold checks and if we have a
>>> reasonable index then we enable the replication. So that the Solr Query
>>> Engines will have a good index to server the user queries.
>>>
>>> I have been thinking how it would be if we have this facility in Solr
>>> (solrconfig.xml) by default for everyone.
>>>
>>> We may have something like this inside the Replication Request Handler
>>> section (either master can check before enabling replciation or slave can
>>> check against the master before downloading the index, which ever is best,
>>> I think better master does this check so that all the slaves need not check
>>> for same thing against the master)
>>>
>>>  
>>>  10
>>>   4
>>>  1
>>>   
>>>
>>> I think, this is a very common task for people using Solr replication. I
>>> am interested to work on this feature and commit the same. Before that I
>>> would like to know your views on this feature. If this is something already
>>> exists or coming up, please let me know!
>>>
>>>
>>> Thanks & Regards,
>>> Kranti K Parisa
>>> http://www.linkedin.com/in/krantiparisa
>>>
>>>
>>
>>
>> --
>> -
>> Noble Paul
>>
>
>


-- 
-
Noble Paul

Re: Threshold Checks for Replication in solrconfig.xml

2013-08-04 Thread Noble Paul നോബിള്‍ नोब्ळ् 
What is the objective here?

Now you can disable replication with a command on the master and re enable
it later. Do you wish to make it a bit easier with this?


the threshold check according to your example will delay the replication
forever if the threshold is not reached at all

This is only useful if you are doing a fresh reindex



On Mon, Aug 5, 2013 at 9:44 AM, Kranti Parisa wrote:

> Hi,
>
> I think, it would be nice to configure Solr for the threshold checks
> before doing the index replication. This would stop a bad index to be
> copied over to the slaves which are ideally the ones serving the user
> requests.
>
> In our case, we will have Solr Indexer which will index the documents.
> Before starting the indexing process we disable the replication and then
> index the documents. Then perform the threshold checks and if we have a
> reasonable index then we enable the replication. So that the Solr Query
> Engines will have a good index to server the user queries.
>
> I have been thinking how it would be if we have this facility in Solr
> (solrconfig.xml) by default for everyone.
>
> We may have something like this inside the Replication Request Handler
> section (either master can check before enabling replciation or slave can
> check against the master before downloading the index, which ever is best,
> I think better master does this check so that all the slaves need not check
> for same thing against the master)
>
>  
>  10
>   4
>  1
>   
>
> I think, this is a very common task for people using Solr replication. I
> am interested to work on this feature and commit the same. Before that I
> would like to know your views on this feature. If this is something already
> exists or coming up, please let me know!
>
>
> Thanks & Regards,
> Kranti K Parisa
> http://www.linkedin.com/in/krantiparisa
>
>


-- 
-
Noble Paul

Re: Welcome Cassandra Targett as Lucene/Solr committer

2013-08-02 Thread Noble Paul നോബിള്‍ नोब्ळ् 
Welcome cassandra. .
On 1 Aug 2013 04:18, "Robert Muir"  wrote:

> I'm pleased to announce that Cassandra Targett has accepted to join our
> ranks as a committer.
>
> Cassandra worked on the donation of the new Solr Reference Guide [1] and
> getting things in order for its first official release [2].
> Cassandra, it is tradition that you introduce yourself with a brief bio.
>
> Welcome!
>
> P.S. As soon as your SVN access is setup, you should then be able to add
> yourself to the committers list on the website as well.
>
> [1]
> https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide
> [2] https://www.apache.org/dyn/closer.cgi/lucene/solr/ref-guide/
>
>

branch 4_x vs trunk

2013-07-31 Thread Noble Paul നോബിള്‍ नोब्ळ् 
Are all the checkins made to 4_x branch available in the trunk too? I see
some tests failing in trunk but 4_x is passing all tests



-- 
-
Noble Paul

Re: Anyone interested about using GPU to improve the performance of Lucene?

2013-07-30 Thread Noble Paul നോബിള്‍ नोब्ळ् 
It does not really have to be a platform independent thing. It can be a
configurable switch where the user who has a particular h/w should be able
use that switch and take advantage of the perf boost.

But, we should be able to demonstrate some significant improvement using
NVIDIA GPUs


On Wed, Jul 10, 2013 at 2:52 AM, Uwe Schindler  wrote:

> Thanks for the information about the CUDA project!
>
> ** **
>
> I think the main reason why you have not heard anything about
> Lucene/Solr/ElasticSearch working together with GPUs is mainly the fact,
> that Apache Lucene and all search servers on top of Lucene (Apache Solr,
> ElasticSearch) are pure Java applications, highly optimized to run in the
> Oracle virtual machine. Currently there is no official support for GPUs
> from Java APIs, you can only use proprietary wrapper libraries to make use
> of CUDA (e.g. http://www.jcuda.org/).
>
> ** **
>
> It would be great, if there would be a platform independent way (directly
> in the official Java API) to execute jobs on GPUs. 
>
> ** **
>
> It might be worth a try to maybe implement the Lucene block codecs (the
> abstraction of the underlying posting list formats) using a GPU. Because
> this is encapsulated in a public API, it could be a separate project, using
> the JNI-based CUDA wrappers to encode/decode PFOR postings lists. The query
> execution logic is harder to port, because there is a lot of abstraction
> included (posting lists are doc-id iterators), which would need to be short
> circuited.
>
> ** **
>
> Uwe
>
> ** **
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
> ** **
>
> *From:* Yanning Li [mailto:yanni...@nvidia.com]
> *Sent:* Tuesday, July 09, 2013 11:02 PM
> *To:* dev@lucene.apache.org
> *Subject:* Anyone interested about using GPU to improve the performance
> of Lucene?
>
> ** **
>
> Hi all,
>
> ** **
>
> I work for NVIDIA Tesla Accelerating Computing Group. Recently we are
> noticed that GPU can really accelerate the performance of search engines.
> There are proof points not only from Google, but also from others, such as
> Yandex, Baidu, Bing, etc.  But not much around Solr/Lucene. 
>
> ** **
>
> So we are trying to engage with Lucene developers more actively.
>
> **1)  **If possible we could like to hear from your perspective, are
> there some opportunities for GPU in Lucene/Solr?
>
> **2)  **Wondering is anyone interested  to use GPU to accelerate the
> performance of Lucene/Solr? If so please feel free to let me know, we can
> send out free GPUs to get  project started. 
>
> ** **
>
> Attached a paper talking about using GPU to accelerate index compression
> in case you have interests. 
>
> ** **
>
> Looking forward to hear from some of you,
>
> ** **
>
> Best
>
> ** **
>
> Yanning
> --
>
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential information.  Any unauthorized review, use,
> disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message. 
> --
>



-- 
-
Noble Paul

Re: Writing serialized java Object to ZK

2013-06-24 Thread Noble Paul നോബിള്‍ नोब्ळ् 
java serialized is not any more compact than json


On Mon, Jun 24, 2013 at 10:02 PM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> My guess is that it is done to avoid running into the max payload
> limit of a ZK node?
>
> On Mon, Jun 24, 2013 at 9:59 PM, Noble Paul നോബിള്‍  नोब्ळ्
>  wrote:
> > OverseerCollectionProcessor.run() writes a serialized java Object to ZK.
> Is
> > it by design? It makes it really hard to debug some ZK messages . I feel
> we
> > should be consistent in what we write to ZK and it shold always be json
> >
> > --
> > -
> > Noble Paul
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
-
Noble Paul

Writing serialized java Object to ZK

2013-06-24 Thread Noble Paul നോബിള്‍ नोब्ळ् 
OverseerCollectionProcessor.run() writes a serialized java Object to ZK. Is
it by design? It makes it really hard to debug some ZK messages . I feel we
should be consistent in what we write to ZK and it shold always be json

-- 
-
Noble Paul

Is solr.xml persistence completely broken in trunk?

2013-06-10 Thread Noble Paul നോബിള്‍ नोब्ळ् 
I created a couple of cores from coreadmin and after I restarted the server
, the cores are gone? I see that the "persist" attribute is deprecated .

Is there a bug open already?

-- 
-
Noble Paul

How to control the dataDir in SolrCloud

2013-06-10 Thread Noble Paul നോബിള്‍ नोब्ळ् 
When I create a collection in SolrCloud, the dataDir is created implicitly
under the instanceDir . I guess there is no way to configure this. It is
essential for large real deployments to control where the data lives.

-- 
-
Noble Paul

Re: Solr - ORM like layer

2013-06-07 Thread Noble Paul നോബിള്‍ नोब्ळ् 
SolrJ has a very limited ORM like functionality. It is built keeping in
mind the  the limitations of Solr  schema. Please take a look at let us
know what can we add more
http://wiki.apache.org/solr/Solrj#Directly_adding_POJOs_to_Solr


On Tue, Jun 4, 2013 at 6:22 PM, Tuğcem Oral  wrote:

> Hi folks,
>
> I wonder that there exist and ORM like layer for solr such that it
> generates the solr schema from given complex object type and index given
> list of corresponding objects. I wrote a simple module for that need in one
> of my projects and happyly ready to generalize it and contribute to solr,
> if there's not such a module exists or in progress.
>
> Thanks all.
>
> --
> TO
>



-- 
-
Noble Paul

build fails

2011-07-15 Thread Noble Paul നോബിള്‍ नोब्ळ् 
is it just me?

BUILD FAILED
C:\work\lucene_dev_fresh\build.xml:23: The following error occurred while execut
ing this line:
C:\work\lucene_dev_fresh\solr\build.xml:135: The following error occurred while
executing this line:
C:\work\lucene_dev_fresh\solr\core\build.xml:21: The following error occurred wh
ile executing this line:
C:\work\lucene_dev_fresh\solr\common-build.xml:67: C:\work\lucene_dev_fresh\solr
\core\lib not found.

-- 
-
Noble Paul

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

Re: Push for a Solr 1.4.1 Bug Fix Release?

2010-05-31 Thread Noble Paul നോബിള്‍ नोब्ळ् 
This has to be fixed as well
 
https://issues.apache.org/jira/browse/SOLR-1
769

On Mon, May 31, 2010 at 7:50 AM, Bill Au  wrote:

> +1
>
> I can help test any RC too.
>
> Bill
>
>
> On Sun, May 30, 2010 at 7:03 PM, Koji Sekiguchi wrote:
>
>>  (10/05/30 14:08), Chris Hostetter wrote:
>>
>> FYI...
>>
>> : ## 9 Bugs w/fixes on the 1.5 branch that seem serious enough
>> : ## that they warrant a 1.4.1 bug-fix release...
>>
>> ...those 9 bugs have been merged to branch-1.4.  I'll work on the
>> remainders listed below (which includes upgrading the lucene jars) tomorow
>> or monday
>>
>> : https://issues.apache.org/jira/browse/SOLR-1522
>> : https://issues.apache.org/jira/browse/SOLR-1538
>> : https://issues.apache.org/jira/browse/SOLR-1558
>> : https://issues.apache.org/jira/browse/SOLR-1563
>> : https://issues.apache.org/jira/browse/SOLR-1579
>> : https://issues.apache.org/jira/browse/SOLR-1580
>> : https://issues.apache.org/jira/browse/SOLR-1582
>> : https://issues.apache.org/jira/browse/SOLR-1596
>> : https://issues.apache.org/jira/browse/SOLR-1651
>>
>>   https://issues.apache.org/jira/browse/SOLR-1934
>>
>>
>> -Hoss
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>I'll backport the following soon if there is no objections:
>>
>> * SOLR-1748, SOLR-1747, SOLR-1746, SOLR-1745, SOLR-1744: Streams and
>> Readers
>> retrieved from ContentStreams are not closed in various places, resulting
>> in file descriptor leaks.
>> (Christoff Brill, Mark Miller)
>>
>> Koji
>>
>> -- http://www.rondhuit.com/en/
>>
>>
>


-- 
-
Noble Paul | Systems Architect| AOL | http://aol.com

Re: SOLR-571:LRUCache autowarmCount should support percentages

2010-04-19 Thread Noble Paul നോബിള്‍ नोब्ळ् 
what is the meaning of 50%? 50% of all queries fired since the last
searcher opened? sounds like a bad idea.

On Tue, Apr 20, 2010 at 3:40 AM, Tomas  wrote:
> Hi, I've been using Solr for some time and i would like to contribute a
> little. I found on Jira an improvement that seems to be easy to implement (I
> don't want to go with the most difficult ones until I get completly familiar
> with Solr code), the one on the Subject of this mail: SOLR-571:LRUCache
> autowarmCount should support percentages.
>
> I was thinking in modify both, the FastLRUCache and the LRUCache to allow
> percentages (as well as absolute values of course) on "autowarmCount"
> parameter, and in the case of a percentage, simply evaluate it on the "init"
> method.
>
> For example, when "size" parameter is 1000 and "autowarmCount" parameter is
> "50%", simply set the field autowarmCount in 500.
> Does someone see a potential problem here?
>
> Tomás
>
>



-- 
-
Noble Paul | Systems Architect| AOL | http://aol.com

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