Re: SolrJ best pratices

2013-10-09 Thread Furkan KAMACI
I suggest you to look at here:
http://wiki.apache.org/solr/Solrj?action=fullsearchcontext=180value=cloudsolrservertitlesearch=Titles#Using_with_SolrCloud


2013/10/9 Shawn Heisey s...@elyograg.org

 On 10/7/2013 3:08 PM, Mark wrote:

 Some specific questions:
 - When working with HttpSolrServer should we keep around instances for
 ever or should we create a singleton that can/should be used over and over?
 - Is there a way to change the collection after creating the server or do
 we need to create a new server for each collection?


 If at all possible, you should create your server object and use it for
 the life of your application.  SolrJ is threadsafe.  If there is any part
 of it that's not, the javadocs should say so - the SolrServer
 implementations definitely are.

 By using the word collection you are implying that you are using
 SolrCloud ... but earlier you said HttpSolrServer, which implies that you
 are NOT using SolrCloud.

 With HttpSolrServer, your base URL includes the core or collection name -
 http://server:port/solr/**corename; for example.  Generally you will
 need one object for each core/collection, and another object for
 server-level things like CoreAdmin.

 With SolrCloud, you should be using CloudSolrServer instead, another
 implementation of SolrServer that is constantly aware of the SolrCloud
 clusterstate.  With that object, you can use setDefaultCollection, and you
 can also add a collection parameter to each SolrQuery or other request
 object.

 Thanks,
 Shawn




Re: SolrJ best pratices

2013-10-09 Thread Mark
Thanks for the clarification.

In Solr Cloud just use 1 connection. In non-cloud environments you will need 
one per core.



On Oct 8, 2013, at 5:58 PM, Shawn Heisey s...@elyograg.org wrote:

 On 10/7/2013 3:08 PM, Mark wrote:
 Some specific questions:
 - When working with HttpSolrServer should we keep around instances for ever 
 or should we create a singleton that can/should be used over and over?
 - Is there a way to change the collection after creating the server or do we 
 need to create a new server for each collection?
 
 If at all possible, you should create your server object and use it for the 
 life of your application.  SolrJ is threadsafe.  If there is any part of it 
 that's not, the javadocs should say so - the SolrServer implementations 
 definitely are.
 
 By using the word collection you are implying that you are using SolrCloud 
 ... but earlier you said HttpSolrServer, which implies that you are NOT using 
 SolrCloud.
 
 With HttpSolrServer, your base URL includes the core or collection name - 
 http://server:port/solr/corename; for example.  Generally you will need one 
 object for each core/collection, and another object for server-level things 
 like CoreAdmin.
 
 With SolrCloud, you should be using CloudSolrServer instead, another 
 implementation of SolrServer that is constantly aware of the SolrCloud 
 clusterstate.  With that object, you can use setDefaultCollection, and you 
 can also add a collection parameter to each SolrQuery or other request 
 object.
 
 Thanks,
 Shawn
 



Re: SolrJ best pratices

2013-10-08 Thread Shawn Heisey

On 10/7/2013 3:08 PM, Mark wrote:

Some specific questions:
- When working with HttpSolrServer should we keep around instances for ever or 
should we create a singleton that can/should be used over and over?
- Is there a way to change the collection after creating the server or do we 
need to create a new server for each collection?


If at all possible, you should create your server object and use it for 
the life of your application.  SolrJ is threadsafe.  If there is any 
part of it that's not, the javadocs should say so - the SolrServer 
implementations definitely are.


By using the word collection you are implying that you are using 
SolrCloud ... but earlier you said HttpSolrServer, which implies that 
you are NOT using SolrCloud.


With HttpSolrServer, your base URL includes the core or collection name 
- http://server:port/solr/corename; for example.  Generally you will 
need one object for each core/collection, and another object for 
server-level things like CoreAdmin.


With SolrCloud, you should be using CloudSolrServer instead, another 
implementation of SolrServer that is constantly aware of the SolrCloud 
clusterstate.  With that object, you can use setDefaultCollection, and 
you can also add a collection parameter to each SolrQuery or other 
request object.


Thanks,
Shawn



SolrJ best pratices

2013-10-07 Thread Mark
Are there any links describing best practices for interacting with SolrJ? I've 
checked the wiki and it seems woefully incomplete: 
(http://wiki.apache.org/solr/Solrj)

Some specific questions:
- When working with HttpSolrServer should we keep around instances for ever or 
should we create a singleton that can/should be used over and over? 
- Is there a way to change the collection after creating the server or do we 
need to create a new server for each collection?
-..