Re: Old programmers do fade away

[Susheel Kumar]

Hi Erick, You have been really helpful to everyone of us and we are gonna
to miss you a lot. But best of luck and enjoy your time !!!

On Mon, Jan 4, 2021 at 1:22 PM Jason Gerlowski 
wrote:

> Hey Erick,
>
> I'm sorry for our users and for the project overall to hear you'll be
> "hanging up the spurs", but excited that you've found new, fun things
> to expand into in your retirement!  I hope they're awesome!
>
> Best of luck man, it's been great working with you!
>
> Best,
>
> Jason
>
> On Mon, Jan 4, 2021 at 1:05 PM Uwe Schindler  wrote:
> >
> > Hi Erick,
> >
> > too bad that you want to leave us. I really hope to see you in person
> after
> > COVID19 allows us to meet at conferences again. It was always nice
> > discussions with you on the mailing list, although I am not subscribed to
> > solr-user@lao, so the whole work you were doing is not so obvious to me.
> >
> > About the squirrels: As an European, I have no idea why those grey
> American
> > squirrels are so aggressive and eat all your tomatoes!
> > https://www.dropbox.com/s/g8w441njq8xvaxd/20210104_185757.jpg?dl=0
> (sitting
> > in my garden)
> >
> > Here in Bremen, I have no problem at all with tomatoes and squirrels. The
> > European red squirrels only collect and eat nuts (or to be more correct:
> > they collect nuts and then forget about them, making hazelnut trees grow
> > everywhere in my garden, if you do not destroy them).
> > https://www.dropbox.com/s/e9twup0850vxpdz/20210104_185720.jpg?dl=0
> > (leftovers of the nuts...)
> >
> > My tomato plants all survived and I was able to harvest this year.
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Erick Erickson 
> > > Sent: Wednesday, December 30, 2020 3:09 PM
> > > To: dev@lucene.apache.org
> > > Subject: Old programmers do fade away
> > >
> > > 40 years is enough. OK, it's only been 39 1/2 years. Dear Lord, has it
> > really been
> > > that long? Programming's been fun, I've gotten to solve puzzles every
> day.
> > The
> > > art and science of programming has changed over that time. Let me tell
> you
> > > about the joys of debugging with a Z80 stack emulator that required
> that
> > you
> > > to look on the stack for variables and trace function calls by knowing
> how
> > to
> > > follow frame pointers. Oh the tedium! Oh the (lack of) speed! Not to
> > mention
> > > that 64K of memory was all you had to work with. I had a co-worker who
> > could
> > > predict the number of bytes by which the program would shrink based on
> > > extracting common code to functions. The "good old days"...weren't...
> > >
> > > I'd been thinking that I'd treat Lucene/Solr as a hobby, doing
> occasional
> > work
> > > on it when I was bored over long winter nights. I've discovered,
> though,
> > that
> > > I've been increasingly reluctant to crack open the code. I guess that
> > after this
> > > much time, I'm ready to hang up my spurs. One major factor is the
> > realization
> > > that there's so much going on with Lucene/Solr that simply being aware
> of
> > the
> > > changes, much less trying to really understand them, isn't something I
> can
> > do
> > > casually.
> > >
> > > I bought a welder and find myself more interested in playing with that
> > than
> > > programming. Wait until you see the squirrel-proof garden enclosure I'm
> > > building with it. If my initial plan doesn't work, next up is an
> electric
> > fence
> > > along the top. The laser-sighted automatic machine gun emplacement will
> > take
> > > more planning...Ahhh, probably won't be able to get a permit from the
> > > township for that though. Do you think the police would notice?
> Perhaps I
> > > should add that the local police station is two blocks away and in the
> > line of
> > > fire. But an infrared laser powerful enough to "pre-cook" them
> wouldn't be
> > as
> > > obvious would it?
> > >
> > > Why am I so fixated on squirrels? One of the joys of gardening is fresh
> > > tomatoes rather than those red things they sell in the store. The
> > squirrels ATE
> > > EVERY ONE OF MY TOMATOES WHILE THEY WERE STILL GREEN LAST YEAR! And
> > > the melons. In the words of B. Bunny: "Of course you realize this means
> > war"
> > > (https://www.youtube.com/watch?v=4XNr-BQgpd0)...
> > >
> > > Then there's working in the garden and landscaping, the desk I want to
> > build
> > > for my wife, travel as soon as I can, maybe seeing if some sailboats
> need
> > > crew...you get the idea.
> > >
> > > It's been a privilege to work with this group, you're some of the best
> and
> > > brightest. Many thanks to all who've generously given me their time and
> > > guidance. It's been a constant source of amazement to me how willing
> > people
> > > are to take time out of their own life and work to help me when I've
> had
> > > questions. I owe a lot of people beers ;)
> > >
> > > I'll be stopping my list subscriptions, 

[jira] [Commented] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-6930:
-

I agree as well.  We have been using timeAllowed but i'll vote for something 
more sophisticated which can prevent OOM more predictably. 

> Provide "Circuit Breakers" For Expensive Solr Queries
> -
>
> Key: SOLR-6930
> URL: https://issues.apache.org/jira/browse/SOLR-6930
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Mike Drob
>Priority: Major
>
> Ref: 
> http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html
> ES currently allows operators to configure "circuit breakers" to preemptively 
> fail queries that are estimated too large rather than allowing an OOM 
> Exception to happen. We might be able to do the same thing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SOLR-12585) Solr fails even ZK quorum has majority

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-12585:


 Summary: Solr fails even ZK quorum has majority
 Key: SOLR-12585
 URL: https://issues.apache.org/jira/browse/SOLR-12585
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Server, SolrCloud
Affects Versions: 6.6.2
Reporter: Susheel Kumar


Solr fails to function when one of ZK quorum node gets inaccessible due to DNS 
issue. E.g. below we had running Solr Cloud cluster and when one of the node 
went inaccessible due to DNS issue, Solr stops functioning even though the 
other 2 ZK machines were up and had a majority. 

 

See mailing list for more details

[http://lucene.472066.n3.nabble.com/Solr-fails-even-ZK-quorum-has-majority-td4399166.html]
 

 

e.g.

ping ditsearch001.es.com                         

ping: cannot resolve ditsearch001.es.com: Unknown host

 

Caused by: org.apache.solr.common.SolrException: 
java.net.UnknownHostException: ditsearch001.es.com: Name or service not 
known 

        at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:171) 

        at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:117) 

        at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:112) 

        at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:99) 

        at 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [ANNOUNCE] Apache Solr 7.1.0 released

[Susheel Kumar]

Thank you, Yonik. Able to download directly.

On Tue, Oct 17, 2017 at 11:29 AM, Yonik Seeley <ysee...@gmail.com> wrote:

> It pointed to 7.1.0 for me perhaps a browser cache issue?
> Anyway, you can go directly as well:
> http://www.apache.org/dyn/closer.lua/lucene/solr/7.1.0
>
> -Yonik
>
>
> On Tue, Oct 17, 2017 at 11:25 AM, Susheel Kumar <susheel2...@gmail.com>
> wrote:
> > Thanks, Shalin.
> >
> > But the download mirror still has 7.0.1 not 7.1.0.
> >
> > http://www.apache.org/dyn/closer.lua/lucene/solr/7.0.1
> >
> >
> >
> >
> > On Tue, Oct 17, 2017 at 5:28 AM, Shalin Shekhar Mangar
> > <shalinman...@gmail.com> wrote:
> >>
> >> 17 October 2017, Apache Solr™ 7.1.0 available
> >>
> >> The Lucene PMC is pleased to announce the release of Apache Solr 7.1.0
> >>
> >> Solr is the popular, blazing fast, open source NoSQL search platform
> >> from the Apache Lucene project. Its major features include powerful
> >> full-text search, hit highlighting, faceted search, dynamic
> >> clustering, database integration, rich document (e.g., Word, PDF)
> >> handling, and geospatial search. Solr is highly scalable, providing
> >> fault tolerant distributed search and indexing, and powers the search
> >> and navigation features of many of the world's largest internet sites.
> >>
> >> Solr 7.1.0 is available for immediate download at:
> >>
> >> http://lucene.apache.org/solr/mirrors-solr-latest-redir.html
> >>
> >> See http://lucene.apache.org/solr/7_1_0/changes/Changes.html for a
> >> full list of details.
> >>
> >> Solr 7.1.0 Release Highlights:
> >>
> >> * Critical Security Update: Fix for CVE-2017-12629 which is a working
> >> 0-day exploit reported on the public mailing list. See
> >> https://s.apache.org/FJDl
> >>
> >> * Auto-scaling: Solr can now move replicas automatically when a new
> >> node is added or an existing node is removed using the auto scaling
> >> policy framework introduced in 7.0
> >>
> >> * Auto-scaling: The 'autoAddReplicas' feature which was limited to
> >> shared file systems is now available for all file systems. It has been
> >> ported to use the new autoscaling framework internally.
> >>
> >> * Auto-scaling: New set-trigger, remove-trigger, set-listener,
> >> remove-listener, suspend-trigger, resume-trigger APIs
> >>
> >> * Auto-scaling: New /autoscaling/history API to show past autoscaling
> >> actions and cluster events
> >>
> >> * New JSON based Query DSL for Solr that extends JSON Request API to
> >> also support all query parsers and their nested parameters
> >>
> >> * JSON Facet API: min/max aggregations are now supported on
> >> single-valued date fields
> >>
> >> * Lucene's Geo3D (surface of sphere & ellipsoid) is now supported on
> >> spatial RPT fields by setting spatialContextFactory="Geo3D".
> >> Furthermore, this is the first time Solr has out of the box support
> >> for polygons
> >>
> >> * Expanded support for statistical stream evaluators such as various
> >> distributions, rank correlations, distances and more.
> >>
> >> * Multiple other optimizations and bug fixes
> >>
> >> You are encouraged to thoroughly read the "Upgrade Notes" at
> >> http://lucene.apache.org/solr/7_1_0/changes/Changes.html or in the
> >> CHANGES.txt file accompanying the release.
> >>
> >> Solr 7.1 also includes many other new features as well as numerous
> >> optimizations and bugfixes of the corresponding Apache Lucene release.
> >>
> >> Please report any feedback to the mailing lists
> >> (http://lucene.apache.org/solr/discussion.html)
> >>
> >> Note: The Apache Software Foundation uses an extensive mirroring
> >> network for distributing releases. It is possible that the mirror you
> >> are using may not have replicated the release yet. If that is the
> >> case, please try another mirror. This also goes for Maven access.
> >>
> >> --
> >> Regards,
> >> Shalin Shekhar Mangar.
> >>
> >> -
> >> 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: [ANNOUNCE] Apache Solr 7.1.0 released

[Susheel Kumar]

Thanks, Shalin.

But the download mirror still has 7.0.1 not 7.1.0.

http://www.apache.org/dyn/closer.lua/lucene/solr/7.0.1




On Tue, Oct 17, 2017 at 5:28 AM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> 17 October 2017, Apache Solr™ 7.1.0 available
>
> The Lucene PMC is pleased to announce the release of Apache Solr 7.1.0
>
> Solr is the popular, blazing fast, open source NoSQL search platform
> from the Apache Lucene project. Its major features include powerful
> full-text search, hit highlighting, faceted search, dynamic
> clustering, database integration, rich document (e.g., Word, PDF)
> handling, and geospatial search. Solr is highly scalable, providing
> fault tolerant distributed search and indexing, and powers the search
> and navigation features of many of the world's largest internet sites.
>
> Solr 7.1.0 is available for immediate download at:
>
> http://lucene.apache.org/solr/mirrors-solr-latest-redir.html
>
> See http://lucene.apache.org/solr/7_1_0/changes/Changes.html for a
> full list of details.
>
> Solr 7.1.0 Release Highlights:
>
> * Critical Security Update: Fix for CVE-2017-12629 which is a working
> 0-day exploit reported on the public mailing list. See
> https://s.apache.org/FJDl
>
> * Auto-scaling: Solr can now move replicas automatically when a new
> node is added or an existing node is removed using the auto scaling
> policy framework introduced in 7.0
>
> * Auto-scaling: The 'autoAddReplicas' feature which was limited to
> shared file systems is now available for all file systems. It has been
> ported to use the new autoscaling framework internally.
>
> * Auto-scaling: New set-trigger, remove-trigger, set-listener,
> remove-listener, suspend-trigger, resume-trigger APIs
>
> * Auto-scaling: New /autoscaling/history API to show past autoscaling
> actions and cluster events
>
> * New JSON based Query DSL for Solr that extends JSON Request API to
> also support all query parsers and their nested parameters
>
> * JSON Facet API: min/max aggregations are now supported on
> single-valued date fields
>
> * Lucene's Geo3D (surface of sphere & ellipsoid) is now supported on
> spatial RPT fields by setting spatialContextFactory="Geo3D".
> Furthermore, this is the first time Solr has out of the box support
> for polygons
>
> * Expanded support for statistical stream evaluators such as various
> distributions, rank correlations, distances and more.
>
> * Multiple other optimizations and bug fixes
>
> You are encouraged to thoroughly read the "Upgrade Notes" at
> http://lucene.apache.org/solr/7_1_0/changes/Changes.html or in the
> CHANGES.txt file accompanying the release.
>
> Solr 7.1 also includes many other new features as well as numerous
> optimizations and bugfixes of the corresponding Apache Lucene release.
>
> Please report any feedback to the mailing lists
> (http://lucene.apache.org/solr/discussion.html)
>
> Note: The Apache Software Foundation uses an extensive mirroring
> network for distributing releases. It is possible that the mirror you
> are using may not have replicated the release yet. If that is the
> case, please try another mirror. This also goes for Maven access.
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Release 7.1

[Susheel Kumar]

+1 to get out 7.1.

On Tue, Oct 10, 2017 at 9:56 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> +1
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Mon, Oct 9, 2017 at 11:54 AM, Shalin Shekhar Mangar 
> wrote:
>
>> Hello,
>>
>> The 7.0 release took much longer than anticipated so I would like to
>> push a 7.1 release on a more aggressive schedule than usual.
>>
>> I've already pushed branch_7_1 created from branch_7x a few minutes
>> back. If no one has any objections, I'd like to cut the first RC after
>> 24 hours from this email.
>>
>> No new features should be pushed to branch_7_1. Critical bug fixes or
>> test fixes only at this point, please.
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>

[jira] [Updated] (SOLR-10932) install solr service service command fails

[Susheel Kumar (JIRA)]

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

Susheel Kumar updated SOLR-10932:
-
Attachment: SOLR-10932.patch

Attach patch to get rid of error "Script requires the 'service' command" on 
Suse-distribution.  Based on Shawn's test results, the "service --help" 
commands works on most of the distributions then "service --version".

Can we get this committed as this is a simple fix and with every new release 
the installation script fails on Suse-distribution

> install solr service service command fails
> --
>
> Key: SOLR-10932
> URL: https://issues.apache.org/jira/browse/SOLR-10932
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>     Environment: Suse linux
>Reporter: Susheel Kumar
>Priority: Minor
>  Labels: easyfix, newbie, patch
> Attachments: SOLR-10932.patch
>
>
> In SUSE distribution,  "service --version" commands always fail and abort the 
> solr installation with printing the error  "Script requires the 'service' 
> command" 
> We can fix it by changing "service --version" to "service --help" command. 
> Shawn's test results
> ==
> This is what I get with OS versions that I have access to when running
> "service --version":
> CentOS 7:
> service ver. 1.1
> Ubuntu 16:
> service ver. 0.91-ubuntu1
> Ubuntu 14:
> service ver. 0.91-ubuntu1
> CentOS 6:
> service ver. 0.91
> Debian 6:
> service ver. 0.91-ubuntu1
> Sparc Solaris 10:
> bash: service: command not found
> =



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10932) install solr service service command fails

[Susheel Kumar (JIRA)]

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

Susheel Kumar updated SOLR-10932:
-
Flags: Patch

> install solr service service command fails
> --
>
> Key: SOLR-10932
> URL: https://issues.apache.org/jira/browse/SOLR-10932
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
> Environment: Suse linux
>    Reporter: Susheel Kumar
>Priority: Minor
>  Labels: easyfix, newbie, patch
>
> In SUSE distribution,  "service --version" commands always fail and abort the 
> solr installation with printing the error  "Script requires the 'service' 
> command" 
> We can fix it by changing "service --version" to "service --help" command. 
> Shawn's test results
> ==
> This is what I get with OS versions that I have access to when running
> "service --version":
> CentOS 7:
> service ver. 1.1
> Ubuntu 16:
> service ver. 0.91-ubuntu1
> Ubuntu 14:
> service ver. 0.91-ubuntu1
> CentOS 6:
> service ver. 0.91
> Debian 6:
> service ver. 0.91-ubuntu1
> Sparc Solaris 10:
> bash: service: command not found
> =



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10944) Get expression fails to return EOF tuple

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-10944:
--

Thank you so much, Joel.

> Get expression fails to return EOF tuple 
> -
>
> Key: SOLR-10944
> URL: https://issues.apache.org/jira/browse/SOLR-10944
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>    Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: patch
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10944.patch
>
>
> Below is a simple let expr where search would not find a match and return 0 
> result.  In that case, we expect get(a) to show a EOF tuple while it is 
> throwing exception.
> ===
> let(a=search(collection1,
> q=id:9, 
> fl="id,business_email",
> sort="business_email asc"),
> get(a)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Index: 0, Size: 0",
> "EOF": true,
> "RESPONSE_TIME": 8
>   }
> ]
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Request for Lucene.net 4.8 Beta for .Net Core

[Susheel Kumar]

You also have the option to use Solr which is wrapper around Lucene and
make calls to Solr using Http Rest API.  That way you get to use latest and
greatest version of Solr/lucene.

Thanks,
Susheel

On Mon, Jul 24, 2017 at 4:43 PM, Chris Hostetter 
wrote:

>
> Lucene.Net is a fully distinct Apache project with completely
> independent developer/user communities, mailing lists, source code
> repository, and releases...
>
> https://lucenenet.apache.org/community.html
>
>
>
>
> : Date: Mon, 24 Jul 2017 21:56:17 +0530
> : From: rohit kumar 
> : Reply-To: dev@lucene.apache.org
> : To: dev@lucene.apache.org
> : Cc: Mohan Jaganathan 
> : Subject: Request for Lucene.net 4.8 Beta for .Net Core
> :
> : Hi,
> :
> : I am Rohit Kumar Rapolu from Hyderabad, India.  We are working on our
> : academic project which is web application on .net core framework.  We
> : trying to implement full text search in our application.  We heard Lucene
> : is the best for it.  Could we have Lucene 4.8 Beta version which supports
> : on .net core 1.1 framework.  Could you please help us on this.
> :
> :
> : Regards
> :
> : --
> :
> : *RegardsRohit*
> :
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-10944) Get expression fails to return EOF tuple

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-10944:
--

Hi Joel,

I finally have a complex streaming expression for solving my use case but it 
all relies on this simple fix. Would you be able to review/commit this patch so 
that i can look forward for 7.x release to use.

Thanks,
Susheel


  

> Get expression fails to return EOF tuple 
> -
>
> Key: SOLR-10944
> URL: https://issues.apache.org/jira/browse/SOLR-10944
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>    Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: patch
> Attachments: SOLR-10944.patch
>
>
> Below is a simple let expr where search would not find a match and return 0 
> result.  In that case, we expect get(a) to show a EOF tuple while it is 
> throwing exception.
> ===
> let(a=search(collection1,
> q=id:9, 
> fl="id,business_email",
> sort="business_email asc"),
> get(a)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Index: 0, Size: 0",
> "EOF": true,
> "RESPONSE_TIME": 8
>   }
> ]
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Add "Streaming Expressions" to component(s) list in JIRA

[Susheel Kumar]

Thanks, Cassandra.

On Thu, Jul 20, 2017 at 4:33 PM, Cassandra Targett <casstarg...@gmail.com>
wrote:

> I'm +1 on this, so I added it. Sorry for the delay Susheel.
>
> On Fri, Jun 23, 2017 at 3:31 PM, Susheel Kumar <susheel2...@gmail.com>
> wrote:
> > While filing JIRA for streaming expressions, there is no such component
> to
> > selelct.  Can we add "Streaming Expressions" to the components list.
> >
> > Thanks,
> > Susheel
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-10944) Get expression fails to return EOF tuple

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-10944:
--

Hi Joel,

Can you please review the patch, suggest any changes and commit to have it in 
next 7.x release.  This will be a simple fix but is very much required in 
simple to complex expressions involving Get expressions.

Thanks,
Susheel

> Get expression fails to return EOF tuple 
> -
>
> Key: SOLR-10944
> URL: https://issues.apache.org/jira/browse/SOLR-10944
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>    Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: patch
> Attachments: SOLR-10944.patch
>
>
> Below is a simple let expr where search would not find a match and return 0 
> result.  In that case, we expect get(a) to show a EOF tuple while it is 
> throwing exception.
> ===
> let(a=search(collection1,
> q=id:9, 
> fl="id,business_email",
> sort="business_email asc"),
> get(a)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Index: 0, Size: 0",
> "EOF": true,
> "RESPONSE_TIME": 8
>   }
> ]
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11017) Add support for unique metric to facet streaming function

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-11017:


 Summary: Add support for unique metric to facet streaming function
 Key: SOLR-11017
 URL: https://issues.apache.org/jira/browse/SOLR-11017
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Affects Versions: 6.6
Reporter: Susheel Kumar


Add support for Unique metric to facet function which under the cover utilizes 
JSON Facet API.

The challenge is to come up with a keyword which can be used for UniqueMetric. 
Currently "unique" is used for UniqueStream and can't be utilized.  

Does "uniq" make sense? 

...
...
  StreamFactory factory = new StreamFactory()
  .withCollectionZkHost (...) 
   .withFunctionName("facet", FacetStream.class)
  .withFunctionName("sum", SumMetric.class)
  .withFunctionName("unique", UniqueStream.class)
  .withFunctionName("unique", UniqueMetric.class)
...
...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10945) Get expression fails to operate on sort expr

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-10945:
--

Hi Joel - I looked the code to debug this issue and here is what i found

The above two expressions (...merge(get(a)... or ...merge(sort(get(a)...) which 
are similar (mathematically/syntactically/functionally) as a whole,  but the 
one which fails where merge is passed get(a) directly, results into error since 
GetStream is passed in the merge init method and GetStream.getStreamSort() 
method returns null (below) while in the other case SortStream is passed  its 
getStreamSort() method returns proper comparator.  

Wondering how can we handle this either by passing StreamComparator to 
GetStream (and how) or do something in merge to not upfront check.  Please 
share your thoughts

  /** Return the stream sort - ie, the order in which records are returned */
  public StreamComparator getStreamSort(){
return null;
  }

MergeStream
--
 private void init(StreamComparator comp, TupleStream ... streams) throws 
IOException {

// All streams must both be sorted so that comp can be derived from
for(TupleStream stream : streams){
  if(!comp.isDerivedFrom(stream.getStreamSort())){
throw new IOException("Invalid MergeStream - all substream comparators 
(sort) must be a superset of this stream's comparator.");
  }
}

> Get expression fails to operate on sort expr
> 
>
> Key: SOLR-10945
> URL: https://issues.apache.org/jira/browse/SOLR-10945
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Susheel Kumar
>Priority: Minor
>
> Get expr fails to operate on a variable which has sort stream and returns 
> "Invalid MergeStream - all substream comparators (sort) must be a superset of 
> this stream's comparator." Exception tuple.
> Below get is given variable a and b which are having sort expr and fails to 
> work
> ==
> let(
> a=sort(select(tuple(id=3,email="C"),id,email),by="id asc,email asc"),
> b=sort(select(tuple(id=2,email="B"),id,email),by="id asc,email asc"),
> c=merge(get(a),get(b),on="id asc,email asc"),
> get(c)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Invalid MergeStream - all substream comparators (sort) 
> must be a superset of this stream's comparator.",
> "EOF": true
>   }
> ]
>   }
> }
> while below sort outside get works
> ==
> let(
> a=select(tuple(id=3,email="C"),id,email),
> b=select(tuple(id=2,email="B"),id,email),
> c=merge(sort(get(a),by="id asc,email asc"),sort(get(b),by="id asc,email asc"),
> on="id asc,email asc"),
> get(c)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "email": "B",
> "id": "2"
>   },
>   {
> "email": "C",
> "id": "3"
>   },
>   {
> "EOF": true,
> "RESPONSE_TIME": 0
>   }
> ]
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10944) Get expression fails to return EOF tuple

[Susheel Kumar (JIRA)]

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

Susheel Kumar updated SOLR-10944:
-
Attachment: SOLR-10944.patch

Hello,

Attach is the patch where the below line causes "Index 0, Size 0" exception 
when get open the stream and since the list variable "l" has no elements, it 
throws error.

Added a test as well.  Please let me know if need to be handled differently

Bug
===
if(l.get(0) instanceof Tuple)

Fix
===
Simply assign the iterator then checking for and later read will check for EOF 

tupleIterator = l.iterator();




> Get expression fails to return EOF tuple 
> -
>
> Key: SOLR-10944
> URL: https://issues.apache.org/jira/browse/SOLR-10944
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: patch
> Attachments: SOLR-10944.patch
>
>
> Below is a simple let expr where search would not find a match and return 0 
> result.  In that case, we expect get(a) to show a EOF tuple while it is 
> throwing exception.
> ===
> let(a=search(collection1,
> q=id:9, 
> fl="id,business_email",
> sort="business_email asc"),
> get(a)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Index: 0, Size: 0",
> "EOF": true,
> "RESPONSE_TIME": 8
>   }
> ]
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Add "Streaming Expressions" to component(s) list in JIRA

[Susheel Kumar]

While filing JIRA for streaming expressions, there is no such component to
selelct.  Can we add "Streaming Expressions" to the components list.

Thanks,
Susheel

[jira] [Created] (SOLR-10945) Get expression fails to operate on sort expr

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-10945:


 Summary: Get expression fails to operate on sort expr
 Key: SOLR-10945
 URL: https://issues.apache.org/jira/browse/SOLR-10945
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: search
Affects Versions: 6.6
Reporter: Susheel Kumar
Priority: Minor


Get expr fails to operate on a variable which has sort stream and returns 
"Invalid MergeStream - all substream comparators (sort) must be a superset of 
this stream's comparator." Exception tuple.

Below get is given variable a and b which are having sort expr and fails to work
==
let(
a=sort(select(tuple(id=3,email="C"),id,email),by="id asc,email asc"),
b=sort(select(tuple(id=2,email="B"),id,email),by="id asc,email asc"),
c=merge(get(a),get(b),on="id asc,email asc"),
get(c)
)

{
  "result-set": {
"docs": [
  {
"EXCEPTION": "Invalid MergeStream - all substream comparators (sort) 
must be a superset of this stream's comparator.",
"EOF": true
  }
]
  }
}

while below sort outside get works
==
let(
a=select(tuple(id=3,email="C"),id,email),
b=select(tuple(id=2,email="B"),id,email),
c=merge(sort(get(a),by="id asc,email asc"),sort(get(b),by="id asc,email asc"),
on="id asc,email asc"),
get(c)
)

{
  "result-set": {
"docs": [
  {
"email": "B",
"id": "2"
  },
  {
"email": "C",
"id": "3"
  },
  {
"EOF": true,
"RESPONSE_TIME": 0
  }
]
  }
}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10944) Get expression fails to return EOF tuple

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-10944:


 Summary: Get expression fails to return EOF tuple 
 Key: SOLR-10944
 URL: https://issues.apache.org/jira/browse/SOLR-10944
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: search
Affects Versions: 6.6
Reporter: Susheel Kumar
Priority: Blocker


Below is a simple let expr where search would not find a match and return 0 
result.  In that case, we expect get(a) to show a EOF tuple while it is 
throwing exception.

===
let(a=search(collection1,
q=id:9, 
fl="id,business_email",
sort="business_email asc"),
get(a)
)


{
  "result-set": {
"docs": [
  {
"EXCEPTION": "Index: 0, Size: 0",
"EOF": true,
"RESPONSE_TIME": 8
  }
]
  }
}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10933) LetStream variables are not evaluated in proper order

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-10933:
--

You saved my day, Joel. I was struggling on this bit and after noticing this 
issue, i changed my variables to single alphabet the problem disappeared.

let(a=fetch(collection1,having(rollup(over=email,
 count(email),
select(search(collection1,
q=*:*,
fl="id,business_email",
sort="business_email asc"),
   id,
   business_email as email)),
eq(count(email),1)),
fl="id,business_email as email",
on="email=business_email"),
b=fetch(collection1,having(rollup(over=email,
 count(email),
select(search(collection1,
q=*:*,
fl="id,personal_email",
sort="personal_email asc"),
   id,
   personal_email as email)),
eq(count(email),1)),
fl="id,personal_email as email",
on="email=personal_email"),
c=hashJoin(get(a),hashed=get(b),on="email"),
d=hashJoin(get(b),hashed=get(a),on="email"),
e=select(get(a),id,email),
get(e)
)

> LetStream variables are not evaluated in proper order
> -
>
> Key: SOLR-10933
> URL: https://issues.apache.org/jira/browse/SOLR-10933
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10933.patch
>
>
> The LetStream is currently using a HashMap to hold its variable mappings. 
> This is problematic because the ordering of the variables will be lost as 
> they are evaluated. The test cases pass currently because single letter 
> variables in ascending order are used which by luck caused the variables to 
> be evaluated in order.
> There is a very simple fix for this which is to use a LinkedHashMap to hold 
> the variables to ensure they are evaluated in the order that they are 
> received.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10932) install solr service service command fails

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-10932:


 Summary: install solr service service command fails
 Key: SOLR-10932
 URL: https://issues.apache.org/jira/browse/SOLR-10932
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.6
 Environment: Suse linux
Reporter: Susheel Kumar
Priority: Minor


In SUSE distribution,  "service --version" commands always fail and abort the 
solr installation with printing the error  "Script requires the 'service' 
command" 

We can fix it by changing "service --version" to "service --help" command. 

Shawn's test results
==
This is what I get with OS versions that I have access to when running
"service --version":

CentOS 7:
service ver. 1.1

Ubuntu 16:
service ver. 0.91-ubuntu1

Ubuntu 14:
service ver. 0.91-ubuntu1

CentOS 6:
service ver. 0.91

Debian 6:
service ver. 0.91-ubuntu1

Sparc Solaris 10:
bash: service: command not found

=



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10890) Parallel SQL - column not found error

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-10890:


 Summary: Parallel SQL - column not found error
 Key: SOLR-10890
 URL: https://issues.apache.org/jira/browse/SOLR-10890
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Parallel SQL
Affects Versions: 6.6
Reporter: Susheel Kumar
Priority: Minor


Parallel SQL throws "column not found" error when the query hits multiple 
shards and one of shard doesn't have any documents yet. 

Sample error
== 
{"result-set":{"docs":[{"EXCEPTION":"Failed to execute sqlQuery 'SELECT  
sr_sv_userFirstName as firstName, sr_sv_userLastName as lastName FROM 
collection1 ORDEr BY dv_sv_userLastName LIMIT 15' against JDBC connection 
'jdbc:calcitesolr:'.\nError while executing SQL \"SELECT  sr_sv_userFirstName 
as firstName, sr_sv_userLastName as lastName FROM collection1 ORDEr BY 
dv_sv_userLastName LIMIT 15\": From line 1, column 9 to line 1, column 27: 
Column 'sr_sv_userFirstName' not found in any 
table","EOF":true,"RESPONSE_TIME":87}]}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Face the issues to setup solr with zookeeper

[Susheel Kumar]

Also use solr-user mailing list for general issues / queries / questions
and please subscribe and repost this to solr-u...@lucene.apache.org

Refer http://lucene.apache.org/solr/community.html

Thanks,
Susheel

On Wed, Jun 7, 2017 at 9:29 AM, Susheel Kumar <susheel2...@gmail.com> wrote:

> Please provide more detail on the issue you are facing.  See if this blog
> helps you, http://blog.thedigitalgroup.com/susheelk/2015/08/03/
> solrcloud-2-nodes-solr-1-node-zk-setup/
>
> On Wed, Jun 7, 2017 at 8:56 AM, Gurmeet Singh <gurmeet2010...@gmail.com>
> wrote:
>
>> Hi Sir/Mam
>>
>> Please help me to get out of problem.
>>
>> Thanks
>>
>>
>

Re: Face the issues to setup solr with zookeeper

[Susheel Kumar]

Please provide more detail on the issue you are facing.  See if this blog
helps you,
http://blog.thedigitalgroup.com/susheelk/2015/08/03/solrcloud-2-nodes-solr-1-node-zk-setup/


On Wed, Jun 7, 2017 at 8:56 AM, Gurmeet Singh 
wrote:

> Hi Sir/Mam
>
> Please help me to get out of problem.
>
> Thanks
>
>

Re: Question on Solr

[Susheel Kumar]

Hello Prathib,

This is how I would go.  Will index these XML's as flat records/plain data
in Solr and then during query time search these records.  Converting xml's
to plain data in the form of key/ value pair will be done during ingestion
time and then during query if you have to present results into XML format,
you can again apply the XML transformation.

Basically search XML snippets is more or less a text search which is what
Solr is about.  You can utilise nested documents in Solr to fit your need.

Thanks,
Susheel

On Tue, Feb 14, 2017 at 7:39 PM, Prathib Kumar  wrote:

> Hi,
>
> We are evaluating solr to see if it can help to do a search of the xml
> snippets from the whole xml doc.
>
> For Ex:
> Document-1:
>
> 
>Prathib
>Java
>san jose
> CA
> 
>
> Document-2:
> 
>Joe
>C++
>chennai
> TN
> 
>
> Document-3:
> 
>Ramu
>Python
>LosAngeles
> CA
> 
>
>
> My Search string is another XML doc which could be like.
>
> Query-1:
> 
>  san jose
> 
>
> Query-2:
> 
>CA
> 
>
> I have broken this down for simplicity, in reality our xmls are nested and
> have many attributes on each tag.
>
> To continue the evaluation of solr, can you please help me from where I
> could start the analysis ?
>
> Note : currently our xml document doesnt adhere to any schema but we could
> create a schema if required.
>
>
>
> Regards
> Prathib Kumar.
>
>

[jira] [Commented] (SOLR-10086) Add Streaming Expression for Kafka Streams

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-10086:
--

Thanks, Kevin for putting the example and steps together (SOLR-10087).  Are we 
looking to put these custom streaming expressions code i.e. especially these 
common one like kafka etc.  under Solr repo (or contrib etc.) or its upto the 
users to maintain it. 

> Add Streaming Expression for Kafka Streams
> --
>
> Key: SOLR-10086
> URL: https://issues.apache.org/jira/browse/SOLR-10086
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>    Reporter: Susheel Kumar
>Priority: Minor
>
> This is being asked to have SolrCloud pull data from Kafka topic periodically 
> using DataImport Handler. 
> Adding streaming expression support to pull data from Kafka would be good 
> feature to have.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10086) Add Streaming Expression for Kafka Streams

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-10086:


 Summary: Add Streaming Expression for Kafka Streams
 Key: SOLR-10086
 URL: https://issues.apache.org/jira/browse/SOLR-10086
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrJ
Reporter: Susheel Kumar
Priority: Minor


This is being asked to have SolrCloud pull data from Kafka topic periodically 
using DataImport Handler. 

Adding streaming expression support to pull data from Kafka would be good 
feature to have.  




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: 6.3.0

[Susheel Kumar]

+1 but looking to have SOLR-9399
 (currently open) to be
included with 6.3 to support delete requests with Basic Authentication
enabled.

On Wed, Oct 26, 2016 at 3:39 PM, Erick Erickson 
wrote:

> I'd like to get SOLR-9166 in, we'll see if I can get moving enough there.
>
> Erick
>
> On Wed, Oct 26, 2016 at 8:21 AM, Joel Bernstein 
> wrote:
> > I have a couple of issues to commit which I plan on doing today. +1 for
> RC
> > Monday.
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Oct 26, 2016 at 11:16 AM, Michael McCandless
> >  wrote:
> >>
> >> +1
> >>
> >> Mike McCandless
> >>
> >> http://blog.mikemccandless.com
> >>
> >>
> >> On Wed, Oct 26, 2016 at 4:46 AM, Shalin Shekhar Mangar
> >>  wrote:
> >> > It looks like 6.3.0 has accumulated enough new features, optimizations
> >> > and
> >> > fixes. How do folks feel about pushing this release out?
> >> >
> >> > I volunteer to be the RM. If there are no objections, I'd like to put
> >> > the
> >> > first RC to vote on Monday.
> >> >
> >> > --
> >> > Regards,
> >> > Shalin Shekhar Mangar.
> >>
> >> -
> >> 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: [jira] [Commented] (SOLR-9399) Delete requests do not send credentials & fails for Basic Authentication

[Susheel Kumar]

Hello Jan,

Can this one line change in UpdateRequest.java be included for 6.3 release
while we continue to improve/fix the unit tests.  The unit tests are also
added but somehow they do not fail correctly.

We really wanted to have this change SOLR-9399
<https://issues.apache.org/jira/browse/SOLR-9399> (delete requests to
include auth credentials) and SOLR-9188 (blockUnknown property...) to be in
6.3 release to be able to setup Basic Authentication in our Solr cluster.

Thanks,
Susheel

On Fri, Oct 21, 2016 at 8:45 AM, Susheel Kumar <susheel2...@gmail.com>
wrote:

> and this behavior of not failing update.process() with bad credentials
> only seen within the test / for the test cluster created within the
> BasicAuthIntegrationTest.  If I point it to external cluster, the same code
>  i.e. update.process() fails for bad credentials.  Something is weird /
> missing in test.  I debugged deep to the SolrHttpClient yesterday which
> ultimately sends the update POST request  and it returns 200 status when
> run from BasicAuthIntegrationTest while same returns 401 when point
> to external cluster.  Does that tells anything. Not sure if retry/PKI auth
> may have any role.
>
> HttpSolrClient.java
>
> ---
>
>  final HttpResponse response = httpClient.execute(method, ht
> tpClientRequestContext);
>
>  int httpStatus = response.getStatusLine().getStatusCode();
>
> On Fri, Oct 21, 2016 at 7:59 AM, Jan Høydahl (JIRA) <j...@apache.org>
> wrote:
>
>>
>> [ https://issues.apache.org/jira/browse/SOLR-9399?page=com.
>> atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
>> l=15594893#comment-15594893 ]
>>
>> Jan Høydahl commented on SOLR-9399:
>> ---
>>
>> Did some more testing and managed to have the CloudSolrClient actually
>> fail with 401, but only when calling update.commit() and patching
>> CloudSolrClient, adding in line 799
>> {code}
>> 
>> nonRoutableRequest.setBasicAuthCredentials(updateRequest.getBasicAuthUser(),
>> updateRequest.getBasicAuthPassword());
>> {code}
>>
>> However, when calling update.process() the update request succeeds even
>> with wrong credentials. I even verified that the doc gets added/deleted
>> from the index when using wrong credentials. The process() method is using
>> some retry logic, could it be that the retry succeeds using PKI auth?
>>
>> > Delete requests do not send credentials & fails for Basic Authentication
>> > 
>> 
>> >
>> > Key: SOLR-9399
>> > URL: https://issues.apache.org/jira/browse/SOLR-9399
>> > Project: Solr
>> >  Issue Type: Bug
>> >  Security Level: Public(Default Security Level. Issues are Public)
>> >  Components: SolrJ
>> >Affects Versions: 6.0, 6.0.1, 6.x
>> >Reporter: Susheel Kumar
>> >  Labels: security
>> >
>> > The getRoutes(..) func of UpdateRequest do not pass credentials to
>> LBHttpSolrClient when deleteById is set while for updates it passes the
>> credentials.  See below code snippet
>> >   if (deleteById != null) {
>> >
>> >   Iterator<Map.Entry<String,Map<String,Object>>> entries =
>> deleteById.entrySet()
>> >   .iterator();
>> >   while (entries.hasNext()) {
>> >
>> > Map.Entry<String,Map<String,Object>> entry = entries.next();
>> >
>> > String deleteId = entry.getKey();
>> > Map<String,Object> map = entry.getValue();
>> > Long version = null;
>> > if (map != null) {
>> >   version = (Long) map.get(VER);
>> > }
>> > Slice slice = router.getTargetSlice(deleteId, null, null,
>> null, col);
>> > if (slice == null) {
>> >   return null;
>> > }
>> > List urls = urlMap.get(slice.getName());
>> > if (urls == null) {
>> >   return null;
>> > }
>> > String leaderUrl = urls.get(0);
>> > LBHttpSolrClient.Req request = routes.get(leaderUrl);
>> > if (request != null) {
>> >   UpdateRequest urequest = (UpdateRequest) request.getRequest();
>> >   urequest.deleteById(deleteId, version);
>> > } else {
>> >   UpdateRequest urequest = new UpdateRequest();
>> >   urequest.setParams(params);
>> >   urequest.deleteById(deleteId, version);
>> >   urequest.setCommitWithin(getCommitWithin());
>> >   request = new LBHttpSolrClient.Req(urequest, urls);
>> >   routes.put(leaderUrl, request);
>> > }
>> >   }
>> > }
>>
>>
>>
>> --
>> 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: [jira] [Commented] (SOLR-9188) BlockUnknown property makes inter-node communication impossible

[Susheel Kumar]

Hello,

I will also test this on my side as this is something blocked us to
implement authentication all the way upto Prod. I believe I can take the
latest source from master and build and test this out.

Thanks,
Susheel

On Wed, Oct 26, 2016 at 8:39 AM, Ewen Cluley (JIRA)  wrote:

>
> [ https://issues.apache.org/jira/browse/SOLR-9188?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15608337#comment-15608337 ]
>
> Ewen Cluley commented on SOLR-9188:
> ---
>
> Awesome.  Will deploy the patch on top of my 6.2.1 and test that it
> resolved the issue for me.  Thanks
>
> > BlockUnknown property makes inter-node communication impossible
> > ---
> >
> > Key: SOLR-9188
> > URL: https://issues.apache.org/jira/browse/SOLR-9188
> > Project: Solr
> >  Issue Type: Bug
> >  Components: SolrCloud
> >Affects Versions: 6.0
> >Reporter: Piotr Tempes
> >Assignee: Noble Paul
> >Priority: Critical
> >  Labels: BasicAuth, Security
> > Fix For: 6.3, master (7.0)
> >
> > Attachments: SOLR-9188.patch, solr9188-errorlog.txt
> >
> >
> > When I setup my solr cloud without blockUnknown property it works as
> expected. When I want to block non authenticated requests I get following
> stacktrace during startup (see attached file).
>
>
>
> --
> 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: [jira] [Commented] (SOLR-9399) Delete requests do not send credentials & fails for Basic Authentication

[Susheel Kumar]

and this behavior of not failing update.process() with bad credentials only
seen within the test / for the test cluster created within the
BasicAuthIntegrationTest.  If I point it to external cluster, the same code
 i.e. update.process() fails for bad credentials.  Something is weird /
missing in test.  I debugged deep to the SolrHttpClient yesterday which
ultimately sends the update POST request  and it returns 200 status when
run from BasicAuthIntegrationTest while same returns 401 when point
to external cluster.  Does that tells anything. Not sure if retry/PKI auth
may have any role.

HttpSolrClient.java

---

 final HttpResponse response = httpClient.execute(method,
httpClientRequestContext);

 int httpStatus = response.getStatusLine().getStatusCode();

On Fri, Oct 21, 2016 at 7:59 AM, Jan Høydahl (JIRA) <j...@apache.org> wrote:

>
> [ https://issues.apache.org/jira/browse/SOLR-9399?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15594893#comment-15594893 ]
>
> Jan Høydahl commented on SOLR-9399:
> ---
>
> Did some more testing and managed to have the CloudSolrClient actually
> fail with 401, but only when calling update.commit() and patching
> CloudSolrClient, adding in line 799
> {code}
> 
> nonRoutableRequest.setBasicAuthCredentials(updateRequest.getBasicAuthUser(),
> updateRequest.getBasicAuthPassword());
> {code}
>
> However, when calling update.process() the update request succeeds even
> with wrong credentials. I even verified that the doc gets added/deleted
> from the index when using wrong credentials. The process() method is using
> some retry logic, could it be that the retry succeeds using PKI auth?
>
> > Delete requests do not send credentials & fails for Basic Authentication
> > 
> >
> > Key: SOLR-9399
> > URL: https://issues.apache.org/jira/browse/SOLR-9399
> > Project: Solr
> >  Issue Type: Bug
> >  Security Level: Public(Default Security Level. Issues are Public)
> >  Components: SolrJ
> >Affects Versions: 6.0, 6.0.1, 6.x
> >Reporter: Susheel Kumar
> >  Labels: security
> >
> > The getRoutes(..) func of UpdateRequest do not pass credentials to
> LBHttpSolrClient when deleteById is set while for updates it passes the
> credentials.  See below code snippet
> >   if (deleteById != null) {
> >
> >   Iterator<Map.Entry<String,Map<String,Object>>> entries =
> deleteById.entrySet()
> >   .iterator();
> >   while (entries.hasNext()) {
> >
> > Map.Entry<String,Map<String,Object>> entry = entries.next();
> >
> > String deleteId = entry.getKey();
> > Map<String,Object> map = entry.getValue();
> > Long version = null;
> > if (map != null) {
> >   version = (Long) map.get(VER);
> > }
> > Slice slice = router.getTargetSlice(deleteId, null, null, null,
> col);
> > if (slice == null) {
> >   return null;
> > }
> > List urls = urlMap.get(slice.getName());
> > if (urls == null) {
> >   return null;
> > }
> > String leaderUrl = urls.get(0);
> > LBHttpSolrClient.Req request = routes.get(leaderUrl);
> > if (request != null) {
> >   UpdateRequest urequest = (UpdateRequest) request.getRequest();
> >   urequest.deleteById(deleteId, version);
> > } else {
> >   UpdateRequest urequest = new UpdateRequest();
> >   urequest.setParams(params);
> >   urequest.deleteById(deleteId, version);
> >   urequest.setCommitWithin(getCommitWithin());
> >   request = new LBHttpSolrClient.Req(urequest, urls);
> >   routes.put(leaderUrl, request);
> > }
> >   }
> > }
>
>
>
> --
> 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: [jira] [Commented] (SOLR-9399) Delete requests do not send credentials & fails for Basic Authentication

[Susheel Kumar]

Hi Jan, Alan,

I am having same issue, unable to make the delete/update/query tests fails
for basic authentication. Interestingly after setting up cluster,
collection and upload of security.json within the test and putting a
breakpoint, if i open the URL
"http://127.0.0.1:/solr/admin/authentication
thru browser / rest client it asks for credential but somehow the
HttpClient returns 200 even though with incorrect credential.

I thought HttpClient may be caching but it doesn't look like.  Here is the
updated pull request https://github.com/apache/lucene-solr/pull/69/files

Also the same code works if I point to my dev solr cluster/instance but
within test it doesn't.

HttpSolrClient.java

---

 final HttpResponse response = httpClient.execute(method,
httpClientRequestContext);

 int httpStatus = response.getStatusLine().getStatusCode();

On Thu, Oct 20, 2016 at 11:09 AM, Susheel Kumar (JIRA) <j...@apache.org>
wrote:

>
> [ https://issues.apache.org/jira/browse/SOLR-9399?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15592078#comment-15592078 ]
>
> Susheel Kumar commented on SOLR-9399:
> -
>
> I recall something similar experience but let me again look after test has
> been refactored to make it fail first.
>
>
>
>
> > Delete requests do not send credentials & fails for Basic Authentication
> > 
> >
> > Key: SOLR-9399
> > URL: https://issues.apache.org/jira/browse/SOLR-9399
> > Project: Solr
> >  Issue Type: Bug
> >  Security Level: Public(Default Security Level. Issues are Public)
> >  Components: SolrJ
> >Affects Versions: 6.0, 6.0.1, 6.x
> >Reporter: Susheel Kumar
> >  Labels: security
> >
> > The getRoutes(..) func of UpdateRequest do not pass credentials to
> LBHttpSolrClient when deleteById is set while for updates it passes the
> credentials.  See below code snippet
> >   if (deleteById != null) {
> >
> >   Iterator<Map.Entry<String,Map<String,Object>>> entries =
> deleteById.entrySet()
> >   .iterator();
> >   while (entries.hasNext()) {
> >
> > Map.Entry<String,Map<String,Object>> entry = entries.next();
> >
> > String deleteId = entry.getKey();
> > Map<String,Object> map = entry.getValue();
> > Long version = null;
> > if (map != null) {
> >   version = (Long) map.get(VER);
> > }
> > Slice slice = router.getTargetSlice(deleteId, null, null, null,
> col);
> > if (slice == null) {
> >   return null;
> > }
> > List urls = urlMap.get(slice.getName());
> > if (urls == null) {
> >   return null;
> > }
> > String leaderUrl = urls.get(0);
> > LBHttpSolrClient.Req request = routes.get(leaderUrl);
> > if (request != null) {
> >   UpdateRequest urequest = (UpdateRequest) request.getRequest();
> >   urequest.deleteById(deleteId, version);
> > } else {
> >   UpdateRequest urequest = new UpdateRequest();
> >   urequest.setParams(params);
> >   urequest.deleteById(deleteId, version);
> >   urequest.setCommitWithin(getCommitWithin());
> >   request = new LBHttpSolrClient.Req(urequest, urls);
> >   routes.put(leaderUrl, request);
> > }
> >   }
> > }
>
>
>
> --
> 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-9399) Delete requests do not send credentials & fails for Basic Authentication

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-9399:
-

I recall something similar experience but let me again look after test has
been refactored to make it fail first.




> Delete requests do not send credentials & fails for Basic Authentication
> 
>
> Key: SOLR-9399
> URL: https://issues.apache.org/jira/browse/SOLR-9399
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.0, 6.0.1, 6.x
>Reporter: Susheel Kumar
>  Labels: security
>
> The getRoutes(..) func of UpdateRequest do not pass credentials to 
> LBHttpSolrClient when deleteById is set while for updates it passes the 
> credentials.  See below code snippet
>   if (deleteById != null) {
>   
>   Iterator<Map.Entry<String,Map<String,Object>>> entries = 
> deleteById.entrySet()
>   .iterator();
>   while (entries.hasNext()) {
> 
> Map.Entry<String,Map<String,Object>> entry = entries.next();
> 
> String deleteId = entry.getKey();
> Map<String,Object> map = entry.getValue();
> Long version = null;
> if (map != null) {
>   version = (Long) map.get(VER);
> }
> Slice slice = router.getTargetSlice(deleteId, null, null, null, col);
> if (slice == null) {
>   return null;
> }
> List urls = urlMap.get(slice.getName());
> if (urls == null) {
>   return null;
> }
> String leaderUrl = urls.get(0);
> LBHttpSolrClient.Req request = routes.get(leaderUrl);
> if (request != null) {
>   UpdateRequest urequest = (UpdateRequest) request.getRequest();
>   urequest.deleteById(deleteId, version);
> } else {
>   UpdateRequest urequest = new UpdateRequest();
>   urequest.setParams(params);
>   urequest.deleteById(deleteId, version);
>   urequest.setCommitWithin(getCommitWithin());
>   request = new LBHttpSolrClient.Req(urequest, urls);
>   routes.put(leaderUrl, request);
> }
>   }
> }



--
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-9399) Delete requests do not send credentials & fails for Basic Authentication

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-9399:
-

I recall something similar experience but let me again look after test has
been refactored to make it fail first.




> Delete requests do not send credentials & fails for Basic Authentication
> 
>
> Key: SOLR-9399
> URL: https://issues.apache.org/jira/browse/SOLR-9399
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.0, 6.0.1, 6.x
>Reporter: Susheel Kumar
>  Labels: security
>
> The getRoutes(..) func of UpdateRequest do not pass credentials to 
> LBHttpSolrClient when deleteById is set while for updates it passes the 
> credentials.  See below code snippet
>   if (deleteById != null) {
>   
>   Iterator<Map.Entry<String,Map<String,Object>>> entries = 
> deleteById.entrySet()
>   .iterator();
>   while (entries.hasNext()) {
> 
> Map.Entry<String,Map<String,Object>> entry = entries.next();
> 
> String deleteId = entry.getKey();
> Map<String,Object> map = entry.getValue();
> Long version = null;
> if (map != null) {
>   version = (Long) map.get(VER);
> }
> Slice slice = router.getTargetSlice(deleteId, null, null, null, col);
> if (slice == null) {
>   return null;
> }
> List urls = urlMap.get(slice.getName());
> if (urls == null) {
>   return null;
> }
> String leaderUrl = urls.get(0);
> LBHttpSolrClient.Req request = routes.get(leaderUrl);
> if (request != null) {
>   UpdateRequest urequest = (UpdateRequest) request.getRequest();
>   urequest.deleteById(deleteId, version);
> } else {
>   UpdateRequest urequest = new UpdateRequest();
>   urequest.setParams(params);
>   urequest.deleteById(deleteId, version);
>   urequest.setCommitWithin(getCommitWithin());
>   request = new LBHttpSolrClient.Req(urequest, urls);
>   routes.put(leaderUrl, request);
> }
>   }
> }



--
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: [jira] [Commented] (SOLR-9399) Delete requests do not send credentials & fails for Basic Authentication

[Susheel Kumar]

Sure, let me look into the tests.

On Thu, Oct 20, 2016 at 9:06 AM, ASF GitHub Bot (JIRA) <j...@apache.org>
wrote:

>
> [ https://issues.apache.org/jira/browse/SOLR-9399?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15591769#comment-15591769 ]
>
> ASF GitHub Bot commented on SOLR-9399:
> --
>
> Github user romseygeek commented on the issue:
>
> https://github.com/apache/lucene-solr/pull/69
>
> Hi,
>
> BasicAuthIntegrationTest has been refactored since you opened this
> request, do you think you could try adding a test case in there now?
>
>
> > Delete requests do not send credentials & fails for Basic Authentication
> > 
> >
> > Key: SOLR-9399
> > URL: https://issues.apache.org/jira/browse/SOLR-9399
> > Project: Solr
> >  Issue Type: Bug
> >  Security Level: Public(Default Security Level. Issues are Public)
> >  Components: SolrJ
> >Affects Versions: 6.0, 6.0.1, 6.x
> >Reporter: Susheel Kumar
> >  Labels: security
> >
> > The getRoutes(..) func of UpdateRequest do not pass credentials to
> LBHttpSolrClient when deleteById is set while for updates it passes the
> credentials.  See below code snippet
> >   if (deleteById != null) {
> >
> >   Iterator<Map.Entry<String,Map<String,Object>>> entries =
> deleteById.entrySet()
> >   .iterator();
> >   while (entries.hasNext()) {
> >
> > Map.Entry<String,Map<String,Object>> entry = entries.next();
> >
> > String deleteId = entry.getKey();
> > Map<String,Object> map = entry.getValue();
> > Long version = null;
> > if (map != null) {
> >   version = (Long) map.get(VER);
> > }
> > Slice slice = router.getTargetSlice(deleteId, null, null, null,
> col);
> > if (slice == null) {
> >   return null;
> > }
> > List urls = urlMap.get(slice.getName());
> > if (urls == null) {
> >   return null;
> > }
> > String leaderUrl = urls.get(0);
> > LBHttpSolrClient.Req request = routes.get(leaderUrl);
> > if (request != null) {
> >   UpdateRequest urequest = (UpdateRequest) request.getRequest();
> >   urequest.deleteById(deleteId, version);
> > } else {
> >   UpdateRequest urequest = new UpdateRequest();
> >   urequest.setParams(params);
> >   urequest.deleteById(deleteId, version);
> >   urequest.setCommitWithin(getCommitWithin());
> >   request = new LBHttpSolrClient.Req(urequest, urls);
> >   routes.put(leaderUrl, request);
> > }
> >   }
> > }
>
>
>
> --
> 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: [GitHub] lucene-solr issue #66: SOLR-8146: Allowing SolrJ CloudSolrClient to have pre...

[Susheel Kumar]

Hello Noble,

I have merged the routingRule changes on the refactored latest code, have
added ClientSnitchContext class. Please have a look.

 https://github.com/apache/lucene-solr/pull/66

Thanks,
Susheel

On Sat, Oct 8, 2016 at 12:11 PM, susheelks  wrote:

> Github user susheelks commented on the issue:
>
> https://github.com/apache/lucene-solr/pull/66
>
> Merged routingRule changes after latest refactored code
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [DISCUSS] JIRA maintenance and response times

[Susheel Kumar]

I also agree with Alex regarding tagging the issues and perhaps if
possible/known, tag the effort/complexity level (high, medium, easy or
beginner/seasoned etc.) that new comers can also contribute. This may help
to get the low-hanging fruits to get done quicker and close some of them.


Thanks,
Susheel

On Sun, Oct 2, 2016 at 9:38 PM, Alexandre Rafalovitch 
wrote:

> I think the first step should be about increasing visibility rather than
> enforcing transition rules (so the report and reminder part).
>
> I've just been looking into Jira's reporting and it is quite flexible, but
> takes a while to wrap a mind around. Somebody digging in and coming up with
> great Solr-specific dashboards might be a way forward. People who are
> interested could then add them to their own screens.
>
> The next step would be to take those dashboards and run them centrally
> (e.g. on Amazon/Google AppEngine) with per-user information, to avoid those
> users needing to do the configuration.
>
> The next (or alternative) step would be to export JIRA data and do
> information crunching that the built-in reporting currently does not do.
> Reports I am specifically thinking about:
> *) Issues open for more than X days, in which the only activity
> (description+comments) comes from an original author. This would catch the
> issues nobody replied to yet
> *) Issues opened by a non-committer (to let people see the external
> community contribution and do triage/first-response)
> *) Issues where "I" made the last comment and X amount of time passed
> since - useful for "next action" reminders
> *) Issues older than X days that have '*.patch' attachment file (as
> opposed to random attachment)
>
> None of the above needs INFRA, as Jira will happily export up to ~200
> issues with full details per API call. I am doing some real basic
> exploration about it right now.
>
> I also mentioned before, but perhaps not in this discussion, that it would
> be really nice to have some clarity/improvements on tagging the issues. For
> example, I want to tag all Admin UI issues, but not sure what the right tag
> would be. I could of course come up with one myself, but the joke about
> having one-more standard worries me. I would be happier to work within some
> sort of consent-oriented taxonomy. Though, this could be just my problem,
> because I am choosing to do lower-hanging fruits over multiple components
> rather than dark magic in selected few.
>
> > We already have the “Later” resolution (6
> 
>  issues
> in Solr, 14
> 
>  in
> Lucene).
> I've just tried closing SOLR-373. I don't think it worked the way I
> thought it would work. It is now closed but still with the Resolution
> "later". UI did not give me an easy option to edit that as I close. I think
> "Later" may work better as the Status field (So, Opened, Reopened, Later,
> Closed), but I am not sure INFRA would want to change that.
>
> Regards,
>Alex.
>
>
> 
> Newsletter and resources for Solr beginners and intermediates:
> http://www.solr-start.com/
>
> On 3 October 2016 at 03:23, Jan Høydahl  wrote:
>
>> 29. sep. 2016 kl. 19.35 skrev Cassandra Targett :
>>
>> ...
>>
>> I fear a 7-day respond-or-close policy would frustrate people more.
>> Users would see their issues now closed instead of just ignored, and
>> if it gets a +1 from someone to stay open, it can still sit for the
>> next 5 years the same way as today. We need to take that idea a step
>> further.
>>
>>
>> My 7-day comment was not a proposal to auto-close, but as some kind
>> of internal goal of the community.
>>
>> What would I suggest instead? Not sure. One very small suggestion is
>> to add to Stefan's idea and send out a weekly mail about age of issues
>> - # of issues over 6 months, % increase/decrease, # of bugs with no
>> action in X days, # of improvements with patches that have no action
>> in X days.
>>
>>
>> Yes! A bigger ambition is to write a Python script that monitors and
>> enforces our agreed-upon rules and thresholds. If INFRA will give us
>> a user with API access for our projects we have ability to script just
>> about anything.
>>
>> In addition to generating a weekly mail report, the lucene_jira.py script
>> could also perform various actions proactively and automatically
>>
>> See sample state diagram: (https://dl.dropboxusercontent
>> .com/u/20080302/lucene_jira_states.png)
>>
>> The diagram suggests a custom automatic state transition by the script.
>> Issues older than 6m with no comments in 30d will receive a comment
>> “Issue seems to be inactive, will auto-close in 30d unless new activity.
>> If you want to close for now but be reminded in 12months, please close
>> manually with resolution=Later”.
>> The script will then tag the issue 

[jira] [Commented] (SOLR-8146) Allowing SolrJ CloudSolrClient to have preferred replica for query/read

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-8146:
-

Thank you, Noble. I am going thru the changes and will get back to you.

> Allowing SolrJ CloudSolrClient to have preferred replica for query/read
> ---
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch, 
> SOLR-8146.patch
>
>
> h2. Backgrouds
> Currently, the CloudSolrClient randomly picks a replica to query.
> This is done by shuffling the list of live URLs to query then, picking the 
> first item from the list.
> This ticket is to allow more flexibility and control to some extend which 
> URLs will be picked up for queries.
> Note that this is for queries only and would not affect update/delete/admin 
> operations.
> h2. Implementation
> The current patch uses regex pattern and moves to the top of the list of URLs 
> only those matching the given regex specified by the system property 
> {code}solr.preferredQueryNodePattern{code}
> Initially, I thought it may be good to have Solr nodes tagged with a string 
> pattern (snitch?) and use that pattern for matching the URLs.
> Any comment, recommendation or feedback would be appreciated.
> h2. Use Cases
> There are many cases where the ability to choose the node where queries go 
> can be very handy:
> h3. Special node for manual user queries and analytics
> One may have a SolrCLoud cluster where every node host the same set of 
> collections with:  
> - multiple large SolrCLoud nodes (L) used for production apps and 
> - have 1 small node (S) in the same cluster with less ram/cpu used only for 
> manual user queries, data export and other production issue investigation.
> This ticket would allow to configure the applications using SolrJ to query 
> only the (L) nodes
> This use case is similar to the one described in SOLR-5501 raised by [~manuel 
> lenormand]
> h3. Minimizing network traffic
>  
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 (or 
> N) separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client 
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, 
> and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no 
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever 
> possible.
> Note that write/update/delete/admin operations should not be affected.
> Note that in our use case, we have a cross DC deployment. So, replace 
> rack1/rack2 by DC1/DC2
> Any comment would be very appreciated.
> 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

Re: Kudos to Jan

[Susheel Kumar]

Jan has been so quick to prioritize the JIRA's.  Thanks Jan for your
promptness.

Thanks,
Susheel

On Wed, Sep 28, 2016 at 8:03 PM, Martin Gainty  wrote:

> many apache projects contain 2 groups of people
>
> -managers who get the credit for the project
>
> -contributors who do the work for the project
>
> I would like to see Jan the contributor promoted  to the group who gets
> credit for the project
>
> Agreed?
> Martin
> __
>
>
>
>
> --
> From: compuwizard...@gmail.com
> Date: Wed, 28 Sep 2016 11:58:24 -0500
> Subject: Re: Kudos to Jan
> To: dev@lucene.apache.org
>
>
> Definitely a great effort. Not only closing/cleaning up JIRAs but putting
> in a lot of effort to making logging more sane.
>
> Kevin Risden
>
> On Wed, Sep 28, 2016 at 11:50 AM, Alexandre Rafalovitch <
> arafa...@gmail.com> wrote:
>
> +1
>
> I tried doing that too, so I know the effort it takes :-)
>
> Regards,
>Alex.
> 
> Newsletter and resources for Solr beginners and intermediates:
> http://www.solr-start.com/
>
>
> On 28 September 2016 at 23:10, David Smiley 
> wrote:
> > Yes; thanks Jan!
> >
> >
> > On Wed, Sep 28, 2016 at 11:38 AM Erick Erickson  >
> > wrote:
> >>
> >> Jan:
> >>
> >> Wanted to send a public thanks for your efforts to clean up old JIRAs.
> >> We even have more JIRAs closed than opened in the last 30 days!
> >>
> >> It's a thankless task, much appreciated.
> >>
> >> Erick
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> > --
> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > http://www.solrenterprisesearchserver.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>

[jira] [Commented] (SOLR-8146) Allowing SolrJ CloudSolrClient to have preferred replica for query/read

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-8146:
-

Hello Noble,

Can you please review the pull request and provide feedback on the approach of 
implementing routingRule and accordingly i can move forward with it.

Thanks,
Susheel

> Allowing SolrJ CloudSolrClient to have preferred replica for query/read
> ---
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch
>
>
> h2. Backgrouds
> Currently, the CloudSolrClient randomly picks a replica to query.
> This is done by shuffling the list of live URLs to query then, picking the 
> first item from the list.
> This ticket is to allow more flexibility and control to some extend which 
> URLs will be picked up for queries.
> Note that this is for queries only and would not affect update/delete/admin 
> operations.
> h2. Implementation
> The current patch uses regex pattern and moves to the top of the list of URLs 
> only those matching the given regex specified by the system property 
> {code}solr.preferredQueryNodePattern{code}
> Initially, I thought it may be good to have Solr nodes tagged with a string 
> pattern (snitch?) and use that pattern for matching the URLs.
> Any comment, recommendation or feedback would be appreciated.
> h2. Use Cases
> There are many cases where the ability to choose the node where queries go 
> can be very handy:
> h3. Special node for manual user queries and analytics
> One may have a SolrCLoud cluster where every node host the same set of 
> collections with:  
> - multiple large SolrCLoud nodes (L) used for production apps and 
> - have 1 small node (S) in the same cluster with less ram/cpu used only for 
> manual user queries, data export and other production issue investigation.
> This ticket would allow to configure the applications using SolrJ to query 
> only the (L) nodes
> This use case is similar to the one described in SOLR-5501 raised by [~manuel 
> lenormand]
> h3. Minimizing network traffic
>  
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 (or 
> N) separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client 
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, 
> and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no 
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever 
> possible.
> Note that write/update/delete/admin operations should not be affected.
> Note that in our use case, we have a cross DC deployment. So, replace 
> rack1/rack2 by DC1/DC2
> Any comment would be very appreciated.
> 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] (SOLR-9188) BlockUnknown property makes inter-node communication impossible

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-9188:
-

Yes, Jan. The The cluster in my case works fine without any issue and infact we 
moved up to three environment (development, functional & performance) with QA 
certified and didn't notice any issue until one developer noticed these error 
messages in Logs.  

Removing blockUnknown doesn't help as it then allows anyone to access Solr 
directly without challenging with user / pwd.

The Solr Cluster in our case has multiple shards.


Please let me know if i can provide any more details.

Thanks,
Susheel

> BlockUnknown property makes inter-node communication impossible
> ---
>
> Key: SOLR-9188
> URL: https://issues.apache.org/jira/browse/SOLR-9188
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 6.0
>Reporter: Piotr Tempes
>Priority: Critical
>  Labels: BasicAuth, Security
> Attachments: solr9188-errorlog.txt
>
>
> When I setup my solr cloud without blockUnknown property it works as 
> expected. When I want to block non authenticated requests I get following 
> stacktrace during startup (see attached file).



--
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: [jira] [Commented] (SOLR-9188) BlockUnknown property makes inter-node communication impossible

[Susheel Kumar]

The Solr cluster consists of 2 shards in development, 2 in functional, no
replica's and "6 shards in IPE with replicationFactor=2".

On Fri, Aug 26, 2016 at 4:54 PM, Susheel Kumar <susheel2...@gmail.com>
wrote:

> Yes, Jan. The The cluster in my case works fine without any issue and
> surprisingly we moved up to three environment (development, functional &
> performance) with QA certified and didn't notice any issue until one
> developer noticed these error messages in Logs.
>
> Removing blockUnknown doesn't help as it then allows anyone to access
> Solr directly without challenging with user / pwd.
>
>
> Please let me know if i can provide any more details.
>
> Thanks,
> Susheel
>
> On Fri, Aug 26, 2016 at 2:54 PM, Jan Høydahl (JIRA) <j...@apache.org>
> wrote:
>
>>
>> [ https://issues.apache.org/jira/browse/SOLR-9188?page=com.
>> atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
>> l=15438709#comment-15438709 ]
>>
>> Jan Høydahl commented on SOLR-9188:
>> ---
>>
>> Trying to dig deeper:
>>
>> [~susheel2...@gmail.com] also reported on the mailing list but says that
>> his cluster works well, except from the error logs. Are you sure there are
>> no side effects? In SOLR-9257, [~MartinLoeper]  says "This works well when
>> there is no inter-node communication. As soon as I create a collection with
>> 2 shards, I get the following exception for every access of the "/select"
>> request handler.  Error 401 Unauthorized request..."
>>
>> In SOLR-9257, [~shankarmc...@gmail.com] says that removing blockUnknown
>> does not help. Can you confirm this?
>>
>> I rased the priority of this to Critical, please help shed some more
>> light on this
>>
>> > BlockUnknown property makes inter-node communication impossible
>> > ---
>> >
>> > Key: SOLR-9188
>> > URL: https://issues.apache.org/jira/browse/SOLR-9188
>> > Project: Solr
>> >  Issue Type: Bug
>> >  Components: SolrCloud
>> >Affects Versions: 6.0
>> >Reporter: Piotr Tempes
>> >Priority: Critical
>> >  Labels: BasicAuth, Security
>> > Attachments: solr9188-errorlog.txt
>> >
>> >
>> > When I setup my solr cloud without blockUnknown property it works as
>> expected. When I want to block non authenticated requests I get following
>> stacktrace during startup (see attached file).
>>
>>
>>
>> --
>> 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: [jira] [Commented] (SOLR-9188) BlockUnknown property makes inter-node communication impossible

[Susheel Kumar]

Yes, Jan. The The cluster in my case works fine without any issue and
surprisingly we moved up to three environment (development, functional &
performance) with QA certified and didn't notice any issue until one
developer noticed these error messages in Logs.

Removing blockUnknown doesn't help as it then allows anyone to access Solr
directly without challenging with user / pwd.


Please let me know if i can provide any more details.

Thanks,
Susheel

On Fri, Aug 26, 2016 at 2:54 PM, Jan Høydahl (JIRA)  wrote:

>
> [ https://issues.apache.org/jira/browse/SOLR-9188?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15438709#comment-15438709 ]
>
> Jan Høydahl commented on SOLR-9188:
> ---
>
> Trying to dig deeper:
>
> [~susheel2...@gmail.com] also reported on the mailing list but says that
> his cluster works well, except from the error logs. Are you sure there are
> no side effects? In SOLR-9257, [~MartinLoeper]  says "This works well when
> there is no inter-node communication. As soon as I create a collection with
> 2 shards, I get the following exception for every access of the "/select"
> request handler.  Error 401 Unauthorized request..."
>
> In SOLR-9257, [~shankarmc...@gmail.com] says that removing blockUnknown
> does not help. Can you confirm this?
>
> I rased the priority of this to Critical, please help shed some more light
> on this
>
> > BlockUnknown property makes inter-node communication impossible
> > ---
> >
> > Key: SOLR-9188
> > URL: https://issues.apache.org/jira/browse/SOLR-9188
> > Project: Solr
> >  Issue Type: Bug
> >  Components: SolrCloud
> >Affects Versions: 6.0
> >Reporter: Piotr Tempes
> >Priority: Critical
> >  Labels: BasicAuth, Security
> > Attachments: solr9188-errorlog.txt
> >
> >
> > When I setup my solr cloud without blockUnknown property it works as
> expected. When I want to block non authenticated requests I get following
> stacktrace during startup (see attached file).
>
>
>
> --
> 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-9399) Delete requests do not send credentials & fails for Basic Authentication

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-9399:
---

 Summary: Delete requests do not send credentials & fails for Basic 
Authentication
 Key: SOLR-9399
 URL: https://issues.apache.org/jira/browse/SOLR-9399
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrJ
Affects Versions: 6.0.1, 6.0, 6.x
Reporter: Susheel Kumar


The getRoutes(..) func of UpdateRequest do not pass credentials to 
LBHttpSolrClient when deleteById is set while for updates it passes the 
credentials.  See below code snippet

  if (deleteById != null) {
  
  Iterator<Map.Entry<String,Map<String,Object>>> entries = 
deleteById.entrySet()
  .iterator();
  while (entries.hasNext()) {

Map.Entry<String,Map<String,Object>> entry = entries.next();

String deleteId = entry.getKey();
Map<String,Object> map = entry.getValue();
Long version = null;
if (map != null) {
  version = (Long) map.get(VER);
}
Slice slice = router.getTargetSlice(deleteId, null, null, null, col);
if (slice == null) {
  return null;
}
List urls = urlMap.get(slice.getName());
if (urls == null) {
  return null;
}
String leaderUrl = urls.get(0);
LBHttpSolrClient.Req request = routes.get(leaderUrl);
if (request != null) {
  UpdateRequest urequest = (UpdateRequest) request.getRequest();
  urequest.deleteById(deleteId, version);
} else {
  UpdateRequest urequest = new UpdateRequest();
  urequest.setParams(params);
  urequest.deleteById(deleteId, version);
  urequest.setCommitWithin(getCommitWithin());
  request = new LBHttpSolrClient.Req(urequest, urls);
  routes.put(leaderUrl, request);
}
  }
}



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

Need Permission to commit feature branch for Pull Request SOLR-8146

[Susheel Kumar]

Hello,

I created a feature branch for SOLR-8146 that i can submit a pull request
(PR) for review. While pushing the feature branch i am getting below error.
My github id is susheel2...@gmail.com

Thanks,

Susheel

lucene-solr git:(SOLR-8146) git push origin SOLR-8146

Username for 'https://github.com': susheel2...@gmail.com

Password for 'https://susheel2...@gmail.com@github.com':

remote: Permission to apache/lucene-solr.git denied to sushil2777.

Re: Welcome Alexandre Rafalovitch as a Lucene/Solr committer!

[Susheel Kumar]

Congratulations Alexandre !!!

On Sun, Aug 7, 2016 at 3:19 PM, Shai Erera  wrote:

> Welcome Alexandre and congratulations!
>
> On Sun, Aug 7, 2016 at 9:51 PM Dawid Weiss  wrote:
>
>> Welcome Alexandre!
>>
>> Dawid
>>
>> On Sun, Aug 7, 2016 at 7:16 PM, Alan Woodward  wrote:
>> > Welcome Alexandre!
>> >
>> > Alan Woodward
>> > www.flax.co.uk
>> >
>> >
>> > On 7 Aug 2016, at 15:38, Uwe Schindler wrote:
>> >
>> > Welcome Alexandre!
>> >
>> > Uwe
>> >
>> > Am 7. August 2016 00:49:50 MESZ, schrieb "Jan Høydahl"
>> > :
>> >
>> > I'm pleased to announce that Alexandre Rafalovitch has accepted the
>> >
>> > Lucene PMC's invitation to become a committer.
>> >
>> >
>> > Alexandre, it's tradition that you introduce yourself with a brief bio.
>> >
>> >
>> > Your handle "arafalov" is already added to the “lucene" LDAP group, so
>> >
>> > you now have commit privileges. Please test this by adding yourself to
>> >
>> > the committers section of the Who We Are page on the website:
>> >
>> >  (instructions here
>> >
>> > ).
>> >
>> >
>> > The ASF dev page also has lots of useful links:
>> >
>> > .
>> >
>> >
>> > Congratulations and welcome!
>> >
>> >
>> > --
>> >
>> > Jan Høydahl
>> >
>> > -
>> >
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>> >
>> > --
>> > Uwe Schindler
>> > H.-H.-Meier-Allee 63, 28213 Bremen
>> > http://www.thetaphi.de
>> >
>> > -
>> > 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] [Created] (SOLR-9370) Add sample code snippet to confluence documentaion for Basic Authentication

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-9370:
---

 Summary: Add sample code snippet to confluence documentaion for 
Basic Authentication
 Key: SOLR-9370
 URL: https://issues.apache.org/jira/browse/SOLR-9370
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: documentation
Reporter: Susheel Kumar
Priority: Minor


Please add below code snippet to under "Using BasicAuth with SolrJ"  as current 
code "snippet" doesn't give visibility on how basic authentication can be set 
when querying


How to set credentials when querying using SolrJ - Basic Authentication
=

SolrQuery query = new SolrQuery();
query.setQuery("*:*");
// Do any other query setup needed.

SolrRequest req = new QueryRequest(query);
req.setBasicAuthCredentials(userName, password); 

QueryResponse rsp = req.process(solrClient, collection);



--
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-8146) Allowing SolrJ CloudSolrClient to have preferred replica for query/read

[Susheel Kumar (JIRA)]

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

Susheel Kumar edited comment on SOLR-8146 at 7/18/16 6:14 PM:
--

Thanks, Paul.  I like the routingRule terminology than preferredNodes. The 
current rules like cores, freeDisk, host etc doesn't include "rule" in their 
names, so wanted to double check if "routingRule" name is okay and there is 
similar parameter name __route__ for routing keys 
https://cwiki.apache.org/confluence/display/solr/Advanced+Distributed+Request+Options.
  Hope these names all fit together to avoid any ambiguity. 



was (Author: susheel2...@gmail.com):
Thanks, Paul.  I like the routingRule terminology than preferredNodes. The 
current rules like cores, freeDisk, host etc doesn't include "rule" in their 
names, so wanted to double check if "routingRule" name is okay and there is 
similar parameter name _route_ for routing keys 
https://cwiki.apache.org/confluence/display/solr/Advanced+Distributed+Request+Options.
  Hope these names all fit together to avoid any ambiguity. 


> Allowing SolrJ CloudSolrClient to have preferred replica for query/read
> ---
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch
>
>
> h2. Backgrouds
> Currently, the CloudSolrClient randomly picks a replica to query.
> This is done by shuffling the list of live URLs to query then, picking the 
> first item from the list.
> This ticket is to allow more flexibility and control to some extend which 
> URLs will be picked up for queries.
> Note that this is for queries only and would not affect update/delete/admin 
> operations.
> h2. Implementation
> The current patch uses regex pattern and moves to the top of the list of URLs 
> only those matching the given regex specified by the system property 
> {code}solr.preferredQueryNodePattern{code}
> Initially, I thought it may be good to have Solr nodes tagged with a string 
> pattern (snitch?) and use that pattern for matching the URLs.
> Any comment, recommendation or feedback would be appreciated.
> h2. Use Cases
> There are many cases where the ability to choose the node where queries go 
> can be very handy:
> h3. Special node for manual user queries and analytics
> One may have a SolrCLoud cluster where every node host the same set of 
> collections with:  
> - multiple large SolrCLoud nodes (L) used for production apps and 
> - have 1 small node (S) in the same cluster with less ram/cpu used only for 
> manual user queries, data export and other production issue investigation.
> This ticket would allow to configure the applications using SolrJ to query 
> only the (L) nodes
> This use case is similar to the one described in SOLR-5501 raised by [~manuel 
> lenormand]
> h3. Minimizing network traffic
>  
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 (or 
> N) separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client 
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, 
> and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no 
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever 
> possible.
> Note that write/update/delete/admin operations should not be affected.
> Note that in our use case, we have a cross DC deployment. So, replace 
> rack1/rack2 by DC1/DC2
> Any comment would be very appreciated.
> 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] (SOLR-8146) Allowing SolrJ CloudSolrClient to have preferred replica for query/read

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-8146:
-

Thanks, Paul.  I like the routingRule terminology than preferredNodes. The 
current rules like cores, freeDisk, host etc doesn't include "rule" in their 
names, so wanted to double check if "routingRule" name is okay and there is 
similar parameter name _route_ for routing keys 
https://cwiki.apache.org/confluence/display/solr/Advanced+Distributed+Request+Options.
  Hope these names all fit together to avoid any ambiguity. 


> Allowing SolrJ CloudSolrClient to have preferred replica for query/read
> ---
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch
>
>
> h2. Backgrouds
> Currently, the CloudSolrClient randomly picks a replica to query.
> This is done by shuffling the list of live URLs to query then, picking the 
> first item from the list.
> This ticket is to allow more flexibility and control to some extend which 
> URLs will be picked up for queries.
> Note that this is for queries only and would not affect update/delete/admin 
> operations.
> h2. Implementation
> The current patch uses regex pattern and moves to the top of the list of URLs 
> only those matching the given regex specified by the system property 
> {code}solr.preferredQueryNodePattern{code}
> Initially, I thought it may be good to have Solr nodes tagged with a string 
> pattern (snitch?) and use that pattern for matching the URLs.
> Any comment, recommendation or feedback would be appreciated.
> h2. Use Cases
> There are many cases where the ability to choose the node where queries go 
> can be very handy:
> h3. Special node for manual user queries and analytics
> One may have a SolrCLoud cluster where every node host the same set of 
> collections with:  
> - multiple large SolrCLoud nodes (L) used for production apps and 
> - have 1 small node (S) in the same cluster with less ram/cpu used only for 
> manual user queries, data export and other production issue investigation.
> This ticket would allow to configure the applications using SolrJ to query 
> only the (L) nodes
> This use case is similar to the one described in SOLR-5501 raised by [~manuel 
> lenormand]
> h3. Minimizing network traffic
>  
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 (or 
> N) separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client 
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, 
> and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no 
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever 
> possible.
> Note that write/update/delete/admin operations should not be affected.
> Note that in our use case, we have a cross DC deployment. So, replace 
> rack1/rack2 by DC1/DC2
> Any comment would be very appreciated.
> 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] [Comment Edited] (SOLR-8146) Allowing SolrJ CloudSolrClient to have preferred replica for query/read

[Susheel Kumar (JIRA)]

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

Susheel Kumar edited comment on SOLR-8146 at 7/18/16 2:54 PM:
--

Thanks, Noble and Arcadius for clarifying the status of SOLR-8146.  


Hello Noble,  I can start working on the patch.  Have a question to clarify

1. For multi-data center scenario, the preferredNodes rule may specify 
different values / ranges depending on, from which data center solrj client is 
querying?  So do you see preferredNodes rule being used during query operation 
like 

http://localhost:8983/solr/collection1/select?rule=preferredNodes=ip_1:192,ip_2:93

The current Snitches design/implementation is only being used in Admin 
Collections API 
(https://cwiki.apache.org/confluence/display/solr/Collections+API) for replica 
placement so this will be another usage of Snitches and extending to query 
operations.

Thanks,
Susheel




was (Author: susheel2...@gmail.com):
Thanks, Noble and Arcadius for clarifying the status of SOLR-8146.  


Hello Noble,  I can start working on the patch.  Have a question to clarify

1. For multi-date center scenario, the preferredNodes rule may specify 
different values / ranges depending on, from which data center solrj client is 
querying?  So do you see preferredNodes rule being used during query operation 
like 

http://localhost:8983/solr/collection1/select?rule=preferredNodes=ip_1:192,ip_2:93

The current Snitches design/implementation is only being used in Admin 
Collections API 
(https://cwiki.apache.org/confluence/display/solr/Collections+API) for replica 
placement so this will be another usage of Snitches and extending to query 
operations.

Thanks,
Susheel



> Allowing SolrJ CloudSolrClient to have preferred replica for query/read
> ---
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch
>
>
> h2. Backgrouds
> Currently, the CloudSolrClient randomly picks a replica to query.
> This is done by shuffling the list of live URLs to query then, picking the 
> first item from the list.
> This ticket is to allow more flexibility and control to some extend which 
> URLs will be picked up for queries.
> Note that this is for queries only and would not affect update/delete/admin 
> operations.
> h2. Implementation
> The current patch uses regex pattern and moves to the top of the list of URLs 
> only those matching the given regex specified by the system property 
> {code}solr.preferredQueryNodePattern{code}
> Initially, I thought it may be good to have Solr nodes tagged with a string 
> pattern (snitch?) and use that pattern for matching the URLs.
> Any comment, recommendation or feedback would be appreciated.
> h2. Use Cases
> There are many cases where the ability to choose the node where queries go 
> can be very handy:
> h3. Special node for manual user queries and analytics
> One may have a SolrCLoud cluster where every node host the same set of 
> collections with:  
> - multiple large SolrCLoud nodes (L) used for production apps and 
> - have 1 small node (S) in the same cluster with less ram/cpu used only for 
> manual user queries, data export and other production issue investigation.
> This ticket would allow to configure the applications using SolrJ to query 
> only the (L) nodes
> This use case is similar to the one described in SOLR-5501 raised by [~manuel 
> lenormand]
> h3. Minimizing network traffic
>  
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 (or 
> N) separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client 
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, 
> and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no 
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever 
> possible.
> Note that write/update/delete/admin operations should not be affected.
> Note that in our use case, we have a cross DC deployment. So, replace 
> rack1/rack2 by DC1/DC2
> Any comment would be very appreciated.
> Thanks.



--
This message w

[jira] [Commented] (SOLR-8146) Allowing SolrJ CloudSolrClient to have preferred replica for query/read

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-8146:
-

Thanks, Noble and Arcadius for clarifying the status of SOLR-8146.  


Hello Noble,  I can start working on the patch.  Have a question to clarify

1. For multi-date center scenario, the preferredNodes rule may specify 
different values / ranges depending on, from which data center solrj client is 
querying?  So do you see preferredNodes rule being used during query operation 
like 

http://localhost:8983/solr/collection1/select?rule=preferredNodes=ip_1:192,ip_2:93

The current Snitches design/implementation is only being used in Admin 
Collections API 
(https://cwiki.apache.org/confluence/display/solr/Collections+API) for replica 
placement so this will be another usage of Snitches and extending to query 
operations.

Thanks,
Susheel



> Allowing SolrJ CloudSolrClient to have preferred replica for query/read
> ---
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch
>
>
> h2. Backgrouds
> Currently, the CloudSolrClient randomly picks a replica to query.
> This is done by shuffling the list of live URLs to query then, picking the 
> first item from the list.
> This ticket is to allow more flexibility and control to some extend which 
> URLs will be picked up for queries.
> Note that this is for queries only and would not affect update/delete/admin 
> operations.
> h2. Implementation
> The current patch uses regex pattern and moves to the top of the list of URLs 
> only those matching the given regex specified by the system property 
> {code}solr.preferredQueryNodePattern{code}
> Initially, I thought it may be good to have Solr nodes tagged with a string 
> pattern (snitch?) and use that pattern for matching the URLs.
> Any comment, recommendation or feedback would be appreciated.
> h2. Use Cases
> There are many cases where the ability to choose the node where queries go 
> can be very handy:
> h3. Special node for manual user queries and analytics
> One may have a SolrCLoud cluster where every node host the same set of 
> collections with:  
> - multiple large SolrCLoud nodes (L) used for production apps and 
> - have 1 small node (S) in the same cluster with less ram/cpu used only for 
> manual user queries, data export and other production issue investigation.
> This ticket would allow to configure the applications using SolrJ to query 
> only the (L) nodes
> This use case is similar to the one described in SOLR-5501 raised by [~manuel 
> lenormand]
> h3. Minimizing network traffic
>  
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 (or 
> N) separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client 
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, 
> and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no 
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever 
> possible.
> Note that write/update/delete/admin operations should not be affected.
> Note that in our use case, we have a cross DC deployment. So, replace 
> rack1/rack2 by DC1/DC2
> Any comment would be very appreciated.
> 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] (SOLR-9283) Documentation on using preferredNodes-ImplicitSnitch for Multi Data Center scenario

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-9283:
-

Thank you Noble for your response. Let me know if anyone is working on
completing the patch or I can give a shot on the patch if you can provide
some direction/design.

Thanks,
Susheel




> Documentation on using preferredNodes-ImplicitSnitch for Multi Data Center 
> scenario
> ---
>
> Key: SOLR-9283
> URL: https://issues.apache.org/jira/browse/SOLR-9283
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.0
>    Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: documentation
>
> SOLR-8146 and SOLR-8522 has been worked on to allow SolrJ CloudSolrClient to 
> have preferred replica for query/read more specifically for multiple Data 
> Center's scenario but there is no/unclear documentation on how exactly this 
> feature can be used and what steps needs to be taken care at SolrJ client 
> side and part of collection configuration/state.
> I am offering help to create the required documentation if little more 
> details can be provided.



--
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-8146) Allowing SolrJ CloudSolrClient to have preferred replica for query/read

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-8146:
-

Hello Noble, Arcadius,

Can you please describe how exactly ImplicitSnitch can be used for 
preferredNodes and if there is anything to be done on SolrJ client to use 
preferredNodes for querying replicas?

I have created a JIRA  https://issues.apache.org/jira/browse/SOLR-9283 to 
document the exact steps/details for anyone to refer.

Thanks,
Susheel

> Allowing SolrJ CloudSolrClient to have preferred replica for query/read
> ---
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch
>
>
> h2. Backgrouds
> Currently, the CloudSolrClient randomly picks a replica to query.
> This is done by shuffling the list of live URLs to query then, picking the 
> first item from the list.
> This ticket is to allow more flexibility and control to some extend which 
> URLs will be picked up for queries.
> Note that this is for queries only and would not affect update/delete/admin 
> operations.
> h2. Implementation
> The current patch uses regex pattern and moves to the top of the list of URLs 
> only those matching the given regex specified by the system property 
> {code}solr.preferredQueryNodePattern{code}
> Initially, I thought it may be good to have Solr nodes tagged with a string 
> pattern (snitch?) and use that pattern for matching the URLs.
> Any comment, recommendation or feedback would be appreciated.
> h2. Use Cases
> There are many cases where the ability to choose the node where queries go 
> can be very handy:
> h3. Special node for manual user queries and analytics
> One may have a SolrCLoud cluster where every node host the same set of 
> collections with:  
> - multiple large SolrCLoud nodes (L) used for production apps and 
> - have 1 small node (S) in the same cluster with less ram/cpu used only for 
> manual user queries, data export and other production issue investigation.
> This ticket would allow to configure the applications using SolrJ to query 
> only the (L) nodes
> This use case is similar to the one described in SOLR-5501 raised by [~manuel 
> lenormand]
> h3. Minimizing network traffic
>  
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 (or 
> N) separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client 
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, 
> and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no 
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever 
> possible.
> Note that write/update/delete/admin operations should not be affected.
> Note that in our use case, we have a cross DC deployment. So, replace 
> rack1/rack2 by DC1/DC2
> Any comment would be very appreciated.
> 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

Re: [jira] [Created] (SOLR-9283) Documentation on using preferredNodes-ImplicitSnitch for Multi Data Center scenario

[Susheel Kumar]

Hello,

I have created JIRA SOLR-9283 to document usage of
preferredNodes-ImplicitSnitch to allow SolrJ CloudSolrClient to have
preferred replica for query/read more specifically for multiple Data
Center's scenario. I can help create the documentation if exact usage can
be provided.

Thanks,
Susheel

On Wed, Jul 6, 2016 at 10:28 AM, Susheel Kumar (JIRA) <j...@apache.org>
wrote:

> Susheel Kumar created SOLR-9283:
> ---
>
>  Summary: Documentation on using preferredNodes-ImplicitSnitch
> for Multi Data Center scenario
>  Key: SOLR-9283
>  URL: https://issues.apache.org/jira/browse/SOLR-9283
>  Project: Solr
>   Issue Type: Improvement
>   Security Level: Public (Default Security Level. Issues are Public)
> Affects Versions: 6.0
> Reporter: Susheel Kumar
> Priority: Blocker
>
>
> SOLR-8146 and SOLR-8522 has been worked on to allow SolrJ CloudSolrClient
> to have preferred replica for query/read more specifically for multiple
> Data Center's scenario but there is no/unclear documentation on how exactly
> this feature can be used and what steps needs to be taken care at SolrJ
> client side and part of collection configuration/state.
>
> I am offering help to create the required documentation if little more
> details can be provided.
>
>
>
> --
> 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-9283) Documentation on using preferredNodes-ImplicitSnitch for Multi Data Center scenario

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-9283:
---

 Summary: Documentation on using preferredNodes-ImplicitSnitch for 
Multi Data Center scenario
 Key: SOLR-9283
 URL: https://issues.apache.org/jira/browse/SOLR-9283
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.0
Reporter: Susheel Kumar
Priority: Blocker


SOLR-8146 and SOLR-8522 has been worked on to allow SolrJ CloudSolrClient to 
have preferred replica for query/read more specifically for multiple Data 
Center's scenario but there is no/unclear documentation on how exactly this 
feature can be used and what steps needs to be taken care at SolrJ client side 
and part of collection configuration/state.

I am offering help to create the required documentation if little more details 
can be provided.



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

ImplicitSnitch Documentation for querying Multi-DataCenter replicas using preferredNodes

[Susheel Kumar]

Hello,

Can someone help me to clarify and document how to use ImplicitSnitch
preferredNodes rule to implement scenario where search queries executed
from data center DC1 client, uses all dc1 replica's and data center DC2
client, uses all dc2 replica's.

The only source I see is the discussion from JIRA associated with tickets
https://issues.apache.org/jira/browse/SOLR-8146  and the blog
http://menelic.com/2015/12/05/allowing-solrj-cloudsolrclient-to-have-preferred-replica-for-query-operations/


Thanks,
Susheel

Re: [jira] [Commented] (SOLR-8522) ImplicitSnitch to support IPv4 fragment tags

[Susheel Kumar]

Hello Arcadius, Noble,

I have a single Solr cluster setup across two DC's with below similar
configuration.  Now i am looking to use preferredNodes feature/rule that
search queries executed from DC1 client uses all dc1 replica's and DC2
client uses all dc2 replica's for faster query response.  I am bit confused
with the current documentation on what different steps needs to be taken
care on client and zookeeper side?  Can you  please summarize what needs to
be executed part of Solrj client configuration/properties and Zookeeper
clusterstate (MODIFYCOLLECTION) to make it work?

DC1 - 3-dc1 shards replica and 3-dc2 shards replica
DC2 - 3-dc2 shards replaca and 3-dc1 shards replica


Thanks,
Susheel



On Fri, Jun 3, 2016 at 2:47 AM, Arcadius Ahouansou (JIRA) 
wrote:

>
> [
> https://issues.apache.org/jira/browse/SOLR-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15313750#comment-15313750
> ]
>
> Arcadius Ahouansou commented on SOLR-8522:
> --
>
> Hi [~k317h]
> I commented on  SOLR-9183
>
> > ImplicitSnitch to support IPv4 fragment tags
> > 
> >
> > Key: SOLR-8522
> > URL: https://issues.apache.org/jira/browse/SOLR-8522
> > Project: Solr
> >  Issue Type: Improvement
> >  Components: SolrCloud
> >Affects Versions: 5.4
> >Reporter: Arcadius Ahouansou
> >Assignee: Noble Paul
> >Priority: Minor
> > Fix For: 6.0
> >
> > Attachments: SOLR-8522.patch, SOLR-8522.patch, SOLR-8522.patch,
> SOLR-8522.patch, SOLR-8522.patch
> >
> >
> > This is a description from [~noble.paul]'s comment on SOLR-8146
> > h3. IPv4 fragment tags
> > Lets assume a Solr node IPv4 address is {{192.93.255.255}} .
> > This is about enhancing the current {{ImplicitSnitch}}  to support IP
> based tags like:
> > - {{hostfrag_1 = 255}}
> > - {{hostfrag_2 = 255}}
> > - {{hostfrag_3 = 93}}
> > - {{hostfrag_4 = 192}}
> > Note that IPv6 support will be implemented by a separate ticket
> > h3. Host name fragment tags
> > Lets assume a Solr node host name {{serv1.dc1.country1.apache.org}} .
> > This is about enhancing the current {{ImplicitSnitch}}  to support  tags
> like:
> > - {{hostfrag_1 = org}}
> > - {{hostfrag_2 = apache}}
> > - {{hostfrag_3 = country1}}
> > - {{hostfrag_4 = dc1}}
> > - {{hostfrag_5 = serv1}}
>
>
>
> --
> 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: Welcome Kevin Rsiden as Lucene/Solr committer

[Susheel Kumar]

Congratulations Kevin!!!

On Wed, Mar 16, 2016 at 8:17 PM, Otis Gospodnetic <
otis.gospodne...@gmail.com> wrote:

> Congratulations and welcome!
>
> Otis
>
> On Mar 16, 2016, at 13:02, Joel Bernstein  wrote:
>
> I'm pleased to announce that Kevin Risden has accepted the PMC's invitation
> to become a committer.
>
> Kevin, it's tradition that you introduce yourself with a brief bio.
>
> I believe your account has been setup and karma has been granted so that
> you can add yourself to the committers section of the Who We Are page on
> the website:
> .
>
> Congratulations and welcome!
>
>
> Joel Bernstein
>
>

[jira] [Created] (SOLR-8686) Install Script hard codes the SOLR_ENV path in /etc/init.d/solr

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-8686:
---

 Summary: Install Script hard codes the SOLR_ENV path in 
/etc/init.d/solr
 Key: SOLR-8686
 URL: https://issues.apache.org/jira/browse/SOLR-8686
 Project: Solr
  Issue Type: Bug
  Components: scripts and tools
Affects Versions: 5.4.1
Reporter: Susheel Kumar


Until Solr-5.3.1 (that i am aware of), the install script would set the right 
SOLR_ENV path in /etc/init.d/solr which is passed as -d "Directory for live / 
writable Solr files..."  but with solr-5.4.1 i see it always sets to 
/etc/default/solr.in.sh.  
Below is diff snippet of install_solr_service.sh of 5.3.1 vs 5.4.1


 
sed_expr1="s#SOLR_INSTALL_DIR=.*#SOLR_INSTALL_DIR=$SOLR_EXTRACT_DIR/$SOLR_SERVICE#"
< sed_expr2="s#SOLR_ENV=.*#SOLR_ENV=$SOLR_VAR_DIR/solr.in.sh#"
< sed_expr3="s#RUNAS=.*#RUNAS=$SOLR_USER#"
---
> sed_expr1="s#SOLR_INSTALL_DIR=.*#SOLR_INSTALL_DIR=\"$SOLR_EXTRACT_DIR/$SOLR_SERVICE\"#"
> sed_expr2="s#SOLR_ENV=.*#SOLR_ENV=\"/etc/default/$SOLR_SERVICE.in.sh\"#"
> sed_expr3="s#RUNAS=.*#RUNAS=\"$SOLR_USER\"#"



--
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-8592) Create collection alias from New UI doesn't actually work

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-8592:
---

 Summary: Create collection alias from New UI doesn't actually work
 Key: SOLR-8592
 URL: https://issues.apache.org/jira/browse/SOLR-8592
 Project: Solr
  Issue Type: Bug
 Environment: Solr Dashboard New UI shipped with 5.4.0
Reporter: Susheel Kumar
Priority: Minor


The new UI shipped with 5.4.0 allows collection aliases to be created from UI 
and it does work but when you try to use any alias created using UI 
http://:8983/solr/index.html#/ it gives error saying

error": {
"msg": "Could not find collection : [object Object]",
"code": 400
}

While doing same operation using admin/collection API it actually works.



--
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: [jira] [Commented] (SOLR-8184) Negative tests for JDBC Connection String

[Susheel Kumar]

I agree as well, Jason.  Please go ahead to make the changes.

Thanks,
Susheel

On Wed, Jan 6, 2016 at 11:11 PM, Jason Gerlowski (JIRA) <j...@apache.org>
wrote:

>
> [
> https://issues.apache.org/jira/browse/SOLR-8184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15086777#comment-15086777
> ]
>
> Jason Gerlowski commented on SOLR-8184:
> ---
>
> To follow up on my prior comment, it turns out that the test file Kevin
> referred to above (JdbcDriverTest) does involve much less overhead (it runs
> in ~1sec on my machine.).  Since the overheard on these tests is much
> lower, I second Kevin's recommendation that we move everything we can into
> JdbcDriverTest .
>
> There are really 3 tests in question here:
> testConnectionStringWithMissingZkHost, testConnectionStringJumbled, and
> testConnectionStringWithWrongCollection.  The first of these is already
> covered by JdbcDriverTest.testNullZkConnectionString.  The second doesn't
> have a JdbcDriverTest analog, but could easily be moved over to
> JdbcDriverTest.  The third test case would be more difficult to move, as it
> involves checking an error arises after connecting, creating a statement,
> etc.  There doesn't look like there's an easy way to port this over.
>
> My suggestion/vote would be:
> 1.) Totally drop the first test (since it already has coverage in
> JdbcDriverTest),
> 2.) Move the second test to JdbcDriverTest,
> 3.) Keep the third test in JdbcTest, but move it into the doTest()
> method.  This allows it to avoid incurring the unnecessary overheard, as
> Kevin mentioned above.
>
> Anyone have thoughts/suggestions/counterarguments? I'm happy to make these
> modifications myself if others find them reasonable, but I don't want to
> step on any toes.  [~susheel2...@gmail.com]  pushed the first revision of
> this up, so I'll hold off for a few days to see if he has any thoughts.
>
> Otherwise (assuming people are ok with my proposed plan), I'll go ahead
> with this.
>
> > Negative tests for JDBC Connection String
> > -
> >
> > Key: SOLR-8184
> > URL: https://issues.apache.org/jira/browse/SOLR-8184
> > Project: Solr
> >  Issue Type: Test
> > Environment: Trunk
> >Reporter: Susheel Kumar
> >Priority: Minor
> > Attachments: SOLR-8184.patch, SOLR-8184.patch
> >
> >
> > Ticket to track negative tests for JDBC connection string SOLR-7986
>
>
>
> --
> 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: CDCR is is being developed for SolrCloud not for Master/Slave?

[Susheel Kumar]

Thanks, Erick for the confirmation. I'll also plan to test & use CDCR from
the trunk starting Jan.

On Tue, Nov 24, 2015 at 12:58 PM, Erick Erickson <erickerick...@gmail.com>
wrote:

> I can also confirm that CDCR is currently in use in a production
> environment. Beyond that I cannot comment. Whether this will be _ever_
> be in 5.x is an open question at this point, it will probably be 6.0
> only as it "fits" better being significant new functionality. Much
> depends on how long it'll take to release 6.0.
>
> I expect to close SOLR-6273 today, and commit and close SOLR-8263 on
> trunk/6.0 today as well, barring unforeseen issues.
>
> As far as 5x is concerned, I'll supply an "uber-patch" for SOLR-6273
> but _not_ commit any changes to the 5x code line. Similarly, I'll make
> sure that SOLR-8263 applies to the (patched with SOLR-6273_5x) 5x code
> line but _not_ commit it either. I'll compile/test (beast) the
> combined patches. These are "as is" for those who really want to jump
> on this functionality and to preserve the port in case we want to
> apply this in future to 5x.
>
>
>
> On Mon, Nov 23, 2015 at 9:16 AM, Susheel Kumar <susheel2...@gmail.com>
> wrote:
> > Thanks, Shalin for confirming. Good to know it is already being used and
> > looking forward for getting it released soon.
> >
> > On Mon, Nov 23, 2015 at 12:08 PM, Shalin Shekhar Mangar
> > <shalinman...@gmail.com> wrote:
> >>
> >> Hi Susheel,
> >>
> >> No, CDCR is a SolrCloud only feature. I've heard that the CDCR patches
> >> are in production already at a large company but I don't have the
> >> details.
> >>
> >> On Mon, Nov 23, 2015 at 10:01 PM, Susheel Kumar <susheel2...@gmail.com>
> >> wrote:
> >> > Thanks, Upayavira for confirming.  Do you know if CDCR is also going
> to
> >> > work
> >> > for Master/Slave old architecture if any of the folks are having that
> in
> >> > production?
> >> >
> >> > On Sun, Nov 22, 2015 at 2:59 PM, Upayavira <u...@odoko.co.uk> wrote:
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Sun, Nov 22, 2015, at 07:51 PM, Susheel Kumar wrote:
> >> >>
> >> >> Hello,
> >> >>
> >> >> One of our architect in team mentioned that CDCR is being developed
> for
> >> >> Master/Slave and can't be used for SolrCloud.  I did look the patches
> >> >> (Zookeeper being used..)  and it doesn't seems to be the case.
> >> >>
> >> >> Can someone from dev community confirm that CDCR being developed is
> for
> >> >> SolrCloud and not for Master/Slave architecture ?
> >> >>
> >> >> Thanks,
> >> >> Susheel
> >> >>
> >> >>
> >> >> You are correct - CDCR will be for allowing multiple SolrCloud farms
> to
> >> >> work together.
> >> >>
> >> >> Upayavira
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Shalin Shekhar Mangar.
> >>
> >> -
> >> 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: Fix heliosearch link for CDCR high level design Solr-6273

[Susheel Kumar]

Hi Shalin,

Can we fix/replace appropriately the heliosearch link to refer to high
level design for CDCR in SOLR-6273 jira description. Currently it seems to
be broken.

Thanks,
Susheel

 http://heliosearch.org/solr-cross-data-center-replication/


On Mon, Nov 23, 2015 at 12:16 PM, Susheel Kumar <susheel2...@gmail.com>
wrote:

> Thanks, Shalin for confirming. Good to know it is already being used and
> looking forward for getting it released soon.
>
> On Mon, Nov 23, 2015 at 12:08 PM, Shalin Shekhar Mangar <
> shalinman...@gmail.com> wrote:
>
>> Hi Susheel,
>>
>> No, CDCR is a SolrCloud only feature. I've heard that the CDCR patches
>> are in production already at a large company but I don't have the
>> details.
>>
>> On Mon, Nov 23, 2015 at 10:01 PM, Susheel Kumar <susheel2...@gmail.com>
>> wrote:
>> > Thanks, Upayavira for confirming.  Do you know if CDCR is also going to
>> work
>> > for Master/Slave old architecture if any of the folks are having that in
>> > production?
>> >
>> > On Sun, Nov 22, 2015 at 2:59 PM, Upayavira <u...@odoko.co.uk> wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On Sun, Nov 22, 2015, at 07:51 PM, Susheel Kumar wrote:
>> >>
>> >> Hello,
>> >>
>> >> One of our architect in team mentioned that CDCR is being developed for
>> >> Master/Slave and can't be used for SolrCloud.  I did look the patches
>> >> (Zookeeper being used..)  and it doesn't seems to be the case.
>> >>
>> >> Can someone from dev community confirm that CDCR being developed is for
>> >> SolrCloud and not for Master/Slave architecture ?
>> >>
>> >> Thanks,
>> >> Susheel
>> >>
>> >>
>> >> You are correct - CDCR will be for allowing multiple SolrCloud farms to
>> >> work together.
>> >>
>> >> Upayavira
>> >
>> >
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>

Re: CDCR is is being developed for SolrCloud not for Master/Slave?

[Susheel Kumar]

Thanks, Upayavira for confirming.  Do you know if CDCR is also going to
work for Master/Slave old architecture if any of the folks are having that
in production?

On Sun, Nov 22, 2015 at 2:59 PM, Upayavira <u...@odoko.co.uk> wrote:

>
>
>
> On Sun, Nov 22, 2015, at 07:51 PM, Susheel Kumar wrote:
>
> Hello,
>
> One of our architect in team mentioned that CDCR is being developed for
> Master/Slave and can't be used for SolrCloud.  I did look the patches
> (Zookeeper being used..)  and it doesn't seems to be the case.
>
> Can someone from dev community confirm that CDCR being developed is for
> SolrCloud and not for Master/Slave architecture ?
>
> Thanks,
> Susheel
>
>
> You are correct - CDCR will be for allowing multiple SolrCloud farms to
> work together.
>
> Upayavira
>

Re: CDCR is is being developed for SolrCloud not for Master/Slave?

[Susheel Kumar]

Thanks, Shalin for confirming. Good to know it is already being used and
looking forward for getting it released soon.

On Mon, Nov 23, 2015 at 12:08 PM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> Hi Susheel,
>
> No, CDCR is a SolrCloud only feature. I've heard that the CDCR patches
> are in production already at a large company but I don't have the
> details.
>
> On Mon, Nov 23, 2015 at 10:01 PM, Susheel Kumar <susheel2...@gmail.com>
> wrote:
> > Thanks, Upayavira for confirming.  Do you know if CDCR is also going to
> work
> > for Master/Slave old architecture if any of the folks are having that in
> > production?
> >
> > On Sun, Nov 22, 2015 at 2:59 PM, Upayavira <u...@odoko.co.uk> wrote:
> >>
> >>
> >>
> >>
> >> On Sun, Nov 22, 2015, at 07:51 PM, Susheel Kumar wrote:
> >>
> >> Hello,
> >>
> >> One of our architect in team mentioned that CDCR is being developed for
> >> Master/Slave and can't be used for SolrCloud.  I did look the patches
> >> (Zookeeper being used..)  and it doesn't seems to be the case.
> >>
> >> Can someone from dev community confirm that CDCR being developed is for
> >> SolrCloud and not for Master/Slave architecture ?
> >>
> >> Thanks,
> >> Susheel
> >>
> >>
> >> You are correct - CDCR will be for allowing multiple SolrCloud farms to
> >> work together.
> >>
> >> Upayavira
> >
> >
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

CDCR is is being developed for SolrCloud not for Master/Slave?

[Susheel Kumar]

Hello,

One of our architect in team mentioned that CDCR is being developed for
Master/Slave and can't be used for SolrCloud.  I did look the patches
(Zookeeper being used..)  and it doesn't seems to be the case.

Can someone from dev community confirm that CDCR being developed is for
SolrCloud and not for Master/Slave architecture ?

Thanks,
Susheel

Re: Next release...

[Susheel Kumar]

CDCR will help many of the folks who are currently trying other
alternatives. Would love to see coming this out sooner and providing
feedback.

On Mon, Nov 9, 2015 at 1:16 PM, Upayavira  wrote:

> I would love to see a 5.4 release. All the tasks I had planned for the
> admin UI are done, so, barring any unforseen and as yet unreported bugs,
> it is ready to go.
>
> How much time commitment does it typically take to make a release? I'd
> consider volunteering, but may not have sufficient time to carry it all
> the way.
>
> Upayavira
>
> On Mon, Nov 9, 2015, at 04:10 PM, Erick Erickson wrote:
> > Adrien:
> >
> > I can certainly wait for a while to commit CDCR to 5.4, there's no
> > huge need to rush 5.4 out the door, particularly not just to
> > accommodate me! After all, let's just say it's been a while that we've
> > been working on this, a bit more time isn't critical
> >
> > I don't want to wait a month though, so if someone is already thinking
> > of branching for 5.4 anyway so I asked to I can plan around it.
> >
> > Erick
> >
> > On Mon, Nov 9, 2015 at 8:00 AM, Adrien Grand  wrote:
> > > Le lun. 9 nov. 2015 à 16:32, Erick Erickson 
> a
> > > écrit :
> > >>
> > >> What is the thinking on cutting 5.4? It looks like the CCR (SOLR-6273)
> > >> is about ready to rock-n-roll. It's a lot of code, and I don't want to
> > >> push it into 5x just before we cut the next release. So if 5.4 is
> > >> imminent I'd like to know for my planning.
> > >
> > >
> > > I think that we should release Lucene 5.4 soon indeed! Maybe we could
> create
> > > a 5.4 branch today already so that you can commit the CDCR changes.
> This
> > > will also help make sure that the 5.4 branch only gets bug fixes as of
> today
> > > and then we have one week to make sure things are stable and we can
> start
> > > the release process next week?
> >
> > -
> > 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: Welcome Joel Bernstein to the PMC

[Susheel Kumar]

Congratulations, Joel !!!

On Fri, Nov 6, 2015 at 1:19 PM, Varun Thacker 
wrote:

> Congrats Joel!
>
> On Fri, Nov 6, 2015 at 6:26 AM, Yonik Seeley  wrote:
>
>> I'm pleased to announce that Joel as accepted the PMC's invitation to
>> join.
>>
>> Welcome Joel!
>>
>> -Yonik
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
>
> --
>
>
> Regards,
> Varun Thacker
>

Re: Welcome Dennis Gove as Lucene/Solr committer

[Susheel Kumar]

Congratulations, Denis !!!

On Fri, Nov 6, 2015 at 1:42 PM, Steven Bower  wrote:

> Congrats!!!
>
> On Fri, Nov 6, 2015 at 1:25 PM Varun Thacker 
> wrote:
>
>> Welcome Dennis!
>>
>> On Fri, Nov 6, 2015 at 7:19 AM, Joel Bernstein 
>> wrote:
>>
>>> I'm pleased to announce that Dennis Gove has accepted the PMC's
>>> invitation to become a committer.
>>>
>>> Dennis, it's tradition that you introduce yourself with a brief bio.
>>>
>>> Your account is not entirely ready yet. We will let you know when it is
>>> created
>>> and karma has been granted so that you can add yourself to the committers
>>> section of the Who We Are page on the website:
>>> .
>>>
>>> Congratulations and welcome!
>>>
>>>
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>>
>>
>>
>>
>> --
>>
>>
>> Regards,
>> Varun Thacker
>>
>

Solr Search: Access Control / Role based security

[Susheel Kumar]

Hi,

I have seen couple of use cases / need where we want to restrict result of
search based on role of a user.  For e.g.

- if user role is admin, any document from the search result will be
returned
- if user role is manager, only documents intended for managers will be
returned
- if user role is worker, only documents intended for workers will be
returned

Typical practise is to tag the documents with the roles (using a
multi-valued field) during indexing and then during search append filter
query to restrict result based on roles.

Wondering if there is any other better way out there and if this common
requirement should be added as a Solr feature/plugin.

The current security plugins are more towards making Solr apis/resources
secure not towards securing/controlling data during search.
https://cwiki.apache.org/confluence/display/solr/Authentication+and+Authorization+Plugins


Please share your thoughts.

Thanks,
Susheel

[jira] [Created] (SOLR-8184) Negative tests for JDBC Connection String

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-8184:
---

 Summary: Negative tests for JDBC Connection String
 Key: SOLR-8184
 URL: https://issues.apache.org/jira/browse/SOLR-8184
 Project: Solr
  Issue Type: Test
 Environment: Trunl
Reporter: Susheel Kumar
Priority: Minor


Ticket to track negative tests for JDBC connection string SOLR-7986



--
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-8184) Negative tests for JDBC Connection String

[Susheel Kumar (JIRA)]

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

Susheel Kumar updated SOLR-8184:

Environment: Trunk  (was: Trunl)

> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
> Environment: Trunk
>    Reporter: Susheel Kumar
>Priority: Minor
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
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-8184) Negative tests for JDBC Connection String

[Susheel Kumar (JIRA)]

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

Susheel Kumar updated SOLR-8184:

Flags: Patch

> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
> Environment: Trunk
>    Reporter: Susheel Kumar
>Priority: Minor
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
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-8184) Negative tests for JDBC Connection String

[Susheel Kumar (JIRA)]

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

Susheel Kumar updated SOLR-8184:

Attachment: SOLR-8184.patch

Negative tests for JDBC Connection String

> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
> Environment: Trunk
>    Reporter: Susheel Kumar
>Priority: Minor
> Attachments: SOLR-8184.patch
>
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
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-8184) Negative tests for JDBC Connection String

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-8184:
-

Some observations:

The test "testConnectionStringWithMissingZKHost" throws SolrException / 
TimeOutException than SQLException and similarly the test 
"testConnectionStringWithWrongCollection" goes thru various retries before it 
fails. Is that right behavior?

> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
>     Environment: Trunk
>Reporter: Susheel Kumar
>Priority: Minor
> Attachments: SOLR-8184.patch
>
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
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-7986) JDBC Driver for SQL Interface

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-7986:
-

Hi Kevin,

I have created SOLR-8184 for negative tests and i see some commonality
between the tests from 8179 & 8184. Interestingly the missing zookeeper
test doesn't get pass in either patch.

Thanks,
Susheel

On Wed, Oct 21, 2015 at 12:57 PM, Kevin Risden (JIRA) <j...@apache.org>



> JDBC Driver for SQL Interface
> -
>
> Key: SOLR-7986
> URL: https://issues.apache.org/jira/browse/SOLR-7986
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: Trunk
>Reporter: Joel Bernstein
> Fix For: Trunk
>
> Attachments: SOLR-7986-SPI.patch, SOLR-7986.patch, SOLR-7986.patch, 
> SOLR-7986.patch, SOLR-7986.patch, SOLR-7986.patch, SOLR-7986.patch, 
> SOLR-7986.patch, SOLR-7986.patch, SOLR-7986.patch
>
>
> This ticket is to create a JDBC Driver (thin client) for the new SQL 
> interface (SOLR-7560). As part of this ticket a driver will be added to the 
> Solrj libary under the package: *org.apache.solr.client.solrj.io.sql*
> Initial implementation will include basic *Driver*, *Connection*, *Statement* 
> and *ResultSet* implementations.
> Future releases can build on this implementation to support a wide range of 
> JDBC clients and tools.
> *Syntax using parallel Map/Reduce for aggregations*:
> {code}
> Properties props = new Properties();
> props.put("aggregationMode", "map_reduce");
> props.put("numWorkers", "10");
> Connection con = 
> DriverManager.getConnection("jdbc:solr://?collection=",
>  props);
> Statement stmt = con.createStatement();
> ResultSet rs = stmt.executeQuery("select a, sum(b) from tablex group by a 
> having sum(b) > 100");
> while(rs.next()) {
> String a = rs.getString("a");
> double sumB = rs.getDouble("sum(b)");
> }
> {code} 
> *Syntax using JSON facet API for aggregations*:
> {code}
> Properties props = new Properties();
> props.put("aggregationMode", "facet");
> Connection con = 
> DriverManager.getConnection("jdbc:solr://?collection=",
>  props);
> Statement stmt = con.createStatement();
> ResultSet rs = stmt.executeQuery("select a, sum(b) from tablex group by a 
> having sum(b) > 100");
> while(rs.next()) {
> String a = rs.getString("a");
> double sumB = rs.getDouble("sum(b)");
> }
> {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-7986) JDBC Driver for SQL Interface

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-7986:
-

Hi Joel,

Created SOLR-8184 and attached the patch with tests and linked to SOLR-8125.

Thanks,
Susheel

On Tue, Oct 20, 2015 at 9:15 PM, Joel Bernstein (JIRA) <j...@apache.org>



> JDBC Driver for SQL Interface
> -
>
> Key: SOLR-7986
> URL: https://issues.apache.org/jira/browse/SOLR-7986
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: Trunk
>Reporter: Joel Bernstein
> Fix For: Trunk
>
> Attachments: SOLR-7986-SPI.patch, SOLR-7986.patch, SOLR-7986.patch, 
> SOLR-7986.patch, SOLR-7986.patch, SOLR-7986.patch, SOLR-7986.patch, 
> SOLR-7986.patch, SOLR-7986.patch, SOLR-7986.patch
>
>
> This ticket is to create a JDBC Driver (thin client) for the new SQL 
> interface (SOLR-7560). As part of this ticket a driver will be added to the 
> Solrj libary under the package: *org.apache.solr.client.solrj.io.sql*
> Initial implementation will include basic *Driver*, *Connection*, *Statement* 
> and *ResultSet* implementations.
> Future releases can build on this implementation to support a wide range of 
> JDBC clients and tools.
> *Syntax using parallel Map/Reduce for aggregations*:
> {code}
> Properties props = new Properties();
> props.put("aggregationMode", "map_reduce");
> props.put("numWorkers", "10");
> Connection con = 
> DriverManager.getConnection("jdbc:solr://?collection=",
>  props);
> Statement stmt = con.createStatement();
> ResultSet rs = stmt.executeQuery("select a, sum(b) from tablex group by a 
> having sum(b) > 100");
> while(rs.next()) {
> String a = rs.getString("a");
> double sumB = rs.getDouble("sum(b)");
> }
> {code} 
> *Syntax using JSON facet API for aggregations*:
> {code}
> Properties props = new Properties();
> props.put("aggregationMode", "facet");
> Connection con = 
> DriverManager.getConnection("jdbc:solr://?collection=",
>  props);
> Statement stmt = con.createStatement();
> ResultSet rs = stmt.executeQuery("select a, sum(b) from tablex group by a 
> having sum(b) > 100");
> while(rs.next()) {
> String a = rs.getString("a");
> double sumB = rs.getDouble("sum(b)");
> }
> {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-7986) JDBC Driver for SQL Interface

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-7986:
-

Hi Joel,

I added locally 3 bad connection string tests. Please let me know your opinion 
before I provide a patch
a) The first below test "testConnectionStringWithMissingZKHost" throws 
SolrException than SQLException. Is that right behaviour. Just wanted to 
confirm.
b) Is it okay to add more public multiple tests method OR have one test method 
and calling various private test methods inside it. Any preference since I see 
the later is more common .
c) The test  "testConnectionStringWithWrongCollection" goes thru various 
retries before it fails. Below the console messages. Is that right behavior. 

Thanks,
Susheel



  @Test
  public void testConnectionStringWithMissingZKHost() throws Exception  {
   //should throw Solr exception as per current design
exception.expect(SolrException.class);
String zkHost = zkServer.getZkAddress();
Properties props = new Properties();
//bad connection string: missing zkHost
   Connection con = DriverManager.getConnection("jdbc:solr://"  + 
"?collection=collection1", props);
  }
  
  @Test
  public void testConnectionStringJumbled() throws Exception  {
//should throw SQL exception
 exception.expect(SQLException.class);
 Properties props = new Properties();
 String zkHost = zkServer.getZkAddress();
 //Bad connection string: string jumbled   
 Connection con = DriverManager.getConnection("solr:jdbc://" + zkHost + 
"?collection=collection1", props);
   }
  
  @Test
  public void testConnectionStringWithWrongCollection() throws Exception  {
 //should throw SQL exception
 exception.expect(SQLException.class);
 Properties props = new Properties();
 String zkHost = zkServer.getZkAddress();
 //Bad connection string: wrong collection name   
 Connection con = DriverManager.getConnection("jdbc:solr://" + zkHost + 
"?collection=mycollection", props);
 Statement stmt = con.createStatement();
 ResultSet rs = stmt.executeQuery("select id, a_i, a_s, a_f from 
mycollection order by a_i desc limit 2");

   } 

testConnectionStringWithWrongCollection console messages.
-
Sep 22, 2015 5:26:28 PM com.carrotsearch.randomizedtesting.ThreadLeakControl 
checkThreadLeaks
WARNING: Will linger awaiting termination of 6 leaked thread(s).
95116 WARN  
(TEST-JdbcTest.testConnectionStringWithWrongCollection-seed#[8ED3B3162E3AB02D]-SendThread(127.0.0.1:55137))
 [n:127.0.0.1:55092_cb_i%2Fof c:collection1 s:shard1 r:core_node4 
x:collection1] o.a.z.ClientCnxn Session 0x14ff6f24fcf0012 for server null, 
unexpected error, closing socket connection and attempting reconnect
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)
96786 WARN  
(TEST-JdbcTest.testConnectionStringWithWrongCollection-seed#[8ED3B3162E3AB02D]-SendThread(127.0.0.1:55137))
 [n:127.0.0.1:55092_cb_i%2Fof c:collection1 s:shard1 r:core_node4 
x:collection1] o.a.z.ClientCnxn Session 0x14ff6f24fcf0012 for server null, 
unexpected error, closing socket connection and attempting reconnect
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)
98838 WARN  
(TEST-JdbcTest.testConnectionStringWithWrongCollection-seed#[8ED3B3162E3AB02D]-SendThread(127.0.0.1:55137))
 [n:127.0.0.1:55092_cb_i%2Fof c:collection1 s:shard1 r:core_node4 
x:collection1] o.a.z.ClientCnxn Session 0x14ff6f24fcf0012 for server null, 
unexpected error, closing socket connection and attempting reconnect
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)
100696 WARN  
(TEST-JdbcTest.testConnectionStringWithWrongCollection-seed#[8ED3B3162E3AB02D]-SendThread(127.0.0.1:55137))
 [n:127.0.0.1:55092_cb_i%2Fof c:collection1 s:shard1 r:core_node4 
x:collection1] o.a.z.ClientCnxn Session 0x14ff6f24fcf0012 for server null, 
unexpected error, closin

[jira] [Commented] (SOLR-8002) Field aliases support for SQL queries

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-8002:
-

Thanks, Dennis for the explanation & I agree with the approach that either SQL 
statement or String Expression would be converted to Stream Expression object.

> Field aliases support for SQL queries
> -
>
> Key: SOLR-8002
> URL: https://issues.apache.org/jira/browse/SOLR-8002
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: Trunk
>    Reporter: Susheel Kumar
>
> Currently field aliases are not supported for SQL queries against SQL 
> Handler. E.g. below SQL query
>  select id,name as product_name from techproducts limit 20
> currently fails as data returned contains still "name" as the field/column 
> key than product_name



--
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-8002) Field aliases support for SQL queries

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-8002:
-

Agree, Joel that this is tricky to start.  I'll anyway continue with more tests 
and will look into SOLR-7986 as well.  

> Field aliases support for SQL queries
> -
>
> Key: SOLR-8002
> URL: https://issues.apache.org/jira/browse/SOLR-8002
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: Trunk
>    Reporter: Susheel Kumar
>
> Currently field aliases are not supported for SQL queries against SQL 
> Handler. E.g. below SQL query
>  select id,name as product_name from techproducts limit 20
> currently fails as data returned contains still "name" as the field/column 
> key than product_name



--
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-8002) Field aliases support for SQL queries

[Susheel Kumar (JIRA)]

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

Susheel Kumar edited comment on SOLR-8002 at 9/9/15 5:03 AM:
-

Hi Joel, Davis,

Just to clarify that utilizing the SelectStream in SQL api (SQLHandler.java) 
would require transforming the SQL expression into SOLR streaming expressions 
for SelectStream to work. So for e.g. SQL expression

select id, field_i, str_s from collection1 where text='' order by field_i 
desc  

would be transformed to Solr Streaming expression 

search(collection1, q="text:", fl="id,field_i,str_s", sort="field_i desc")

Please let me know your thoughts on this.

Thanks,
Susheel

  





was (Author: susheel2...@gmail.com):
Hi Joel, Davis,

Just to clarify that utilizing the SelectStream in SQL api (SQLHandler.java) 
would require transforming the SQL expression into SOLR streaming expressions 
for SelectStream to work. So for e.g. SQL expression

select id, field_i, str_s from collection1 where text='' order by field_i 
desc  

would be transformed to

search(collection1, q="text:", fl="id,field_i,str_s", sort="field_i desc")

Please let me know your thoughts on this.

Thanks,
Susheel

  




> Field aliases support for SQL queries
> -
>
> Key: SOLR-8002
> URL: https://issues.apache.org/jira/browse/SOLR-8002
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: Trunk
>Reporter: Susheel Kumar
>
> Currently field aliases are not supported for SQL queries against SQL 
> Handler. E.g. below SQL query
>  select id,name as product_name from techproducts limit 20
> currently fails as data returned contains still "name" as the field/column 
> key than product_name



--
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-8002) Field aliases support for SQL queries

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-8002:
-

Hi Joel, Davis,

Just to clarify that utilizing the SelectStream in SQL api (SQLHandler.java) 
would require transforming the SQL expression into SOLR streaming expressions 
for SelectStream to work. So for e.g. SQL expression

select id, field_i, str_s from collection1 where text='' order by field_i 
desc  

would be transformed to

search(collection1, q="text:", fl="id,field_i,str_s", sort="field_i desc")

Please let me know your thoughts on this.

Thanks,
Susheel

  




> Field aliases support for SQL queries
> -
>
> Key: SOLR-8002
> URL: https://issues.apache.org/jira/browse/SOLR-8002
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>    Affects Versions: Trunk
>Reporter: Susheel Kumar
>
> Currently field aliases are not supported for SQL queries against SQL 
> Handler. E.g. below SQL query
>  select id,name as product_name from techproducts limit 20
> currently fails as data returned contains still "name" as the field/column 
> key than product_name



--
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-8002) Field aliases support for SQL queries

[Susheel Kumar (JIRA)]

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

Susheel Kumar edited comment on SOLR-8002 at 9/9/15 5:04 AM:
-

Hi Joel, Davis,

Just to clarify that utilizing the SelectStream in SQL api (SQLHandler.java) 
would require transforming the SQL expression into SOLR streaming expressions 
for SelectStream to work. So for e.g. SQL expression

select id, field_i, str_s from collection1 where text='' order by field_i 
desc  

would be transformed to Solr Streaming expression 

search(collection1, q="text:", fl="id,field_i,str_s", sort="field_i desc")

Please let me know your thoughts & if that is the correct understanding.

Thanks,
Susheel

  





was (Author: susheel2...@gmail.com):
Hi Joel, Davis,

Just to clarify that utilizing the SelectStream in SQL api (SQLHandler.java) 
would require transforming the SQL expression into SOLR streaming expressions 
for SelectStream to work. So for e.g. SQL expression

select id, field_i, str_s from collection1 where text='' order by field_i 
desc  

would be transformed to Solr Streaming expression 

search(collection1, q="text:", fl="id,field_i,str_s", sort="field_i desc")

Please let me know your thoughts on this.

Thanks,
Susheel

  




> Field aliases support for SQL queries
> -
>
> Key: SOLR-8002
> URL: https://issues.apache.org/jira/browse/SOLR-8002
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: Trunk
>Reporter: Susheel Kumar
>
> Currently field aliases are not supported for SQL queries against SQL 
> Handler. E.g. below SQL query
>  select id,name as product_name from techproducts limit 20
> currently fails as data returned contains still "name" as the field/column 
> key than product_name



--
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-8002) Field aliases support for SQL queries

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-8002:
-

Sure, Joel.  Let me start looking into the patch SOLR-7669. 

> Field aliases support for SQL queries
> -
>
> Key: SOLR-8002
> URL: https://issues.apache.org/jira/browse/SOLR-8002
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: Trunk
>    Reporter: Susheel Kumar
>
> Currently field aliases are not supported for SQL queries against SQL 
> Handler. E.g. below SQL query
>  select id,name as product_name from techproducts limit 20
> currently fails as data returned contains still "name" as the field/column 
> key than product_name



--
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-7560) Parallel SQL Support

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-7560:
-

Hi Joel,

I have created a JIRA SOLR-8002 for field aliases.  Also noticed the JIRA 
SOLR-7986 you have created and design thoughts on creating Connection, 
Statement & ResultSet classes.  

Thanks,
Susheel

> Parallel SQL Support
> 
>
> Key: SOLR-7560
> URL: https://issues.apache.org/jira/browse/SOLR-7560
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java, search
>Reporter: Joel Bernstein
> Fix For: Trunk
>
> Attachments: SOLR-7560.calcite.patch, SOLR-7560.patch, 
> SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch
>
>
> This ticket provides support for executing *Parallel SQL* queries across 
> SolrCloud collections. The SQL engine will be built on top of the Streaming 
> API (SOLR-7082), which provides support for *parallel relational algebra* and 
> *real-time map-reduce*.
> Basic design:
> 1) A new SQLHandler will be added to process SQL requests. The SQL statements 
> will be compiled to live Streaming API objects for parallel execution across 
> SolrCloud worker nodes.
> 2) SolrCloud collections will be abstracted as *Relational Tables*. 
> 3) The Presto SQL parser will be used to parse the SQL statements.
> 4) A JDBC thin client will be added as a Solrj client.
> This ticket will focus on putting the framework in place and providing basic 
> SELECT support and GROUP BY aggregate support.
> Future releases will build on this framework to provide additional SQL 
> features.



--
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-8002) Field aliases support for SQL queries

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-8002:
---

 Summary: Field aliases support for SQL queries
 Key: SOLR-8002
 URL: https://issues.apache.org/jira/browse/SOLR-8002
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: Trunk
Reporter: Susheel Kumar


Currently field aliases are not supported for SQL queries against SQL Handler. 
E.g. below SQL query

 select id,name as product_name from techproducts limit 20

currently fails as data returned contains still "name" as the field/column key 
than product_name



--
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: Create JIRA ticket permissions

[Susheel Kumar]

Thanks, Shalin.  My bad that i couldn't figure out Create button & little
arrow next to it are two different clicks.

On Tue, Sep 1, 2015 at 2:46 AM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> You just need to sign up for the Jira account. Every new user has
> permissions to create a new issue.
>
> On Tue, Sep 1, 2015 at 7:15 AM, Susheel Kumar <susheel2...@gmail.com>
> wrote:
> > Hello,
> >
> > I wanted to create JIRA tickets for Parallel SQL Support / SQL Handler.
> I
> > think I am not having the rights to create it.  Please suggest.
> >
> > Thanks,
> > Susheel
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Create JIRA ticket permissions

[Susheel Kumar]

Hello,

I wanted to create JIRA tickets for Parallel SQL Support / SQL Handler.  I
think I am not having the rights to create it.  Please suggest.

Thanks,
Susheel

[jira] [Commented] (SOLR-7560) Parallel SQL Support

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-7560:
-

Thanks, Joel. I'll try to write tests around the supported features. Do you 
have any list of items/tickets for future releases or If I can help to 
maintain.  Also i will try to understand how presto is being plugged with Solr 
but if you have any pointers please let me know.

 Parallel SQL Support
 

 Key: SOLR-7560
 URL: https://issues.apache.org/jira/browse/SOLR-7560
 Project: Solr
  Issue Type: New Feature
  Components: clients - java, search
Reporter: Joel Bernstein
 Fix For: Trunk

 Attachments: SOLR-7560.calcite.patch, SOLR-7560.patch, 
 SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch


 This ticket provides support for executing *Parallel SQL* queries across 
 SolrCloud collections. The SQL engine will be built on top of the Streaming 
 API (SOLR-7082), which provides support for *parallel relational algebra* and 
 *real-time map-reduce*.
 Basic design:
 1) A new SQLHandler will be added to process SQL requests. The SQL statements 
 will be compiled to live Streaming API objects for parallel execution across 
 SolrCloud worker nodes.
 2) SolrCloud collections will be abstracted as *Relational Tables*. 
 3) The Presto SQL parser will be used to parse the SQL statements.
 4) A JDBC thin client will be added as a Solrj client.
 This ticket will focus on putting the framework in place and providing basic 
 SELECT support and GROUP BY aggregate support.
 Future releases will build on this framework to provide additional SQL 
 features.



--
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-7560) Parallel SQL Support

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-7560:
-

Hi Joel,

I started with two basic tests on my local box
a) add field alias e.g. 
select id,name as product_name from techproducts limit 20

 which currently fails as data returned contains still name as the 
field/column key than product_name 

b) I wanted to get additional field returned from SQL e.g 
select id,name,manu,mul(price,weight) from techproducts limit 20
which currently fails with error Aggregate functions only supported with group 
by queries.  while actually I just want to have additional calculated field 
based on some function/formula for every document.  I checked SQLHandler.java 
which currently throws this out due to presence of parenthesis without any 
group by/aggregate function.

Please let me know your suggestion on this. 

Thanks,
Susheel 



 Parallel SQL Support
 

 Key: SOLR-7560
 URL: https://issues.apache.org/jira/browse/SOLR-7560
 Project: Solr
  Issue Type: New Feature
  Components: clients - java, search
Reporter: Joel Bernstein
 Fix For: Trunk

 Attachments: SOLR-7560.calcite.patch, SOLR-7560.patch, 
 SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch


 This ticket provides support for executing *Parallel SQL* queries across 
 SolrCloud collections. The SQL engine will be built on top of the Streaming 
 API (SOLR-7082), which provides support for *parallel relational algebra* and 
 *real-time map-reduce*.
 Basic design:
 1) A new SQLHandler will be added to process SQL requests. The SQL statements 
 will be compiled to live Streaming API objects for parallel execution across 
 SolrCloud worker nodes.
 2) SolrCloud collections will be abstracted as *Relational Tables*. 
 3) The Presto SQL parser will be used to parse the SQL statements.
 4) A JDBC thin client will be added as a Solrj client.
 This ticket will focus on putting the framework in place and providing basic 
 SELECT support and GROUP BY aggregate support.
 Future releases will build on this framework to provide additional SQL 
 features.



--
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-7560) Parallel SQL Support

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-7560:
-

Thanks, Eric for pointing server dist target. Now I am able to run basic SQL.  
Will start looking into deeper.

 Parallel SQL Support
 

 Key: SOLR-7560
 URL: https://issues.apache.org/jira/browse/SOLR-7560
 Project: Solr
  Issue Type: New Feature
  Components: clients - java, search
Reporter: Joel Bernstein
 Fix For: Trunk

 Attachments: SOLR-7560.calcite.patch, SOLR-7560.patch, 
 SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch


 This ticket provides support for executing *Parallel SQL* queries across 
 SolrCloud collections. The SQL engine will be built on top of the Streaming 
 API (SOLR-7082), which provides support for *parallel relational algebra* and 
 *real-time map-reduce*.
 Basic design:
 1) A new SQLHandler will be added to process SQL requests. The SQL statements 
 will be compiled to live Streaming API objects for parallel execution across 
 SolrCloud worker nodes.
 2) SolrCloud collections will be abstracted as *Relational Tables*. 
 3) The Presto SQL parser will be used to parse the SQL statements.
 4) A JDBC thin client will be added as a Solrj client.
 This ticket will focus on putting the framework in place and providing basic 
 SELECT support and GROUP BY aggregate support.
 Future releases will build on this framework to provide additional SQL 
 features.



--
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-7560) Parallel SQL Support

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-7560:
-

Hi,

I can help to test the Parallel SQL Support feature which is very useful for 
analytical purpose.  Can I get some info on setting up SQLHandler / some 
instructions to get started.

Thanks,
Susheel

 Parallel SQL Support
 

 Key: SOLR-7560
 URL: https://issues.apache.org/jira/browse/SOLR-7560
 Project: Solr
  Issue Type: New Feature
  Components: clients - java, search
Reporter: Joel Bernstein
 Fix For: Trunk

 Attachments: SOLR-7560.calcite.patch, SOLR-7560.patch, 
 SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch


 This ticket provides support for executing *Parallel SQL* queries across 
 SolrCloud collections. The SQL engine will be built on top of the Streaming 
 API (SOLR-7082), which provides support for *parallel relational algebra* and 
 *real-time map-reduce*.
 Basic design:
 1) A new SQLHandler will be added to process SQL requests. The SQL statements 
 will be compiled to live Streaming API objects for parallel execution across 
 SolrCloud worker nodes.
 2) SolrCloud collections will be abstracted as *Relational Tables*. 
 3) The Presto SQL parser will be used to parse the SQL statements.
 4) A JDBC thin client will be added as a Solrj client.
 This ticket will focus on putting the framework in place and providing basic 
 SELECT support and GROUP BY aggregate support.
 Future releases will build on this framework to provide additional SQL 
 features.



--
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-7560) Parallel SQL Support

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-7560:
-

Thanks, Joel. Found the SQLHandler config and I did checkout the trunk and 
compiled using 'ant compile' but getting error when starting solr. Will look 
into classpath which may be causing the issue.  

./bin/solr status

Found 1 Solr nodes: 

Solr process 11789 running on port 8983
Error: Could not find or load main class org.apache.solr.util.SolrCLI.



 Parallel SQL Support
 

 Key: SOLR-7560
 URL: https://issues.apache.org/jira/browse/SOLR-7560
 Project: Solr
  Issue Type: New Feature
  Components: clients - java, search
Reporter: Joel Bernstein
 Fix For: Trunk

 Attachments: SOLR-7560.calcite.patch, SOLR-7560.patch, 
 SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch


 This ticket provides support for executing *Parallel SQL* queries across 
 SolrCloud collections. The SQL engine will be built on top of the Streaming 
 API (SOLR-7082), which provides support for *parallel relational algebra* and 
 *real-time map-reduce*.
 Basic design:
 1) A new SQLHandler will be added to process SQL requests. The SQL statements 
 will be compiled to live Streaming API objects for parallel execution across 
 SolrCloud worker nodes.
 2) SolrCloud collections will be abstracted as *Relational Tables*. 
 3) The Presto SQL parser will be used to parse the SQL statements.
 4) A JDBC thin client will be added as a Solrj client.
 This ticket will focus on putting the framework in place and providing basic 
 SELECT support and GROUP BY aggregate support.
 Future releases will build on this framework to provide additional SQL 
 features.



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