Best field type for boosting all documents

[Ashwin Ramesh]

Hi everybody,

We have a usecase where we want to push a popularity boost for each
document in our collection. When a user searches for any term, we would
like to arbitrarily add an additional boost by this value (which is
different for each document).

E.g. q=foo&boost=def(popularityBoostField,1)

Should we define the field 'popularityBoostField' as a docValue or regular
field?

If the field is sparsely filled, will that cause any issues?

Regards,

Ash

-- 
*P.S. We've launched a new blog to share the latest ideas and case studies 
from our team. Check it out here: product.canva.com 
. ***
** Empowering the 
world to design
Also, we're hiring. Apply here! 

  
  
    
  

Rename field in all documents from `i_itemNumber_l` to `i_itemNumber_cp_l`

[Sebastian Riemer]

Dear mailing list,

I would like to know:

Is there some simple way to rename a field in all documents in my solr index?

I am using a dynamic schema definition, and I've introduced some new 
copyField-instructions. Those make it necessary to reindex all documents. It 
would help me a great deal to be able to rename a specific field from:

`i_itemNumber_l` to `i_itemNumber_cp_l`

I don't really mind to reindex all documents too, but that takes some time and 
having my (old) documents return NULL as value for the field 
`i_itemNumber_cp_l` is breaking a lot of stuff.

So if there _IS_ a way to rename that field, that would help tremendously. Btw. 
I am using Solr 6.5.1 and I use SolrJ in my ApplicationLayer.

Best regards and as always,

Thank you so much for any input!


Yours,
Sebastian

Mit freundlichen Grüßen
Sebastian Riemer, BSc


[logo_Littera_SC]
LITTERA Software & Consulting GmbH
A-6060 Hall i.T., Haller Au 19a
Telefon: +43(0) 50 765 000, Fax: +43(0) 50 765 118
Sitz: Hall i.T., eingetragen beim Handelsgericht Innsbruck,
Firmenbuch-Nr. FN 295807k, geschäftsführender Gesellschafter: Albert 
Unterkircher

D-80637 München, Landshuter Allee 8-10
Telefon: +49(0) 89 919 29 122, Fax: +49(0) 89 919 29 123
Sitz: München, eingetragen beim Amtsgericht München
unter HRB 103698, Geschäftsführer: Albert Unterkircher
E-Mail: off...@littera.eumailto:off...@littera.eu>
Homepage: www.littera.eu

Diese Nachricht kann vertrauliche, nicht für die Veröffentlichung bestimmte 
und/oder rechtlich geschützte Informationen enthalten. Falls Sie nicht der 
beabsichtigte Empfänger sind, beachten Sie bitte, dass jegliche 
Veröffentlichung, Verbreitung oder Vervielfältigung dieser Nachricht 
strengstens untersagt ist. Sollten Sie diese Nachricht irrtümlich erhalten 
haben, informieren Sie bitte sofort den Absender durch Anruf oder Rücksendung 
der Nachricht und vernichten Sie diese.

This communication may contain information that is legally privileged, 
confidential or exempt from disclosure.  If you are not the intended recipient, 
please note that any dissemination, distribution, or copying of this 
communication is strictly prohibited.  Anyone who receives this message in 
error should notify the sender immediately by telephone or by return e-mail and 
delete this communication entirely from his or her computer.

Re: Best field type for boosting all documents

[Paras Lehana]

Hey Ashwin,

We, at Auto-Suggest, had the similar requirement. We wanted to boost
suggestions as per their demand. For this, we also introduced a new
*integer* field *demand*. We simply boosted it by (we use some mathematical
transformations so showing the basic version here):

*&boost=demand*


We use eDismax query parser. Since this is a numeric field, you get the
uninverted index (uninvertible = true) by default. Anyways, as the
recommendations in docValues section

suggests
using docValues for fields on you expect to do faceting, sorting and
function queries, we enabled docValues for demand and tried the performance
gain in using boost for demand.
*Well, we didn't see any significant gains by enabling docValues on a
numeric field. *



On Mon, 16 Sep 2019 at 12:57, Ashwin Ramesh  wrote:

> Hi everybody,
>
> We have a usecase where we want to push a popularity boost for each
> document in our collection. When a user searches for any term, we would
> like to arbitrarily add an additional boost by this value (which is
> different for each document).
>
> E.g. q=foo&boost=def(popularityBoostField,1)
>
> Should we define the field 'popularityBoostField' as a docValue or regular
> field?
>
> If the field is sparsely filled, will that cause any issues?
>
> Regards,
>
> Ash
>
> --
> *P.S. We've launched a new blog to share the latest ideas and case studies
> from our team. Check it out here: product.canva.com
> . ***
> ** Empowering the
> world to design
> Also, we're hiring. Apply here!
> 
>  
>  
>   
>   
>
>
>
>
>
>
>

-- 
-- 
Regards,

*Paras Lehana* [65871]
Software Programmer, Auto-Suggest,
IndiaMART Intermesh Ltd.

8th Floor, Tower A, Advant-Navis Business Park, Sector 142,
Noida, UP, IN - 201303

Mob.: +91-9560911996
Work: 01203916600 | Extn:  *8173*

-- 
IMPORTANT: 
NEVER share your IndiaMART OTP/ Password with anyone.

Re: Rename field in all documents from `i_itemNumber_l` to `i_itemNumber_cp_l`

[Alexandre Rafalovitch]

I don't think you can rename it in the index.

However, you may be able to rename it during the query:
https://lucene.apache.org/solr/guide/6_6/common-query-parameters.html#CommonQueryParameters-FieldNameAliases

Or, if you use eDisMax, during query rewriting:
https://lucene.apache.org/solr/guide/6_6/the-extended-dismax-query-parser.html
, see example at:
https://github.com/arafalov/solr-indexing-book/blob/master/published/languages/conf/solrconfig.xml#L20-L21

These two may need to play together actually, if you want it to be fully
transparent to the client code. See the #37 of the example above.

Regards,
   Alex.


On Mon, 16 Sep 2019 at 03:54, Sebastian Riemer  wrote:

> Dear mailing list,
>
>
>
> I would like to know:
>
>
>
> Is there some simple way to rename a field in all documents in my solr
> index?
>
>
>
> I am using a dynamic schema definition, and I’ve introduced some new
> copyField-instructions. Those make it necessary to reindex all documents.
> It would help me a great deal to be able to rename a specific field from:
>
>
>
> `i_itemNumber_l` to `i_itemNumber_cp_l`
>
>
>
> I don’t really mind to reindex all documents too, but that takes some time
> and having my (old) documents return NULL as value for the field
> `i_itemNumber_cp_l` is breaking a lot of stuff.
>
>
>
> So if there _*IS*_ a way to rename that field, that would help
> tremendously. Btw. I am using Solr 6.5.1 and I use SolrJ in my
> ApplicationLayer.
>
>
>
> Best regards and as always,
>
>
>
> Thank you so much for any input!
>
>
>
>
>
> Yours,
>
> Sebastian
>
>
>
> Mit freundlichen Grüßen
>
> Sebastian Riemer, BSc
>
>
>
>
>
> [image: logo_Littera_SC] 
> LITTERA Software & Consulting GmbH
>
> A-6060 Hall i.T., Haller Au 19a
>
> Telefon: +43(0) 50 765 000, Fax: +43(0) 50 765 118
>
> Sitz: Hall i.T., eingetragen beim Handelsgericht Innsbruck,
> Firmenbuch-Nr. FN 295807k, geschäftsführender Gesellschafter: Albert
> Unterkircher
>
>
>
> D-80637 München, Landshuter Allee 8-10
> Telefon: +49(0) 89 919 29 122, Fax: +49(0) 89 919 29 123
>
> Sitz: München, eingetragen beim Amtsgericht München
> unter HRB 103698, Geschäftsführer: Albert Unterkircher
>
> E-Mail: off...@littera.eu
> Homepage: www.littera.eu
>
>
>
> Diese Nachricht kann vertrauliche, nicht für die Veröffentlichung
> bestimmte und/oder rechtlich geschützte Informationen enthalten. Falls Sie
> nicht der beabsichtigte Empfänger sind, beachten Sie bitte, dass jegliche
> Veröffentlichung, Verbreitung oder Vervielfältigung dieser Nachricht
> strengstens untersagt ist. Sollten Sie diese Nachricht irrtümlich erhalten
> haben, informieren Sie bitte sofort den Absender durch Anruf oder
> Rücksendung der Nachricht und vernichten Sie diese.
>
> This communication may contain information that is legally privileged,
> confidential or exempt from disclosure.  If you are not the intended
> recipient, please note that any dissemination, distribution, or copying of
> this communication is strictly prohibited.  Anyone who receives this
> message in error should notify the sender immediately by telephone or by
> return e-mail and delete this communication entirely from his or her
> computer.
>
>
>

Re: Rename field in all documents from `i_itemNumber_l` to `i_itemNumber_cp_l`

[Erick Erickson]

If you’re reindexing anyway, I recommend you index to a new collection then use 
“collection aliasing” to point to the new one, that’s cleanest.

There’s no way to rename fields. Further, the meta-data will be carried in the 
index forever even if all docs have been reindexed into an existing collection. 
It’s a long story. For just a few fields this is totally transparent and not a 
problem, just FYI.

And from there, Alexandre’s comments will allow you to keep the application the 
same.

Best,
Erick

> On Sep 16, 2019, at 9:56 AM, Alexandre Rafalovitch  wrote:
> 
> I don't think you can rename it in the index.
> 
> However, you may be able to rename it during the query:
> https://lucene.apache.org/solr/guide/6_6/common-query-parameters.html#CommonQueryParameters-FieldNameAliases
> 
> Or, if you use eDisMax, during query rewriting:
> https://lucene.apache.org/solr/guide/6_6/the-extended-dismax-query-parser.html
> , see example at:
> https://github.com/arafalov/solr-indexing-book/blob/master/published/languages/conf/solrconfig.xml#L20-L21
> 
> These two may need to play together actually, if you want it to be fully
> transparent to the client code. See the #37 of the example above.
> 
> Regards,
>   Alex.
> 
> 
> On Mon, 16 Sep 2019 at 03:54, Sebastian Riemer  wrote:
> 
>> Dear mailing list,
>> 
>> 
>> 
>> I would like to know:
>> 
>> 
>> 
>> Is there some simple way to rename a field in all documents in my solr
>> index?
>> 
>> 
>> 
>> I am using a dynamic schema definition, and I’ve introduced some new
>> copyField-instructions. Those make it necessary to reindex all documents.
>> It would help me a great deal to be able to rename a specific field from:
>> 
>> 
>> 
>> `i_itemNumber_l` to `i_itemNumber_cp_l`
>> 
>> 
>> 
>> I don’t really mind to reindex all documents too, but that takes some time
>> and having my (old) documents return NULL as value for the field
>> `i_itemNumber_cp_l` is breaking a lot of stuff.
>> 
>> 
>> 
>> So if there _*IS*_ a way to rename that field, that would help
>> tremendously. Btw. I am using Solr 6.5.1 and I use SolrJ in my
>> ApplicationLayer.
>> 
>> 
>> 
>> Best regards and as always,
>> 
>> 
>> 
>> Thank you so much for any input!
>> 
>> 
>> 
>> 
>> 
>> Yours,
>> 
>> Sebastian
>> 
>> 
>> 
>> Mit freundlichen Grüßen
>> 
>> Sebastian Riemer, BSc
>> 
>> 
>> 
>> 
>> 
>> [image: logo_Littera_SC] 
>> LITTERA Software & Consulting GmbH
>> 
>> A-6060 Hall i.T., Haller Au 19a
>> 
>> Telefon: +43(0) 50 765 000, Fax: +43(0) 50 765 118
>> 
>> Sitz: Hall i.T., eingetragen beim Handelsgericht Innsbruck,
>> Firmenbuch-Nr. FN 295807k, geschäftsführender Gesellschafter: Albert
>> Unterkircher
>> 
>> 
>> 
>> D-80637 München, Landshuter Allee 8-10
>> Telefon: +49(0) 89 919 29 122, Fax: +49(0) 89 919 29 123
>> 
>> Sitz: München, eingetragen beim Amtsgericht München
>> unter HRB 103698, Geschäftsführer: Albert Unterkircher
>> 
>> E-Mail: off...@littera.eu
>> Homepage: www.littera.eu
>> 
>> 
>> 
>> Diese Nachricht kann vertrauliche, nicht für die Veröffentlichung
>> bestimmte und/oder rechtlich geschützte Informationen enthalten. Falls Sie
>> nicht der beabsichtigte Empfänger sind, beachten Sie bitte, dass jegliche
>> Veröffentlichung, Verbreitung oder Vervielfältigung dieser Nachricht
>> strengstens untersagt ist. Sollten Sie diese Nachricht irrtümlich erhalten
>> haben, informieren Sie bitte sofort den Absender durch Anruf oder
>> Rücksendung der Nachricht und vernichten Sie diese.
>> 
>> This communication may contain information that is legally privileged,
>> confidential or exempt from disclosure.  If you are not the intended
>> recipient, please note that any dissemination, distribution, or copying of
>> this communication is strictly prohibited.  Anyone who receives this
>> message in error should notify the sender immediately by telephone or by
>> return e-mail and delete this communication entirely from his or her
>> computer.

HDFS Shard Split

[Joe Obernberger]

Hi All - added a couple more solr nodes to an existing solr cloud 
cluster where the index is in HDFS.  When I try to a split a shard, I 
get an error saying there is not enough disk space.  It looks like it is 
looking on the local file system, and not in HDFS.


"Operation splitshard casued 
exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
not enough free disk space to perform index split on node


-Joe

Cannot index into solr 8.1.1

[Bhuvanesh]

Hi team,

Recently I created a cloud Solr 8.1.1 with zookeeper similar to cloud Solr
6.6.2 which is in use. All configurations and schema files are exactly
alike, but when I try to index the same documents Solr throws *cannot
change field "FIELD_NAME" from* *index options=DOCS_AND_FREQS_AND_POSITIONS
to inconsistent index options=DOCS* for a specific field which is of type
*string*. It is a required field so cannot be omitted.

For another Collection in the same core(Solr 8.1.1), Solr throws *cannot
change docValues type from SORTED_NUMERIC to SORTED for field
"ANOTHER_FIELD_NAME"* to the field of type *string.*

This is not existing solr upgrade, Solr 8.1.1 setup is completely new from
scratch and I am simply indexing the same data which we are using now with
solr 6.6.2

Both field type definitions are:






*Note:* It is indexing perfectly in the existing Solr i.e., 6.6.2


Kind regards,
Bhuvaneshwar Venkatraman

Re: Cannot index into solr 8.1.1

[Shawn Heisey]

On 9/16/2019 10:18 AM, Bhuvanesh wrote:

Recently I created a cloud Solr 8.1.1 with zookeeper similar to cloud Solr
6.6.2 which is in use. All configurations and schema files are exactly
alike, but when I try to index the same documents Solr throws *cannot
change field "FIELD_NAME" from* *index options=DOCS_AND_FREQS_AND_POSITIONS
to inconsistent index options=DOCS* for a specific field which is of type
*string*. It is a required field so cannot be omitted.

For another Collection in the same core(Solr 8.1.1), Solr throws *cannot
change docValues type from SORTED_NUMERIC to SORTED for field
"ANOTHER_FIELD_NAME"* to the field of type *string.*

This is not existing solr upgrade, Solr 8.1.1 setup is completely new from
scratch and I am simply indexing the same data which we are using now with
solr 6.6.2


Those errors indicate that there is an existing index that was built 
with a different schema, and the current index is not compatible with 
the schema you have now.


You're saying that you're indexing from scratch, but the error messages 
are indicating otherwise.


It's not possible to use an index from Solr 6 in Solr 8, and the errors 
would be entirely different if you tried.


This problem looks like you indexed some stuff in version 8, then 
changed the schema, and are trying to index more.  But your problem 
description seems to contradict this theory, so I'm not sure what to think.


The solution to these errors is to entirely delete all of the 
$CORE/data/index directories from each index core related to the 
collection, restart Solr or reload the collection, and reindex again 
from scratch.


Thanks,
Shawn

Re: Cannot index into solr 8.1.1

[Bhuvanesh]

Hi Shawn,

Thanks for your reply.

The core is used to test the solr setup by creating a trial collection. But
other than that every collection created are exactly the same as existing
one. I don't think this would create a problem, please brief me if it is
otherwise.

Thanks and regards,
Bhuvaneshwar Venkatraman

On Mon, Sep 16, 2019, 9:59 PM Shawn Heisey  wrote:

> On 9/16/2019 10:18 AM, Bhuvanesh wrote:
> > Recently I created a cloud Solr 8.1.1 with zookeeper similar to cloud
> Solr
> > 6.6.2 which is in use. All configurations and schema files are exactly
> > alike, but when I try to index the same documents Solr throws *cannot
> > change field "FIELD_NAME" from* *index
> options=DOCS_AND_FREQS_AND_POSITIONS
> > to inconsistent index options=DOCS* for a specific field which is of type
> > *string*. It is a required field so cannot be omitted.
> >
> > For another Collection in the same core(Solr 8.1.1), Solr throws *cannot
> > change docValues type from SORTED_NUMERIC to SORTED for field
> > "ANOTHER_FIELD_NAME"* to the field of type *string.*
> >
> > This is not existing solr upgrade, Solr 8.1.1 setup is completely new
> from
> > scratch and I am simply indexing the same data which we are using now
> with
> > solr 6.6.2
>
> Those errors indicate that there is an existing index that was built
> with a different schema, and the current index is not compatible with
> the schema you have now.
>
> You're saying that you're indexing from scratch, but the error messages
> are indicating otherwise.
>
> It's not possible to use an index from Solr 6 in Solr 8, and the errors
> would be entirely different if you tried.
>
> This problem looks like you indexed some stuff in version 8, then
> changed the schema, and are trying to index more.  But your problem
> description seems to contradict this theory, so I'm not sure what to think.
>
> The solution to these errors is to entirely delete all of the
> $CORE/data/index directories from each index core related to the
> collection, restart Solr or reload the collection, and reindex again
> from scratch.
>
> Thanks,
> Shawn
>

Re: Cannot index into solr 8.1.1

[Erick Erickson]

99.9% sure that if you look closely, you’ll find that these fields are 
inappropriately defined. What may have happened is that there are tighter 
checks in Solr 8 that throw errors where the contradictory definitions were 
silently ignored. For instance you report one error: 

SORTED_NUMERIC to SORTED for field "ANOTHER_FIELD_NAME" to the field of type 
string.

Any mention of SORTED_NUMERIC with a field type of string means something is 
very wrong with the definition. Usually, this is a function of changing the 
definition without starting with a new collection. So are you sure that when 
you create a collection to test you completely blow the old collection away?

And if this is using “schemaless” mode, it would mean that the type inferred 
for the first document with a particular field is incorrect, which is why 
there’s a warning printed out about disabling schemaless mode.

Best,
Erick



> On Sep 16, 2019, at 1:15 PM, Bhuvanesh  wrote:
> 
> Hi Shawn,
> 
> Thanks for your reply.
> 
> The core is used to test the solr setup by creating a trial collection. But
> other than that every collection created are exactly the same as existing
> one. I don't think this would create a problem, please brief me if it is
> otherwise.
> 
> Thanks and regards,
> Bhuvaneshwar Venkatraman
> 
> On Mon, Sep 16, 2019, 9:59 PM Shawn Heisey  wrote:
> 
>> On 9/16/2019 10:18 AM, Bhuvanesh wrote:
>>> Recently I created a cloud Solr 8.1.1 with zookeeper similar to cloud
>> Solr
>>> 6.6.2 which is in use. All configurations and schema files are exactly
>>> alike, but when I try to index the same documents Solr throws *cannot
>>> change field "FIELD_NAME" from* *index
>> options=DOCS_AND_FREQS_AND_POSITIONS
>>> to inconsistent index options=DOCS* for a specific field which is of type
>>> *string*. It is a required field so cannot be omitted.
>>> 
>>> For another Collection in the same core(Solr 8.1.1), Solr throws *cannot
>>> change docValues type from SORTED_NUMERIC to SORTED for field
>>> "ANOTHER_FIELD_NAME"* to the field of type *string.*
>>> 
>>> This is not existing solr upgrade, Solr 8.1.1 setup is completely new
>> from
>>> scratch and I am simply indexing the same data which we are using now
>> with
>>> solr 6.6.2
>> 
>> Those errors indicate that there is an existing index that was built
>> with a different schema, and the current index is not compatible with
>> the schema you have now.
>> 
>> You're saying that you're indexing from scratch, but the error messages
>> are indicating otherwise.
>> 
>> It's not possible to use an index from Solr 6 in Solr 8, and the errors
>> would be entirely different if you tried.
>> 
>> This problem looks like you indexed some stuff in version 8, then
>> changed the schema, and are trying to index more.  But your problem
>> description seems to contradict this theory, so I'm not sure what to think.
>> 
>> The solution to these errors is to entirely delete all of the
>> $CORE/data/index directories from each index core related to the
>> collection, restart Solr or reload the collection, and reindex again
>> from scratch.
>> 
>> Thanks,
>> Shawn
>> 

Re: upgrading from solr4 to solr8 searches taking 4 to 10 times as long to return

[Russell Bahr]

Hi Toke,
I just checked and the link is still active.  I am back from DC today and am 
going through and continuing to work on the issue.  Here is the link.  Any 
insights from you on this is appreciated.  I am going back through the previous 
suggestions and am in the process of trying them now.
Thanks,
Russ

> On Sep 8, 2019, at 10:42 AM, Toke Eskildsen  wrote:
> 
> Günter Hipler  wrote:
>> what about this
>> https://issues.apache.org/jira/browse/SOLR-8096
>> seems still unresolved issue?
> 
> Unfortunately Russell has de-shared the solrconfig.xml, but as far as I 
> remember it does not trigger faceting.
> 
>> With our migration from version 4 to 7 last year we experienced similar
>> problems.
> 
> The iterator-based DocValues implementation in Solr 7 has a performance issue 
> with large segments, with symptoms akin to SOLR-8096. If you have not already 
> solved your problems, Solr 8 (with an upgraded index) might help.
> 
> - Toke Eskildsen

Why I receive permission denied when running as root

[Raymond Xie]

[root@pocnnr1n1 solr-8.2.0]# ll
total 88
-rw-r--r--  1 root root  4023 Jul 19 09:09 README.md
-rw-r--r--  1 root root 32153 Jul 19 09:09 build.xml
-rw-r--r--  1 root root 27717 Jul 19 09:09 NOTICE.txt
-rw-r--r--  1 root root 12646 Jul 19 09:09 LICENSE.txt
drwxr-xr-x 10 root root   174 Sep 16 21:13 dev-tools
drwxr-xr-x 30 root root  4096 Sep 16 21:13 lucene
drwxr-xr-x 16 root root  4096 Sep 16 21:13 solr

[root@pocnnr1n1 solr]# bin/solr start
-bash: bin/solr: Permission denied

Can anyone please help me to sort it out?

Thank you. Regards.
**
*Sincerely yours,*


*Raymond*

Re: Why I receive permission denied when running as root

[Paras Lehana]

Hi Raymond,

It's not recommended to run solr as root (security reasons
).
Nevertheless, in order to answer your question, try this command:

*sudo bin/solr start -force*


>From Solr Control Script Reference

:

If attempting to start Solr as the root user, the script will exit with a
> warning that running Solr as "root" can cause problems. It is possible to
> override this warning with the -force parameter.


PS: I suggest you to go through *Service Installation Script *in Taking
Solr to Production
 that
describes the ideal Solr setup. A must read!

Hope I helped.


On Tue, 17 Sep 2019 at 08:37, Raymond Xie  wrote:

> [root@pocnnr1n1 solr-8.2.0]# ll
> total 88
> -rw-r--r--  1 root root  4023 Jul 19 09:09 README.md
> -rw-r--r--  1 root root 32153 Jul 19 09:09 build.xml
> -rw-r--r--  1 root root 27717 Jul 19 09:09 NOTICE.txt
> -rw-r--r--  1 root root 12646 Jul 19 09:09 LICENSE.txt
> drwxr-xr-x 10 root root   174 Sep 16 21:13 dev-tools
> drwxr-xr-x 30 root root  4096 Sep 16 21:13 lucene
> drwxr-xr-x 16 root root  4096 Sep 16 21:13 solr
>
> [root@pocnnr1n1 solr]# bin/solr start
> -bash: bin/solr: Permission denied
>
> Can anyone please help me to sort it out?
>
> Thank you. Regards.
> **
> *Sincerely yours,*
>
>
> *Raymond*
>


-- 
-- 
Regards,

*Paras Lehana* [65871]
Software Programmer, Auto-Suggest,
IndiaMART Intermesh Ltd.

8th Floor, Tower A, Advant-Navis Business Park, Sector 142,
Noida, UP, IN - 201303

Mob.: +91-9560911996
Work: 01203916600 | Extn:  *8173*

-- 
IMPORTANT: 
NEVER share your IndiaMART OTP/ Password with anyone.