date:20140123

[jira] [Commented] (SOLR-5514) atomic update throws exception if the schema contains uuid fields: Invalid UUID String: 'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'

2014-01-23 Thread Arun Kumar (JIRA)


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

Arun Kumar commented on SOLR-5514:
--

Hi Dirk, Is this still an issue? I am not able to reproduce. Can you please 
confirm?

 atomic update throws exception if the schema contains uuid fields: Invalid 
 UUID String: 'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'
 -

 Key: SOLR-5514
 URL: https://issues.apache.org/jira/browse/SOLR-5514
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5.1
 Environment: unix and windows
Reporter: Dirk Reuss 
Assignee: Shalin Shekhar Mangar

 I am updating an exiting document with the statement 
 adddocfield name='name' update='set'newvalue/field
 All fields are stored and I have several UUID fields. About 10-20% of the 
 update commands will fail with the message: (example)
 Invalid UUID String: 'java.util.UUID:532c9353-d391-4a04-8618-dc2fa1ef8b35'
 the point is that java.util.UUID seems to be prepended to the original uuid 
 stored in the field and when the value is written this error occours.
 I tried to check if this specific uuid field was the problem and
 added the uuid field in the update xml with(field name='id1' 
 update='set'...). But the error simply moved to an other uuid field.
 here is the original exception:
 lst name=responseHeaderint name=status500/intint 
 name=QTime34/int/lstlst name=errorstr name=msgError while 
 creating field 
 'MyUUIDField{type=uuid,properties=indexed,stored,omitTermFreqAndPositions,required,
  required=true}' from value 
 'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'/strstr 
 name=traceorg.apache.solr.common.SolrException: Error while creating field 
 'MyUUIDField{type=uuid,properties=indexed,stored,omitTermFreqAndPositions,required,
  required=true}' from value 
 'java.util.UUID:e26c4d56-e98d-41de-9b7f-f63192089670'
   at org.apache.solr.schema.FieldType.createField(FieldType.java:259)
   at org.apache.solr.schema.StrField.createFields(StrField.java:56)
   at 
 org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:47)
   at 
 org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:118)
   at 
 org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:77)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:215)
   at 
 org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
   at 
 org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:556)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:692)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:435)
   at 
 org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
   at 
 org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
   at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
   at 
 org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
   at 
 org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
   at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
   at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
   at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
   at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
   at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
   at

[jira] [Updated] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks

2014-01-23 Thread Anshum Gupta (JIRA)

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

Anshum Gupta updated SOLR-5477:
---

Attachment: SOLR-5477.patch

Still a lot of stuff to be added/fixed but here's another patch so that if
someone is interested, he/she could get some idea on the direction in which I'm
moving.

Here's what's been fixed/changed in this patch:
* Standardized the request parameters for CoreAdmin and Collection level
request status. Parameters now are : action=REQUESTSTATUSrequestid=XX
* Added async option for all other calls (not just splitshard and
createcollection).
* Fixed the encoding related stuff and the potential NPEs where ever I could
spot those.
* Removed unused code and cleaned up some debugging stuff.
* Used a ThreadPool in case of coreadmin in a rather raw manner i.e. static
(and without the mode check etc). Have added todo's to add those checks and to
also call shutdown for the threadpool.
* Changed names of the queues to the ones suggested by Shalin.
* Items are no longer being put in the completed queue in Overseer.
* Ran ant check-forbidden-apis to fix reported issues.

Here's what still lies with me incomplete/not-working:
* Make shard requests async (pass the param to coreadmin requests and poll for
completion/failure) from the OverseerCollectionProcessor.
* Have a threadpool for OverseerCollectionProcessor so that the long running
tasks don't block everything else.
* Improve current tests and add more tests.

Async execution of OverseerCollectionProcessor tasks

Key: SOLR-5477
URL: https://issues.apache.org/jira/browse/SOLR-5477
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Anshum Gupta
Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch

Typical collection admin commands are long running and it is very common to
have the requests get timed out. It is more of a problem if the cluster is
very large.Add an option to run these commands asynchronously
add an extra param async=true for all collection commands
the task is written to ZK and the caller is returned a task id.
as separate collection admin command will be added to poll the status of the
task
command=statusid=7657668909
if id is not passed all running async tasks should be listed
A separate queue is created to store in-process tasks . After the tasks are
completed the queue entry is removed. OverSeerColectionProcessor will perform
these tasks in multiple threads

--
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-5658) commitWithin does not reflect the new documents added

2014-01-23 Thread Varun Thacker (JIRA)

Varun Thacker created SOLR-5658:
---

 Summary: commitWithin does not reflect the new documents added
 Key: SOLR-5658
 URL: https://issues.apache.org/jira/browse/SOLR-5658
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.6, 5.0
Reporter: Varun Thacker


I start 4 nodes using the setup mentioned on - 
https://cwiki.apache.org/confluence/display/solr/Getting+Started+with+SolrCloud
 
I added a document using - 
curl http://localhost:8983/solr/update?commitWithin=1 -H Content-Type: 
text/xml --data-binary 'adddocfield name=idtestdoc/field/doc/add'

In Solr 4.5.1 there is 1 soft commit with openSearcher=true and 1 hard commit 
with openSearcher=false
In Solr 4.6.x there is there is only one commit hard commit with 
openSearcher=false
 
So even after 10 seconds queries on none of the shards reflect the added 
document. 

This was also reported on the solr-user list ( 
http://lucene.472066.n3.nabble.com/Possible-regression-for-Solr-4-6-0-commitWithin-does-not-work-with-replicas-td4106102.html
 )

Here are the relevant logs 

Logs from Solr 4.5.1
Node 1:
420021 [qtp619011445-12] INFO  
org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
webapp=/solr path=/update params={commitWithin=1} {add=[testdoc]} 0 45
 
Node 2:
119896 [qtp1608701025-10] INFO  
org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
webapp=/solr path=/update 
params={distrib.from=http://192.168.1.103:8983/solr/collection1/update.distrib=TOLEADERwt=javabinversion=2}
 {add=[testdoc (1458003295513608192)]} 0 348
129648 [commitScheduler-8-thread-1] INFO  org.apache.solr.update.UpdateHandler  
– start 
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
129679 [commitScheduler-8-thread-1] INFO  
org.apache.solr.search.SolrIndexSearcher  – Opening Searcher@e174f70 main
129680 [commitScheduler-8-thread-1] INFO  org.apache.solr.update.UpdateHandler  
– end_commit_flush
129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
QuerySenderListener sending requests to Searcher@e174f70 
main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
QuerySenderListener done.
129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
[collection1] Registered new searcher Searcher@e174f70 
main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
134648 [commitScheduler-7-thread-1] INFO  org.apache.solr.update.UpdateHandler  
– start 
commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
134658 [commitScheduler-7-thread-1] INFO  org.apache.solr.core.SolrCore  – 
SolrDeletionPolicy.onCommit: commits: num=2

commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3; 
maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_3,generation=3}

commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3; 
maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_4,generation=4}
134658 [commitScheduler-7-thread-1] INFO  org.apache.solr.core.SolrCore  – 
newest commit generation = 4
134660 [commitScheduler-7-thread-1] INFO  org.apache.solr.update.UpdateHandler  
– end_commit_flush
 
 
Node 3:
 
Node 4:
374545 [qtp1608701025-16] INFO  
org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
webapp=/solr path=/update 
params={distrib.from=http://192.168.1.103:7574/solr/collection1/update.distrib=FROMLEADERwt=javabinversion=2}
 {add=[testdoc (1458002133233172480)]} 0 20
384545 [commitScheduler-8-thread-1] INFO  org.apache.solr.update.UpdateHandler  
– start 
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
384552 [commitScheduler-8-thread-1] INFO  
org.apache.solr.search.SolrIndexSearcher  – Opening Searcher@36137e08 main
384553 [commitScheduler-8-thread-1] INFO  org.apache.solr.update.UpdateHandler  
– end_commit_flush
384553 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
QuerySenderListener sending requests to Searcher@36137e08 
main{StandardDirectoryReader(segments_2:7:nrt _1(4.5.1):C1)}
384553 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
QuerySenderListener done.
384554 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
[collection1] Registered new searcher Searcher@36137e08 
main{StandardDirectoryReader(segments_2:7:nrt _1(4.5.1):C1)}
389545 [commitScheduler-7-thread-1] INFO  org.apache.solr.update.UpdateHandler  
– start

[jira] [Assigned] (SOLR-5658) commitWithin does not reflect the new documents added

2014-01-23 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar reassigned SOLR-5658:
---

Assignee: Shalin Shekhar Mangar

 commitWithin does not reflect the new documents added
 -

 Key: SOLR-5658
 URL: https://issues.apache.org/jira/browse/SOLR-5658
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.6, 5.0
Reporter: Varun Thacker
Assignee: Shalin Shekhar Mangar

 I start 4 nodes using the setup mentioned on - 
 https://cwiki.apache.org/confluence/display/solr/Getting+Started+with+SolrCloud
  
 I added a document using - 
 curl http://localhost:8983/solr/update?commitWithin=1 -H Content-Type: 
 text/xml --data-binary 'adddocfield 
 name=idtestdoc/field/doc/add'
 In Solr 4.5.1 there is 1 soft commit with openSearcher=true and 1 hard commit 
 with openSearcher=false
 In Solr 4.6.x there is there is only one commit hard commit with 
 openSearcher=false
  
 So even after 10 seconds queries on none of the shards reflect the added 
 document. 
 This was also reported on the solr-user list ( 
 http://lucene.472066.n3.nabble.com/Possible-regression-for-Solr-4-6-0-commitWithin-does-not-work-with-replicas-td4106102.html
  )
 Here are the relevant logs 
 Logs from Solr 4.5.1
 Node 1:
 420021 [qtp619011445-12] INFO  
 org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
 webapp=/solr path=/update params={commitWithin=1} {add=[testdoc]} 0 45
  
 Node 2:
 119896 [qtp1608701025-10] INFO  
 org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
 webapp=/solr path=/update 
 params={distrib.from=http://192.168.1.103:8983/solr/collection1/update.distrib=TOLEADERwt=javabinversion=2}
  {add=[testdoc (1458003295513608192)]} 0 348
 129648 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – start 
 commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
 129679 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.search.SolrIndexSearcher  – Opening Searcher@e174f70 main
 129680 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – end_commit_flush
 129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 QuerySenderListener sending requests to Searcher@e174f70 
 main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
 129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 QuerySenderListener done.
 129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 [collection1] Registered new searcher Searcher@e174f70 
 main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
 134648 [commitScheduler-7-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – start 
 commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
 134658 [commitScheduler-7-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 SolrDeletionPolicy.onCommit: commits: num=2
   
 commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
  lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3; 
 maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_3,generation=3}
   
 commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
  lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3; 
 maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_4,generation=4}
 134658 [commitScheduler-7-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 newest commit generation = 4
 134660 [commitScheduler-7-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – end_commit_flush
  
  
 Node 3:
  
 Node 4:
 374545 [qtp1608701025-16] INFO  
 org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
 webapp=/solr path=/update 
 params={distrib.from=http://192.168.1.103:7574/solr/collection1/update.distrib=FROMLEADERwt=javabinversion=2}
  {add=[testdoc (1458002133233172480)]} 0 20
 384545 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – start 
 commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
 384552 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.search.SolrIndexSearcher  – Opening Searcher@36137e08 main
 384553 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – end_commit_flush
 384553 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 QuerySenderListener sending requests to Searcher@36137e08 
 main{StandardDirectoryReader(segments_2:7:nrt _1(4.5.1):C1)}
 384553 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  –

[jira] [Updated] (SOLR-5658) commitWithin does not reflect the new documents added

2014-01-23 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar updated SOLR-5658:


Description: 
I start 4 nodes using the setup mentioned on - 
https://cwiki.apache.org/confluence/display/solr/Getting+Started+with+SolrCloud
 
I added a document using - 
curl http://localhost:8983/solr/update?commitWithin=1 -H Content-Type: 
text/xml --data-binary 'adddocfield name=idtestdoc/field/doc/add'

In Solr 4.5.1 there is 1 soft commit with openSearcher=true and 1 hard commit 
with openSearcher=false
In Solr 4.6.x there is there is only one commit hard commit with 
openSearcher=false
 
So even after 10 seconds queries on none of the shards reflect the added 
document. 

This was also reported on the solr-user list ( 
http://lucene.472066.n3.nabble.com/Possible-regression-for-Solr-4-6-0-commitWithin-does-not-work-with-replicas-td4106102.html
 )

Here are the relevant logs 

Logs from Solr 4.5.1
Node 1:
{code}
420021 [qtp619011445-12] INFO  
org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
webapp=/solr path=/update params={commitWithin=1} {add=[testdoc]} 0 45
{code}
 
Node 2:
{code}
119896 [qtp1608701025-10] INFO  
org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
webapp=/solr path=/update 
params={distrib.from=http://192.168.1.103:8983/solr/collection1/update.distrib=TOLEADERwt=javabinversion=2}
 {add=[testdoc (1458003295513608192)]} 0 348
129648 [commitScheduler-8-thread-1] INFO  org.apache.solr.update.UpdateHandler  
– start 
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
129679 [commitScheduler-8-thread-1] INFO  
org.apache.solr.search.SolrIndexSearcher  – Opening Searcher@e174f70 main
129680 [commitScheduler-8-thread-1] INFO  org.apache.solr.update.UpdateHandler  
– end_commit_flush
129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
QuerySenderListener sending requests to Searcher@e174f70 
main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
QuerySenderListener done.
129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
[collection1] Registered new searcher Searcher@e174f70 
main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
134648 [commitScheduler-7-thread-1] INFO  org.apache.solr.update.UpdateHandler  
– start 
commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
134658 [commitScheduler-7-thread-1] INFO  org.apache.solr.core.SolrCore  – 
SolrDeletionPolicy.onCommit: commits: num=2

commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3; 
maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_3,generation=3}

commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3; 
maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_4,generation=4}
134658 [commitScheduler-7-thread-1] INFO  org.apache.solr.core.SolrCore  – 
newest commit generation = 4
134660 [commitScheduler-7-thread-1] INFO  org.apache.solr.update.UpdateHandler  
– end_commit_flush
 {code}
 
Node 3:
 
Node 4:
{code}
374545 [qtp1608701025-16] INFO  
org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
webapp=/solr path=/update 
params={distrib.from=http://192.168.1.103:7574/solr/collection1/update.distrib=FROMLEADERwt=javabinversion=2}
 {add=[testdoc (1458002133233172480)]} 0 20
384545 [commitScheduler-8-thread-1] INFO  org.apache.solr.update.UpdateHandler  
– start 
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
384552 [commitScheduler-8-thread-1] INFO  
org.apache.solr.search.SolrIndexSearcher  – Opening Searcher@36137e08 main
384553 [commitScheduler-8-thread-1] INFO  org.apache.solr.update.UpdateHandler  
– end_commit_flush
384553 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
QuerySenderListener sending requests to Searcher@36137e08 
main{StandardDirectoryReader(segments_2:7:nrt _1(4.5.1):C1)}
384553 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
QuerySenderListener done.
384554 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
[collection1] Registered new searcher Searcher@36137e08 
main{StandardDirectoryReader(segments_2:7:nrt _1(4.5.1):C1)}
389545 [commitScheduler-7-thread-1] INFO  org.apache.solr.update.UpdateHandler  
– start 
commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
389549

[jira] [Commented] (SOLR-5658) commitWithin does not reflect the new documents added

2014-01-23 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar commented on SOLR-5658:
-

Thanks for reporting this Varun.

The thing to note between the 4.5 logs and the 4.6.x logs is that in 4.5, there 
are two commit statements per node (1 soft commit with openSearcher=true and 
another hard commit with openSearcher=false) whereas in 4.6.x there is only one 
commit (hard commit with openSearcher=false). We need to find out why.

 commitWithin does not reflect the new documents added
 -

 Key: SOLR-5658
 URL: https://issues.apache.org/jira/browse/SOLR-5658
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.6, 5.0
Reporter: Varun Thacker
Assignee: Shalin Shekhar Mangar

 I start 4 nodes using the setup mentioned on - 
 https://cwiki.apache.org/confluence/display/solr/Getting+Started+with+SolrCloud
  
 I added a document using - 
 curl http://localhost:8983/solr/update?commitWithin=1 -H Content-Type: 
 text/xml --data-binary 'adddocfield 
 name=idtestdoc/field/doc/add'
 In Solr 4.5.1 there is 1 soft commit with openSearcher=true and 1 hard commit 
 with openSearcher=false
 In Solr 4.6.x there is there is only one commit hard commit with 
 openSearcher=false
  
 So even after 10 seconds queries on none of the shards reflect the added 
 document. 
 This was also reported on the solr-user list ( 
 http://lucene.472066.n3.nabble.com/Possible-regression-for-Solr-4-6-0-commitWithin-does-not-work-with-replicas-td4106102.html
  )
 Here are the relevant logs 
 Logs from Solr 4.5.1
 Node 1:
 {code}
 420021 [qtp619011445-12] INFO  
 org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
 webapp=/solr path=/update params={commitWithin=1} {add=[testdoc]} 0 45
 {code}
  
 Node 2:
 {code}
 119896 [qtp1608701025-10] INFO  
 org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
 webapp=/solr path=/update 
 params={distrib.from=http://192.168.1.103:8983/solr/collection1/update.distrib=TOLEADERwt=javabinversion=2}
  {add=[testdoc (1458003295513608192)]} 0 348
 129648 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – start 
 commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
 129679 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.search.SolrIndexSearcher  – Opening Searcher@e174f70 main
 129680 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – end_commit_flush
 129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 QuerySenderListener sending requests to Searcher@e174f70 
 main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
 129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 QuerySenderListener done.
 129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 [collection1] Registered new searcher Searcher@e174f70 
 main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
 134648 [commitScheduler-7-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – start 
 commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
 134658 [commitScheduler-7-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 SolrDeletionPolicy.onCommit: commits: num=2
   
 commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
  lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3; 
 maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_3,generation=3}
   
 commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
  lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3; 
 maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_4,generation=4}
 134658 [commitScheduler-7-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 newest commit generation = 4
 134660 [commitScheduler-7-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – end_commit_flush
  {code}
  
 Node 3:
  
 Node 4:
 {code}
 374545 [qtp1608701025-16] INFO  
 org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
 webapp=/solr path=/update 
 params={distrib.from=http://192.168.1.103:7574/solr/collection1/update.distrib=FROMLEADERwt=javabinversion=2}
  {add=[testdoc (1458002133233172480)]} 0 20
 384545 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – start 
 commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
 384552 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.search.SolrIndexSearcher  – Opening

[jira] [Commented] (SOLR-5658) commitWithin does not reflect the new documents added

2014-01-23 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar commented on SOLR-5658:
-

Also reported by a user (thanks Varun for pointing it out to me privately):

http://lucene.472066.n3.nabble.com/Possible-regression-for-Solr-4-6-0-commitWithin-does-not-work-with-replicas-td4106102.html

 commitWithin does not reflect the new documents added
 -

 Key: SOLR-5658
 URL: https://issues.apache.org/jira/browse/SOLR-5658
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.6, 5.0
Reporter: Varun Thacker
Assignee: Shalin Shekhar Mangar

 I start 4 nodes using the setup mentioned on - 
 https://cwiki.apache.org/confluence/display/solr/Getting+Started+with+SolrCloud
  
 I added a document using - 
 curl http://localhost:8983/solr/update?commitWithin=1 -H Content-Type: 
 text/xml --data-binary 'adddocfield 
 name=idtestdoc/field/doc/add'
 In Solr 4.5.1 there is 1 soft commit with openSearcher=true and 1 hard commit 
 with openSearcher=false
 In Solr 4.6.x there is there is only one commit hard commit with 
 openSearcher=false
  
 So even after 10 seconds queries on none of the shards reflect the added 
 document. 
 This was also reported on the solr-user list ( 
 http://lucene.472066.n3.nabble.com/Possible-regression-for-Solr-4-6-0-commitWithin-does-not-work-with-replicas-td4106102.html
  )
 Here are the relevant logs 
 Logs from Solr 4.5.1
 Node 1:
 {code}
 420021 [qtp619011445-12] INFO  
 org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
 webapp=/solr path=/update params={commitWithin=1} {add=[testdoc]} 0 45
 {code}
  
 Node 2:
 {code}
 119896 [qtp1608701025-10] INFO  
 org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
 webapp=/solr path=/update 
 params={distrib.from=http://192.168.1.103:8983/solr/collection1/update.distrib=TOLEADERwt=javabinversion=2}
  {add=[testdoc (1458003295513608192)]} 0 348
 129648 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – start 
 commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
 129679 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.search.SolrIndexSearcher  – Opening Searcher@e174f70 main
 129680 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – end_commit_flush
 129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 QuerySenderListener sending requests to Searcher@e174f70 
 main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
 129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 QuerySenderListener done.
 129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 [collection1] Registered new searcher Searcher@e174f70 
 main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
 134648 [commitScheduler-7-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – start 
 commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
 134658 [commitScheduler-7-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 SolrDeletionPolicy.onCommit: commits: num=2
   
 commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
  lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3; 
 maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_3,generation=3}
   
 commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
  lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3; 
 maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_4,generation=4}
 134658 [commitScheduler-7-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 newest commit generation = 4
 134660 [commitScheduler-7-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – end_commit_flush
  {code}
  
 Node 3:
  
 Node 4:
 {code}
 374545 [qtp1608701025-16] INFO  
 org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
 webapp=/solr path=/update 
 params={distrib.from=http://192.168.1.103:7574/solr/collection1/update.distrib=FROMLEADERwt=javabinversion=2}
  {add=[testdoc (1458002133233172480)]} 0 20
 384545 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – start 
 commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
 384552 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.search.SolrIndexSearcher  – Opening Searcher@36137e08 main
 384553 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – end_commit_flush
 384553

Re: [VOTE] Release Lucene/Solr 4.6.1 RC3

2014-01-23 Thread Michael McCandless

+1

SUCCESS! [0:38:52.784699]

Mike McCandless

http://blog.mikemccandless.com


On Thu, Jan 23, 2014 at 1:10 AM, Shalin Shekhar Mangar
shalinman...@gmail.com wrote:
 +1

 SUCCESS! [1:08:11.734266]

 On Thu, Jan 23, 2014 at 9:32 AM, Mark Miller markrmil...@gmail.com wrote:
 Please vote to release the following artifacts:

 http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560491/

 Here is my +1.

 SUCCESS! [0:50:55.923056]

 --
 - Mark



 --
 Regards,
 Shalin Shekhar Mangar.

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


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

[jira] [Commented] (LUCENE-5409) ToParentBlockJoinCollector.getTopGroups returns empty Groups

2014-01-23 Thread Michael McCandless (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879858#comment-13879858
 ] 

Michael McCandless commented on LUCENE-5409:


Hmm, maybe a BooleanQuery containing just a single TermQuery?

Or, maybe create a custom Query for this test that wraps another query but has 
its own unusual hashCode() impl...

 ToParentBlockJoinCollector.getTopGroups returns empty Groups
 

 Key: LUCENE-5409
 URL: https://issues.apache.org/jira/browse/LUCENE-5409
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
Affects Versions: 4.6
 Environment: Ubuntu 12.04
Reporter: Peng Cheng
Assignee: Michael McCandless
Priority: Critical
 Fix For: 4.7

   Original Estimate: 168h
  Remaining Estimate: 168h

 A bug is observed to cause unstable results returned by the getTopGroups 
 function of class ToParentBlockJoinCollector.
 In the scorer generation stage, the ToParentBlockJoinCollector will 
 automatically rewrite all the associated ToParentBlockJoinQuery (and their 
 subqueries), and save them into its in-memory Look-up table, namely 
 joinQueryID (see enroll() method for detail). Unfortunately, in the 
 getTopGroups method, the new ToParentBlockJoinQuery parameter is not 
 rewritten (at least users are not expected to do so). When the new one is 
 searched in the old lookup table (considering the impact of rewrite() on 
 hashCode()), the lookup will largely fail and eventually end up with a 
 topGroup collection consisting of only empty groups (their hitCounts are 
 guaranteed to be zero).
 An easy fix would be to rewrite the original BlockJoinQuery before invoking 
 getTopGroups method. However, the computational cost of this is not optimal. 
 A better but slightly more complex solution would be to save unrewrited 
 Queries into the lookup table.



--
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] (LUCENE-5410) Add fuzziness support to SimpleQueryParser

2014-01-23 Thread Upayavira (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879868#comment-13879868
 ] 

Upayavira commented on LUCENE-5410:
---

If the point of this query parser is to support the sort of thing that users 
type into search boxes, are they likely to enter fuzzy or phrase slop searches? 
This seems unlikely to me, and seems to take a SimpleQueryParser away from 
being simple. I'd suggest that if that functionality is to be added, it 
should be added somewhere where it is under programmatic control, not user 
control, such as how the edismax query parser accepts additional request 
parameters.

Thus ps=2 would set a phrase slop. fs=2 could set a value of 2 for fuzzy search 
also. This would seem more in keeping with the goal of a clean, simple query 
parser.


 Add fuzziness support to SimpleQueryParser
 --

 Key: LUCENE-5410
 URL: https://issues.apache.org/jira/browse/LUCENE-5410
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/queryparser
Affects Versions: 4.7
Reporter: Lee Hinman
Priority: Minor
 Attachments: LUCENE-5410.patch

   Original Estimate: 168h
  Remaining Estimate: 168h

 It would be nice to add fuzzy query support to the {{SimpleQueryParser}} so 
 that:
 {{foo~2}}
 generates a {{FuzzyQuery}} with an max edit distance of 2 and:
 {{foo bar~2}}
 generates a {{PhraseQuery}} with a slop of 2.



--
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-5473) Make one state.json per collection

2014-01-23 Thread Noble Paul (JIRA)


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

Noble Paul updated SOLR-5473:
-

Attachment: SOLR-5473.patch

updated to trunk

 Make one state.json per collection
 --

 Key: SOLR-5473
 URL: https://issues.apache.org/jira/browse/SOLR-5473
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
 Attachments: SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch


 As defined in the parent issue, store the states of each collection under 
 /collections/collectionname/state.json node



--
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-5659) Ignore or throw proper error message for bad delete containing bad composite ID

2014-01-23 Thread Markus Jelsma (JIRA)

Markus Jelsma created SOLR-5659:
---

 Summary: Ignore or throw proper error message for bad delete 
containing bad composite ID
 Key: SOLR-5659
 URL: https://issues.apache.org/jira/browse/SOLR-5659
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 5.0
 Environment: 5.0-SNAPSHOT 1480985:1559676M - markus - 2014-01-20 
13:48:08
Reporter: Markus Jelsma
 Fix For: 5.0


The following error is thrown when sending deleteById via SolrJ with ID ending 
with an exclamation mark, it is also the case for deletes by id via the URL. 
For some curious reason delete by query using the id field does not fail, but i 
would expect the same behaviour.

* fails: /solr/update?commit=truestream.body=deleteida!/id/delete
* ok: /solr/update?commit=truestream.body=deletequeryid:a!/query/delete

{code}
2014-01-22 15:32:48,826 ERROR [solr.core.SolrCore] - [http-8080-exec-5] - : 
java.lang.ArrayIndexOutOfBoundsException: 1
at 
org.apache.solr.common.cloud.CompositeIdRouter$KeyParser.getHash(CompositeIdRouter.java:291)
at 
org.apache.solr.common.cloud.CompositeIdRouter.sliceHash(CompositeIdRouter.java:58)
at 
org.apache.solr.common.cloud.HashBasedRouter.getTargetSlice(HashBasedRouter.java:33)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.setupRequest(DistributedUpdateProcessor.java:218)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processDelete(DistributedUpdateProcessor.java:961)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processDelete(UpdateRequestProcessor.java:55)
at 
org.apache.solr.handler.loader.XMLLoader.processDelete(XMLLoader.java:347)
at 
org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:278)
at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1915)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:785)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:203)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at 
org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
at 
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:744)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2282)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724) 
{code}

See also: 
http://lucene.472066.n3.nabble.com/AIOOBException-on-trunk-since-21st-or-22nd-build-td4112753.html



--
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

Re: [VOTE] Release Lucene/Solr 4.6.1 RC3

2014-01-23 Thread Robert Muir

+1

SUCCESS! [0:37:34.283758]



On Wed, Jan 22, 2014 at 11:02 PM, Mark Miller markrmil...@gmail.com wrote:

 Please vote to release the following artifacts:

 http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560491/

 Here is my +1.

 SUCCESS! [0:50:55.923056]

 --
 - Mark

[jira] [Commented] (LUCENE-5410) Add fuzziness support to SimpleQueryParser

2014-01-23 Thread Robert Muir (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879952#comment-13879952
 ] 

Robert Muir commented on LUCENE-5410:
-

Upayavira: I see your point, however one of the key advantages of this parser 
is the ability to selectively enable or disable any operator. The same 
arguments could be made for prefix queries or even the NOT operator (-), so it 
was added with that in mind (as well as to provide a way to do multiword 
synonyms: disable WHITESPACE).

As far as setting a parameter to make every term fuzzy, I don't think thats a 
good idea. In such a case I really think you should do n-gram indexing :)

 Add fuzziness support to SimpleQueryParser
 --

 Key: LUCENE-5410
 URL: https://issues.apache.org/jira/browse/LUCENE-5410
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/queryparser
Affects Versions: 4.7
Reporter: Lee Hinman
Priority: Minor
 Attachments: LUCENE-5410.patch

   Original Estimate: 168h
  Remaining Estimate: 168h

 It would be nice to add fuzzy query support to the {{SimpleQueryParser}} so 
 that:
 {{foo~2}}
 generates a {{FuzzyQuery}} with an max edit distance of 2 and:
 {{foo bar~2}}
 generates a {{PhraseQuery}} with a slop of 2.



--
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

78 matches

Mail list logo