from:"Devansh Dhutia \(JIRA\)"

[jira] [Commented] (SOLR-8160) Terms query parser ignores query analysis

2015-10-13 Thread Devansh Dhutia (JIRA)


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

Devansh Dhutia commented on SOLR-8160:
--

Fair enough. I was under the impression all parsers were to obey query time 
analysis out of the box. My apologies for the misunderstanding. 

Is it reasonable to convert this to an enhancement request? 

> Terms query parser ignores query analysis 
> --
>
> Key: SOLR-8160
> URL: https://issues.apache.org/jira/browse/SOLR-8160
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers, search
>Affects Versions: 5.3
>Reporter: Devansh Dhutia
>
> Field setup as
> {code}
>  multiValued="false" required="false" />
>
>   
>  
>  
>   
>   
>  
>  
>   
>
> {code}
> Value sent to cs field for indexing include: AA, BB
> Following is observed
> {code}={!terms f=cs}AA,BB{code} yields 0 results
> {code}={!terms f=cs}aa,bb{code} yields 2 results
> {code}=cs:(AA BB){code} yields 2 results
> {code}=cs:(aa bb){code} yields 2 results
> The first variant above should behave like the other 3 & obey query time 
> analysis



--
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-8160) Terms query parser ignores query analysis

2015-10-12 Thread Devansh Dhutia (JIRA)


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

Devansh Dhutia updated SOLR-8160:
-
Description: 
Field setup as
{code}

   
  
 
 
  
  
 
 
  
   
{code}

Value sent to cs field for indexing include: AA, BB

Following is observed
# {code}{!terms f=cs}AA,BB{code} yields 0 results
# {code}{!terms f=cs}aa,bb{code} yields 2 results
# {code}=cs:(AA BB){code} yields 2 results
# {code}=cs:(aa bb){code} yields 2 results

1 above should behave like the other parsers & obey query time analysis

  was:
Field setup as
{code}

   
  
 
 
  
  
 
 
  
   
{code}

Value sent to cs field for indexing include: AA, BB, CC

Following is observed
# {code}{!terms f=cs}AA,BB{code} yields 0 results
# {code}{!terms f=cs}aa,bb{code} yields 2 results
# {code}=cs:(AA BB){code} yields 2 results
# {code}=cs:(aa bb){code} yields 2 results

1 above should behave like the other parsers & obey query time analysis


> Terms query parser ignores query analysis 
> --
>
> Key: SOLR-8160
> URL: https://issues.apache.org/jira/browse/SOLR-8160
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers, search
>Affects Versions: 5.3
>Reporter: Devansh Dhutia
>
> Field setup as
> {code}
>  multiValued="false" required="false" />
>
>   
>  
>  
>   
>   
>  
>  
>   
>
> {code}
> Value sent to cs field for indexing include: AA, BB
> Following is observed
> # {code}{!terms f=cs}AA,BB{code} yields 0 results
> # {code}{!terms f=cs}aa,bb{code} yields 2 results
> # {code}=cs:(AA BB){code} yields 2 results
> # {code}=cs:(aa bb){code} yields 2 results
> 1 above should behave like the other parsers & obey query time analysis



--
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-8160) Terms query parser ignores query analysis

2015-10-12 Thread Devansh Dhutia (JIRA)

Devansh Dhutia created SOLR-8160:


 Summary: Terms query parser ignores query analysis 
 Key: SOLR-8160
 URL: https://issues.apache.org/jira/browse/SOLR-8160
 Project: Solr
  Issue Type: Bug
  Components: query parsers, search
Affects Versions: 5.3
Reporter: Devansh Dhutia


Field setup as
{code}

   
  
 
 
  
  
 
 
  
   
{code}

Value sent to cs field for indexing include: AA, BB, CC

Following is observed
# {code}{!terms f=cs}AA,BB{code} yields 0 results
# {code}{!terms f=cs}aa,bb{code} yields 2 results
# {code}=cs:(AA BB){code} yields 2 results
# {code}=cs:(aa bb){code} yields 2 results

1 above should behave like the other parsers & obey query time analysis



--
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-8160) Terms query parser ignores query analysis

2015-10-12 Thread Devansh Dhutia (JIRA)


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

Devansh Dhutia updated SOLR-8160:
-
Description: 
Field setup as
{code}

   
  
 
 
  
  
 
 
  
   
{code}

Value sent to cs field for indexing include: AA, BB

Following is observed
{code}={!terms f=cs}AA,BB{code} yields 0 results
{code}={!terms f=cs}aa,bb{code} yields 2 results
{code}=cs:(AA BB){code} yields 2 results
{code}=cs:(aa bb){code} yields 2 results

The first variant above should behave like the other 3 & obey query time 
analysis

  was:
Field setup as
{code}

   
  
 
 
  
  
 
 
  
   
{code}

Value sent to cs field for indexing include: AA, BB

Following is observed
# {code}{!terms f=cs}AA,BB{code} yields 0 results
# {code}{!terms f=cs}aa,bb{code} yields 2 results
# {code}=cs:(AA BB){code} yields 2 results
# {code}=cs:(aa bb){code} yields 2 results

1 above should behave like the other parsers & obey query time analysis


> Terms query parser ignores query analysis 
> --
>
> Key: SOLR-8160
> URL: https://issues.apache.org/jira/browse/SOLR-8160
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers, search
>Affects Versions: 5.3
>Reporter: Devansh Dhutia
>
> Field setup as
> {code}
>  multiValued="false" required="false" />
>
>   
>  
>  
>   
>   
>  
>  
>   
>
> {code}
> Value sent to cs field for indexing include: AA, BB
> Following is observed
> {code}={!terms f=cs}AA,BB{code} yields 0 results
> {code}={!terms f=cs}aa,bb{code} yields 2 results
> {code}=cs:(AA BB){code} yields 2 results
> {code}=cs:(aa bb){code} yields 2 results
> The first variant above should behave like the other 3 & obey query time 
> analysis



--
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-5850) Race condition in ConcurrentUpdateSolrServer

2014-03-12 Thread Devansh Dhutia (JIRA)


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

Devansh Dhutia commented on SOLR-5850:
--

{code:java title=ConcurrentUpdateSolrServer.java}
SolrParams currentParams = new ModifiableSolrParams(req.getParams());
if (!origParams.toNamedList().equals(currentParams.toNamedList())) {
queue.add(req); // params are different, push back to queue
break;
}
{code}

Shouldn't that be a blocking operation? or even an offer with retry logic? 
further down, the queue is polled, and by the time the params are compared, 
another request may have already been added to the queue. 

 Race condition in ConcurrentUpdateSolrServer
 

 Key: SOLR-5850
 URL: https://issues.apache.org/jira/browse/SOLR-5850
 Project: Solr
  Issue Type: Bug
  Components: clients - java, search, SolrCloud, update
Affects Versions: 4.6
Reporter: Devansh Dhutia
Priority: Critical
  Labels: 500, cloud, error, update

 Possibly related to SOLR-2308, we are seeing a Queue Full error message when 
 issuing writes to Solr Cloud
 Each Update has 200 documents, and a commit is issued after 2000 documents 
 have been added. 
 The writes are spread out to all the servers in the cloud (2 in this case) 
 and following is the stack trace from Solr: 
 {code:xml}
 ?xml version=1.0 encoding=UTF-8?
 response
 lst name=responseHeaderint name=status500/intint 
 name=QTime101/int/lstlst name=errorstr name=msgQueue 
 full/strstr name=t
 racejava.lang.IllegalStateException: Queue full
 at java.util.AbstractQueue.add(Unknown Source)
 at 
 org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner$1.writeTo(ConcurrentUpdateSolrServer.java:181)
 at 
 org.apache.http.entity.EntityTemplate.writeTo(EntityTemplate.java:72)
 at 
 org.apache.http.entity.HttpEntityWrapper.writeTo(HttpEntityWrapper.java:98)
 at 
 org.apache.http.impl.client.EntityEnclosingRequestWrapper$EntityWrapper.writeTo(EntityEnclosingRequestWrapper.java:108)
 at 
 org.apache.http.impl.entity.EntitySerializer.serialize(EntitySerializer.java:122)
 at 
 org.apache.http.impl.AbstractHttpClientConnection.sendRequestEntity(AbstractHttpClientConnection.java:271)
 at 
 org.apache.http.impl.conn.ManagedClientConnectionImpl.sendRequestEntity(ManagedClientConnectionImpl.java:197)
 at 
 org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:257)
 at 
 org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
 at 
 org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
 at 
 org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
 at 
 org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
 at 
 org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
 at 
 org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
 at 
 org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:232)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)
 /strint name=code500/int/lst
 /response
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (SOLR-5850) Race condition in ConcurrentUpdateSolrServer

2014-03-11 Thread Devansh Dhutia (JIRA)

Devansh Dhutia created SOLR-5850:


 Summary: Race condition in ConcurrentUpdateSolrServer
 Key: SOLR-5850
 URL: https://issues.apache.org/jira/browse/SOLR-5850
 Project: Solr
  Issue Type: Bug
  Components: search, SolrCloud, update
Affects Versions: 4.6
Reporter: Devansh Dhutia
Priority: Critical


Possibly related to SOLR-2308, we are seeing a Queue Full error message when 
issuing thousands of writes to the Solr Cloud. 

Each Update has 200 documents, and a commit is issued after 2000 documents have 
been added. 

The writes are spread out to all the servers in the cloud (2 in this case) and 
following is the stack trace from Solr: 

{code:xml}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status500/intint 
name=QTime101/int/lstlst name=errorstr name=msgQueue 
full/strstr name=t
racejava.lang.IllegalStateException: Queue full
at java.util.AbstractQueue.add(Unknown Source)
at 
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner$1.writeTo(ConcurrentUpdateSolrServer.java:181)
at org.apache.http.entity.EntityTemplate.writeTo(EntityTemplate.java:72)
at 
org.apache.http.entity.HttpEntityWrapper.writeTo(HttpEntityWrapper.java:98)
at 
org.apache.http.impl.client.EntityEnclosingRequestWrapper$EntityWrapper.writeTo(EntityEnclosingRequestWrapper.java:108)
at 
org.apache.http.impl.entity.EntitySerializer.serialize(EntitySerializer.java:122)
at 
org.apache.http.impl.AbstractHttpClientConnection.sendRequestEntity(AbstractHttpClientConnection.java:271)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.sendRequestEntity(ManagedClientConnectionImpl.java:197)
at 
org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:257)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
at 
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:232)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
/strint name=code500/int/lst
/response
{code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (SOLR-5850) Race condition in ConcurrentUpdateSolrServer

2014-03-11 Thread Devansh Dhutia (JIRA)


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

Devansh Dhutia updated SOLR-5850:
-

Component/s: clients - java

 Race condition in ConcurrentUpdateSolrServer
 

 Key: SOLR-5850
 URL: https://issues.apache.org/jira/browse/SOLR-5850
 Project: Solr
  Issue Type: Bug
  Components: clients - java, search, SolrCloud, update
Affects Versions: 4.6
Reporter: Devansh Dhutia
Priority: Critical
  Labels: 500, cloud, error, update

 Possibly related to SOLR-2308, we are seeing a Queue Full error message when 
 issuing thousands of writes to the Solr Cloud. 
 Each Update has 200 documents, and a commit is issued after 2000 documents 
 have been added. 
 The writes are spread out to all the servers in the cloud (2 in this case) 
 and following is the stack trace from Solr: 
 {code:xml}
 ?xml version=1.0 encoding=UTF-8?
 response
 lst name=responseHeaderint name=status500/intint 
 name=QTime101/int/lstlst name=errorstr name=msgQueue 
 full/strstr name=t
 racejava.lang.IllegalStateException: Queue full
 at java.util.AbstractQueue.add(Unknown Source)
 at 
 org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner$1.writeTo(ConcurrentUpdateSolrServer.java:181)
 at 
 org.apache.http.entity.EntityTemplate.writeTo(EntityTemplate.java:72)
 at 
 org.apache.http.entity.HttpEntityWrapper.writeTo(HttpEntityWrapper.java:98)
 at 
 org.apache.http.impl.client.EntityEnclosingRequestWrapper$EntityWrapper.writeTo(EntityEnclosingRequestWrapper.java:108)
 at 
 org.apache.http.impl.entity.EntitySerializer.serialize(EntitySerializer.java:122)
 at 
 org.apache.http.impl.AbstractHttpClientConnection.sendRequestEntity(AbstractHttpClientConnection.java:271)
 at 
 org.apache.http.impl.conn.ManagedClientConnectionImpl.sendRequestEntity(ManagedClientConnectionImpl.java:197)
 at 
 org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:257)
 at 
 org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
 at 
 org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
 at 
 org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
 at 
 org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
 at 
 org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
 at 
 org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
 at 
 org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:232)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)
 /strint name=code500/int/lst
 /response
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (SOLR-5850) Race condition in ConcurrentUpdateSolrServer

2014-03-11 Thread Devansh Dhutia (JIRA)


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

Devansh Dhutia updated SOLR-5850:
-

Description: 
Possibly related to SOLR-2308, we are seeing a Queue Full error message when 
issuing writes to Solr Cloud

Each Update has 200 documents, and a commit is issued after 2000 documents have 
been added. 

The writes are spread out to all the servers in the cloud (2 in this case) and 
following is the stack trace from Solr: 

{code:xml}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status500/intint 
name=QTime101/int/lstlst name=errorstr name=msgQueue 
full/strstr name=t
racejava.lang.IllegalStateException: Queue full
at java.util.AbstractQueue.add(Unknown Source)
at 
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner$1.writeTo(ConcurrentUpdateSolrServer.java:181)
at org.apache.http.entity.EntityTemplate.writeTo(EntityTemplate.java:72)
at 
org.apache.http.entity.HttpEntityWrapper.writeTo(HttpEntityWrapper.java:98)
at 
org.apache.http.impl.client.EntityEnclosingRequestWrapper$EntityWrapper.writeTo(EntityEnclosingRequestWrapper.java:108)
at 
org.apache.http.impl.entity.EntitySerializer.serialize(EntitySerializer.java:122)
at 
org.apache.http.impl.AbstractHttpClientConnection.sendRequestEntity(AbstractHttpClientConnection.java:271)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.sendRequestEntity(ManagedClientConnectionImpl.java:197)
at 
org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:257)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
at 
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:232)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
/strint name=code500/int/lst
/response
{code}

  was:
Possibly related to SOLR-2308, we are seeing a Queue Full error message when 
issuing thousands of writes to the Solr Cloud. 

Each Update has 200 documents, and a commit is issued after 2000 documents have 
been added. 

The writes are spread out to all the servers in the cloud (2 in this case) and 
following is the stack trace from Solr: 

{code:xml}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status500/intint 
name=QTime101/int/lstlst name=errorstr name=msgQueue 
full/strstr name=t
racejava.lang.IllegalStateException: Queue full
at java.util.AbstractQueue.add(Unknown Source)
at 
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner$1.writeTo(ConcurrentUpdateSolrServer.java:181)
at org.apache.http.entity.EntityTemplate.writeTo(EntityTemplate.java:72)
at 
org.apache.http.entity.HttpEntityWrapper.writeTo(HttpEntityWrapper.java:98)
at 
org.apache.http.impl.client.EntityEnclosingRequestWrapper$EntityWrapper.writeTo(EntityEnclosingRequestWrapper.java:108)
at 
org.apache.http.impl.entity.EntitySerializer.serialize(EntitySerializer.java:122)
at 
org.apache.http.impl.AbstractHttpClientConnection.sendRequestEntity(AbstractHttpClientConnection.java:271)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.sendRequestEntity(ManagedClientConnectionImpl.java:197)
at 
org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:257)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
at 
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:232)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at

[jira] [Updated] (SOLR-5717) group.field returns no groups for trie fields with non zero precisionstep

2014-02-14 Thread Devansh Dhutia (JIRA)


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

Devansh Dhutia updated SOLR-5717:
-

Labels: cloud field grouping  (was: )

 group.field returns no groups for trie fields with non zero precisionstep
 -

 Key: SOLR-5717
 URL: https://issues.apache.org/jira/browse/SOLR-5717
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.6
Reporter: Devansh Dhutia
  Labels: cloud, field, grouping

 I have an statusid field in my schema setup as 
 {code}
 field name=statusid type=tint indexed=true stored=true 
 required=true/
 fieldType name=int class=solr.TrieIntField precisionStep=0 
 positionIncrementGap=0/
 {code}
 I am running a multi shard cloud, and when issuing a query such as the 
 following: 
 {quote}
 /?q=*:*group.field=statusidgroup=true
 {quote}
 I get a response such as 
 {code}
 grouped: {
 statusid: {
   matches: 376601,
   groups: [
 {
   groupValue: 0,
   doclist: {
 numFound: 0,
 start: 0,
 docs: []
   }
 },
 {
   groupValue: 0,
   doclist: {
 numFound: 0,
 start: 0,
 docs: []
   }
 }
   ]
 }
   }
 {code}
 I know there are many results with non zero status ids in the index (verified 
 by faceting on the statusid field
 {code}
 facet_fields: {
   statusid: [
 0,
 177460,
 1,
 163303,
 9,
 34291,
 7,
 804,
 2,
 587,
 8,
 83,
 6,
 73
   ]
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-5717) group.field returns no groups for trie fields with non zero precisionstep

2014-02-14 Thread Devansh Dhutia (JIRA)


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

Devansh Dhutia updated SOLR-5717:
-

Description: 
I have an statusid field in my schema setup as 
{code}
field name=statusid type=tint indexed=true stored=true 
required=true/

fieldType name=tint class=solr.TrieIntField precisionStep=4 
positionIncrementGap=0/

{code}

I am running a multi shard cloud, and when issuing a query such as the 
following: 
{quote}
/?q=*:*group.field=statusidgroup=true
{quote}
I get a response such as 
{code}
grouped: {
statusid: {
  matches: 376601,
  groups: [
{
  groupValue: 0,
  doclist: {
numFound: 0,
start: 0,
docs: []
  }
},
{
  groupValue: 0,
  doclist: {
numFound: 0,
start: 0,
docs: []
  }
}
  ]
}
  }
{code}

I know there are many results with non zero status ids in the index (verified 
by faceting on the statusid field

{code}
facet_fields: {
  statusid: [
0,
177460,
1,
163303,
9,
34291,
7,
804,
2,
587,
8,
83,
6,
73
  ]
}
{code}

  was:
I have an statusid field in my schema setup as 
{code}
field name=statusid type=tint indexed=true stored=true 
required=true/

fieldType name=int class=solr.TrieIntField precisionStep=0 
positionIncrementGap=0/

{code}

I am running a multi shard cloud, and when issuing a query such as the 
following: 
{quote}
/?q=*:*group.field=statusidgroup=true
{quote}
I get a response such as 
{code}
grouped: {
statusid: {
  matches: 376601,
  groups: [
{
  groupValue: 0,
  doclist: {
numFound: 0,
start: 0,
docs: []
  }
},
{
  groupValue: 0,
  doclist: {
numFound: 0,
start: 0,
docs: []
  }
}
  ]
}
  }
{code}

I know there are many results with non zero status ids in the index (verified 
by faceting on the statusid field

{code}
facet_fields: {
  statusid: [
0,
177460,
1,
163303,
9,
34291,
7,
804,
2,
587,
8,
83,
6,
73
  ]
}
{code}


 group.field returns no groups for trie fields with non zero precisionstep
 -

 Key: SOLR-5717
 URL: https://issues.apache.org/jira/browse/SOLR-5717
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.6
Reporter: Devansh Dhutia
  Labels: cloud, field, grouping

 I have an statusid field in my schema setup as 
 {code}
 field name=statusid type=tint indexed=true stored=true 
 required=true/
 fieldType name=tint class=solr.TrieIntField precisionStep=4 
 positionIncrementGap=0/
 {code}
 I am running a multi shard cloud, and when issuing a query such as the 
 following: 
 {quote}
 /?q=*:*group.field=statusidgroup=true
 {quote}
 I get a response such as 
 {code}
 grouped: {
 statusid: {
   matches: 376601,
   groups: [
 {
   groupValue: 0,
   doclist: {
 numFound: 0,
 start: 0,
 docs: []
   }
 },
 {
   groupValue: 0,
   doclist: {
 numFound: 0,
 start: 0,
 docs: []
   }
 }
   ]
 }
   }
 {code}
 I know there are many results with non zero status ids in the index (verified 
 by faceting on the statusid field
 {code}
 facet_fields: {
   statusid: [
 0,
 177460,
 1,
 163303,
 9,
 34291,
 7,
 804,
 2,
 587,
 8,
 83,
 6,
 73
   ]
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5717) group.field returns no groups for trie fields with non zero precisionstep

2014-02-12 Thread Devansh Dhutia (JIRA)


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

Devansh Dhutia commented on SOLR-5717:
--

This may be related: 
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201304.mbox/%3c51643fa3.2050...@kelkoo.fr%3E

 group.field returns no groups for trie fields with non zero precisionstep
 -

 Key: SOLR-5717
 URL: https://issues.apache.org/jira/browse/SOLR-5717
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.6
Reporter: Devansh Dhutia

 I have an statusid field in my schema setup as 
 {code}
 field name=statusid type=tint indexed=true stored=true 
 required=true/
 fieldType name=int class=solr.TrieIntField precisionStep=0 
 positionIncrementGap=0/
 {code}
 I am running a multi shard cloud, and when issuing a query such as the 
 following: 
 {quote}
 /?q=*:*group.field=statusidgroup=true
 {quote}
 I get a response such as 
 {code}
 grouped: {
 statusid: {
   matches: 376601,
   groups: [
 {
   groupValue: 0,
   doclist: {
 numFound: 0,
 start: 0,
 docs: []
   }
 },
 {
   groupValue: 0,
   doclist: {
 numFound: 0,
 start: 0,
 docs: []
   }
 }
   ]
 }
   }
 {code}
 I know there are many results with non zero status ids in the index (verified 
 by faceting on the statusid field
 {code}
 facet_fields: {
   statusid: [
 0,
 177460,
 1,
 163303,
 9,
 34291,
 7,
 804,
 2,
 587,
 8,
 83,
 6,
 73
   ]
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (SOLR-5717) group.field returns no groups for trie fields with non zero precisionstep

2014-02-12 Thread Devansh Dhutia (JIRA)

Devansh Dhutia created SOLR-5717:


 Summary: group.field returns no groups for trie fields with non 
zero precisionstep
 Key: SOLR-5717
 URL: https://issues.apache.org/jira/browse/SOLR-5717
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.6
Reporter: Devansh Dhutia


I have an statusid field in my schema setup as 
{code}
field name=statusid type=tint indexed=true stored=true 
required=true/

fieldType name=int class=solr.TrieIntField precisionStep=0 
positionIncrementGap=0/

{code}

I am running a multi shard cloud, and when issuing a query such as the 
following: 
{quote}
/?q=*:*group.field=statusidgroup=true
{quote}
I get a response such as 
{code}
grouped: {
statusid: {
  matches: 376601,
  groups: [
{
  groupValue: 0,
  doclist: {
numFound: 0,
start: 0,
docs: []
  }
},
{
  groupValue: 0,
  doclist: {
numFound: 0,
start: 0,
docs: []
  }
}
  ]
}
  }
{code}

I know there are many results with non zero status ids in the index (verified 
by faceting on the statusid field

{code}
facet_fields: {
  statusid: [
0,
177460,
1,
163303,
9,
34291,
7,
804,
2,
587,
8,
83,
6,
73
  ]
}
{code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-8160) Terms query parser ignores query analysis

[jira] [Updated] (SOLR-8160) Terms query parser ignores query analysis

[jira] [Created] (SOLR-8160) Terms query parser ignores query analysis

[jira] [Updated] (SOLR-8160) Terms query parser ignores query analysis

[jira] [Commented] (SOLR-5850) Race condition in ConcurrentUpdateSolrServer

[jira] [Created] (SOLR-5850) Race condition in ConcurrentUpdateSolrServer

[jira] [Updated] (SOLR-5850) Race condition in ConcurrentUpdateSolrServer

[jira] [Updated] (SOLR-5850) Race condition in ConcurrentUpdateSolrServer

[jira] [Updated] (SOLR-5717) group.field returns no groups for trie fields with non zero precisionstep

[jira] [Updated] (SOLR-5717) group.field returns no groups for trie fields with non zero precisionstep

[jira] [Commented] (SOLR-5717) group.field returns no groups for trie fields with non zero precisionstep

[jira] [Created] (SOLR-5717) group.field returns no groups for trie fields with non zero precisionstep

12 matches

Site Navigation

Mail list logo

Footer information