Thanks again Shawn for your comments. I am little worried about the multi threading of web application which uses servlets.
I also found one of your explanation (please confirm the same whether its your comment only) in http://lucene.472066.n3.nabble.com/Memory-problems-with-HttpSolrServer-td4060985.html for the question : http://stackoverflow.com/questions/11931179/httpsolrserver-instance-management As you said correctly that creation of SolrServer object depends on number of shards/solrcores and thereafter need to think for implementation which may use singleton pattern. In my web application side, I have only one solrcore which is default one "collection1" so I will create one SolrServer object for my application. Sure If we decide to go for Solr Cloud then also I will create one object. Thanks Upayavira, yes I will do the re-index. Anything you want to suggest as you did the same migration. Thanks Sandeep On Thu, Jun 27, 2013 at 1:33 PM, Upayavira <u...@odoko.co.uk> wrote: > I have done this - upgraded a 1.4 index to 3.x then on to 4.x. It > worked, but... > > New field types have been introduced over time that facilitate new > functionality. To continue to use an upgraded index, you need to > continue using the old field types, and thus loose some of the coolness > of newer versions. > > So, a re-index will set you in far better stead, if it is at all > possible. > > Upayavira > > On Tue, Jun 25, 2013, at 06:37 PM, Erick Erickson wrote: > > bq: I'm not sure if Solr 4.3 will be able to read Solr 1.4 indexes > > > > Solr/Lucene explicitly try to read _one_ major revision backwards. > > Solr 3.x should be able to read 1.4 indexes. Solr 4.x should be > > able to read Solr 3.x. No attempt is made to allow Solr 4.x to read > > Solr 1.4 indexes, so I wouldn't even try. > > > > Shalin's comment is best. If at all possible I'd just forget about > > reading the old index and re-index from scratch. But if you _do_ > > try upgrading 1.4 -> 3.x -> 4.x, you probably want to optimize > > at each step. That'll (I think) rewrite all the segments in the > > current format. > > > > Good luck! > > Erick > > > > On Tue, Jun 25, 2013 at 12:59 AM, Shalin Shekhar Mangar > > <shalinman...@gmail.com> wrote: > > > You must carefully go through the upgrade instructions starting from > > > 1.4 upto 4.3. In particular the instructions for 1.4 to 3.1 and from > > > 3.1 to 4.0 should be given special attention. > > > > > > On Tue, Jun 25, 2013 at 11:43 AM, Sandeep Gupta <gupta...@gmail.com> > wrote: > > >> Hello All, > > >> > > >> We are planning to migrate solr 1.4 to Solr 4.3 version. > > >> And I am seeking some help in this side. > > >> > > >> Considering Schema file change: > > >> By default there are lots of changes if I compare original Solr 1.4 > schema > > >> file to Sol 4.3 schema file. > > >> And that is the reason we are not copying paste of schema file. > > >> In our Solr 1.4 schema implementation, we have some custom fields > with type > > >> "textgen" and "text" > > >> So in migration of these custom fields to Solr 4.3, should I use > type of > > >> "text_general" as replacement of "textgen" and > > >> "text_en" as replacement of "text"? > > >> Please confirm the same. > > > > > > Please check the text_general definition in 4.3 against the textgen > > > fieldtype in Solr 1.4 to see if they're equivalent. Same for text_en > > > and text. > > > > > >> > > >> Considering Solrconfig change: > > >> As we didn't have lots of changes in 1.4 solrconfig file except the > > >> dataimport request handler. > > >> And therefore in migration side, we are simply modifying the Solr 4.3 > > >> solrconfig file with his request handler. > > > > > > And you need to add the dataimporthandler jar into Solr's lib > > > directory. DIH is not added automatically anymore. > > > > > >> > > >> Considering the application development: > > >> > > >> We used all the queries as BOOLEAN type style (was not good) I mean > put > > >> all the parameter in query fields i.e > > >> *:* AND EntityName: <<>> AND <fileName>:<fieldValue> AND ..... > > >> > > >> I think we should simplify our queries using other fields like df, qf > .... > > >> > > > > > > Probably. AND queries are best done by filter queries (fq). > > > > > >> We also used to create Solr server object via CommonsHttpSolrServer() > so I > > >> am planning to use now HttpSolrServer API> > > > > > > Yes. Also, there was a compatibility break between Solr 1.4 and 3.1 in > > > the javabin format so old clients using javabin won't be able to > > > communicate with Solr until you upgrade both solr client and solr > > > servers. > > > > > >> > > >> Please let me know the suggestion for above points also what are the > other > > >> factors I need to take care while considering the migration. > > > > > > There is no substitute for reading the upgrade sections in the > changes.txt. > > > > > > I'm not sure if Solr 4.3 will be able to read Solr 1.4 indexes. You > > > will most likely need to re-index your documents. > > > > > > You should also think about switching to SolrCloud to take advantage > > > of its features. > > > > > > -- > > > Regards, > > > Shalin Shekhar Mangar. >
