Re: Portability of Solr index

[mukesh katariya]

There is a problem with Base64 encoding. There is a project specific
requirement where i need to do some processing on solr string field type and
then base64 encode it. I was using Sun's base64 encoder which is dependent
on the JRE of the system. So when i used to index the base64 it was adding
system specific new line character after every 77 characters.   I googled a
bit and changed the base64 encoder to apache codec  for base64 encoding.
this fixed the problem. 


Thanks for all your time and help.

Best Regards
Mukesh Katariya



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Portability-of-Solr-index-tp4061829p4062230.html
Sent from the Solr - User mailing list archive at Nabble.com.

Portability of Solr index

[mukesh katariya]

I have built a SOLR Index on Windows 7 Enterprise, 64 Bit. I copy the index
to Centos release 6.2, 32 Bit OS.

The index is readable and the application is able to load data from the
index on Linux. But there are a few fields on which FQ Queries dont work on
Linux , but same FQ Query work on windows.

I have a situation where in i have to prepare index on windows and port it
on Linux. I need the index to be portable.

The only thing which is not working is the FQ Queries.

Inside the BlockTreeTermsReader seekExact API, I have enabled debugging and
system out statements scanToTermLeaf: block fp=1705107 prefix=0 nextEnt=0
(of 167)
target=1RD0JIHMr9aw4RPPuS0DVzB2tKf38FfjKaEg7HsYDd7EtAOpE9FYvvj5ryB7679r4KNnlIaze‌​vPo
h7qabtLhXw== [31 52 44 30 4a 49 48 4d 72 39 61 77 34 52 50 50 75 53 30 44 56
7a 42 32 74 4b 66 33 38 46 66 6a 4b 61 45 67 37 48 73 59 44 64 37 45 74 41
4f 70 45 39 46 59 76 76 6a 35 72 79 42 37 36 37 39 72 34 4b 4e 6e 6c 49 61
7a 65 76 50 6f d a 68 37 71 61 62 74 4c 68 58 77 3d 3d] term= [] This is a
Term Query, and target bytes to match
   
As per the algorithm it runs through the term and tries to match , now the
6th term is a exact match, but there is a problem of few bytescycle: term 6
(of 167)
suffix=1RD0JIHMr9aw4RPPuS0DVzB2tKf38FfjKaEg7HsYDd7EtAOpE9FYvvj5ryB7679r4KNnlIaze‌​vPo
h7qabtLhXw== [31 52 44 30 4a 49 48 4d 72 39 61 77 34 52 50 50 75 53 30 44 56
7a 42 32 74 4b 66 33 38 46 66 6a 4b 61 45 67 37 48 73 59 44 64 37 45 74 41
4f 70 45 39 46 59 76 76 6a 35 72 79 42 37 36 37 39 72 34 4b 4e 6e 6c 49 61
7a 65 76 50 6f a 68 37 71 61 62 74 4c 68 58 77 3d 3d] Prefix:=0 Suffix:=89
target.offset:=0 target.length :=90 targetLimit :=89
   
from the first section 50 6f d a 68 37 from the second section 50 6f a 68
37. The test scenario is the index is built on linux and i am testing the
index through solr api on windows machine.



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Portability-of-Solr-index-tp4061794.html
Sent from the Solr - User mailing list archive at Nabble.com.

Portability of Solr index

[mukesh katariya]

I have built a SOLR Index on Windows 7 Enterprise, 64 Bit. I copy the index
to Centos release 6.2, 32 Bit OS.

The index is readable and the application is able to load data from the
index on Linux. But there are a few fields on which FQ Queries dont work on
Linux , but same FQ Query work on windows.

I have a situation where in i have to prepare index on windows and port it
on Linux. I need the index to be portable.

The only thing which is not working is the FQ Queries.

Inside the BlockTreeTermsReader seekExact API, I have enabled debugging and
system out statements scanToTermLeaf: block fp=1705107 prefix=0 nextEnt=0
(of 167)
target=1RD0JIHMr9aw4RPPuS0DVzB2tKf38FfjKaEg7HsYDd7EtAOpE9FYvvj5ryB7679r4KNnlIaze‌​vPo
h7qabtLhXw== [31 52 44 30 4a 49 48 4d 72 39 61 77 34 52 50 50 75 53 30 44 56
7a 42 32 74 4b 66 33 38 46 66 6a 4b 61 45 67 37 48 73 59 44 64 37 45 74 41
4f 70 45 39 46 59 76 76 6a 35 72 79 42 37 36 37 39 72 34 4b 4e 6e 6c 49 61
7a 65 76 50 6f d a 68 37 71 61 62 74 4c 68 58 77 3d 3d] term= [] This is a
Term Query, and target bytes to match 

As per the algorithm it runs through the term and tries to match , now the
6th term is a exact match, but there is a problem of few bytescycle: term 6
(of 167)
suffix=1RD0JIHMr9aw4RPPuS0DVzB2tKf38FfjKaEg7HsYDd7EtAOpE9FYvvj5ryB7679r4KNnlIaze‌​vPo
h7qabtLhXw== [31 52 44 30 4a 49 48 4d 72 39 61 77 34 52 50 50 75 53 30 44 56
7a 42 32 74 4b 66 33 38 46 66 6a 4b 61 45 67 37 48 73 59 44 64 37 45 74 41
4f 70 45 39 46 59 76 76 6a 35 72 79 42 37 36 37 39 72 34 4b 4e 6e 6c 49 61
7a 65 76 50 6f a 68 37 71 61 62 74 4c 68 58 77 3d 3d] Prefix:=0 Suffix:=89
target.offset:=0 target.length :=90 targetLimit :=89 

from the first comment 50 6f d a 68 37 from the second comment 50 6f a 68
37. The test scenario is the index is built on linux and i am testing the
index through solr api on windows machine. 



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Portability-of-Solr-index-tp4061783.html
Sent from the Solr - User mailing list archive at Nabble.com.