[jira] [Commented] (SOLR-8621) solrconfig.xml: deprecate/replace with

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-8621:
--

[~cpoerschke] I've one question about the branch you created. It seemed that 
when you updated it to latest master, you did that with a _git merge_ command - 
correct? So if now I type 'git log' I see something like this:

{noformat}
solr-8621 commit
solr-8621 commit
non-solr-8621 commit
non-solr-8621 commit
non-solr-8621 commit
non-solr-8621 commit
non-solr-8621 commit
non-solr-8621 commit
non-solr-8621 commit
solr-8621 commit
solr-8621 commit
{noformat}

I know we're still discussing rebase vs merge on that thread, and I don't mean 
to continue the discussion here. I just want to level set with your 
expectations and understand if you did that intentionally, i.e. is that how you 
expect 'git log' to look eventually, or was that done as an afterthought?

I would personally rebase all commits we do in this branch on master, so that 
eventually we can have the commits stacked on top of the latest one in master. 
I would even squash all of them into a single commit which says "SOLR-8621: add 
MergePolicyFactory" and with a broader description.

So again, just mean to level set with your intentions here :).

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-8631) Throw UnsupportedOperationException for DatabaseMetaDataImpl.getTypeInfo()

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8631:
-
Summary: Throw UnsupportedOperationException for 
DatabaseMetaDataImpl.getTypeInfo()  (was: Implement 
DatabaseMetaDataImpl.getTypeInfo())

> Throw UnsupportedOperationException for DatabaseMetaDataImpl.getTypeInfo()
> --
>
> Key: SOLR-8631
> URL: https://issues.apache.org/jira/browse/SOLR-8631
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Fix For: Trunk
>
> Attachments: SOLR-8631.patch
>
>
> Once getSchemas (SOLR-8510) is implemented, DBVisualizer tries to get type 
> information with getDataTypes and fails with a NPE. A short term workaround 
> is to an UnsupportedOperationException instead of returning null.
> {code}
> 2016-02-01 21:27:33.868 FINE   647 [pool-3-thread-4 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getTypeInfo()
> 2016-02-01 21:27:33.870 FINE   647 [AWT-EventQueue-0 - B.executionFinished] 
> Exception while Connecting
> com.onseven.dbvis.K.B.P: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:2680)
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:1521)
>   at com.onseven.dbvis.K.B.L$3.run(Z:3032)
>   at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
>   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
>   at java.awt.EventQueue.access$500(EventQueue.java:97)
>   at java.awt.EventQueue$3.run(EventQueue.java:709)
>   at java.awt.EventQueue$3.run(EventQueue.java:703)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
>   at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
>   at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
>   at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
>   at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
>   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
>   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
>   at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122)
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192)
>   at javax.swing.SwingWorker.get(SwingWorker.java:602)
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:990)
>   ... 16 more
> Caused by: java.lang.NullPointerException
>   at com.onseven.dbvis.db.AbstractFacade.getDataTypes(Z:3212)
>   at com.onseven.dbvis.db.AbstractFacade.runConnectionSetup(Z:1260)
>   at com.onseven.dbvis.db.A.I.ￄﾷ(Z:3512)
>   at com.onseven.dbvis.db.A.B.execute(Z:2933)
>   at com.onseven.dbvis.K.B.Z.ￄﾁ(Z:2285)
>   at com.onseven.dbvis.K.B.L.ￄﾂ(Z:1374)
>   at com.onseven.dbvis.K.B.L.doInBackground(Z:1521)
>   at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at javax.swing.SwingWorker.run(SwingWorker.java:334)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



--
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] [Resolved] (SOLR-8631) Throw UnsupportedOperationException for DatabaseMetaDataImpl.getTypeInfo()

[Joel Bernstein (JIRA)]

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

Joel Bernstein resolved SOLR-8631.
--
Resolution: Implemented

> Throw UnsupportedOperationException for DatabaseMetaDataImpl.getTypeInfo()
> --
>
> Key: SOLR-8631
> URL: https://issues.apache.org/jira/browse/SOLR-8631
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Fix For: Trunk
>
> Attachments: SOLR-8631.patch
>
>
> Once getSchemas (SOLR-8510) is implemented, DBVisualizer tries to get type 
> information with getDataTypes and fails with a NPE. A short term workaround 
> is to an UnsupportedOperationException instead of returning null.
> {code}
> 2016-02-01 21:27:33.868 FINE   647 [pool-3-thread-4 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getTypeInfo()
> 2016-02-01 21:27:33.870 FINE   647 [AWT-EventQueue-0 - B.executionFinished] 
> Exception while Connecting
> com.onseven.dbvis.K.B.P: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:2680)
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:1521)
>   at com.onseven.dbvis.K.B.L$3.run(Z:3032)
>   at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
>   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
>   at java.awt.EventQueue.access$500(EventQueue.java:97)
>   at java.awt.EventQueue$3.run(EventQueue.java:709)
>   at java.awt.EventQueue$3.run(EventQueue.java:703)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
>   at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
>   at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
>   at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
>   at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
>   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
>   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
>   at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122)
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192)
>   at javax.swing.SwingWorker.get(SwingWorker.java:602)
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:990)
>   ... 16 more
> Caused by: java.lang.NullPointerException
>   at com.onseven.dbvis.db.AbstractFacade.getDataTypes(Z:3212)
>   at com.onseven.dbvis.db.AbstractFacade.runConnectionSetup(Z:1260)
>   at com.onseven.dbvis.db.A.I.ￄﾷ(Z:3512)
>   at com.onseven.dbvis.db.A.B.execute(Z:2933)
>   at com.onseven.dbvis.K.B.Z.ￄﾁ(Z:2285)
>   at com.onseven.dbvis.K.B.L.ￄﾂ(Z:1374)
>   at com.onseven.dbvis.K.B.L.doInBackground(Z:1521)
>   at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at javax.swing.SwingWorker.run(SwingWorker.java:334)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



--
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] (LUCENE-7007) Reduce block-tree GC/CPU cost when flushing or merging postings

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15128836#comment-15128836
 ] 

Robert Muir commented on LUCENE-7007:
-

Do you think luceneutil is the best dataset for comparison? I think its useful 
to see comparisons for "healthy" indexes like that too, but its still a far cry 
from structured datasets (more DOCS_ONLY/terms heavy) or abusive cases (e.g. 
massive n-gramming) where blocktree might be a performance bottleneck.

> Reduce block-tree GC/CPU cost when flushing or merging postings
> ---
>
> Key: LUCENE-7007
> URL: https://issues.apache.org/jira/browse/LUCENE-7007
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
> Attachments: LUCENE-7007.patch
>
>
> Writing postings is a GC and CPU heavy operation now, in part because of how
> block tree recursively builds up the tree structure, by creating many
> tiny FSTs which it inefficiently merges together as it walks up the
> tree eventually to the root block.
> So I tried a quick prototype (patch attached) to use a
> less-RAM-efficient, but much fewer tiny FST related objects, when
> writing postings.
> But in some quick indexing performance tests (luceneutil), it makes no
> measurable improvements to indexing performance.
> So I'm putting my patch up here for posterity ... I don't intend to
> commit it unless we can iterate it further.  It adds code complexity,
> it's not committable as-is (we need to conditionalize it so it
> sometimes does use FSTs, for segments with many terms), etc.



--
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-5743) Faceting with BlockJoin support

[Vijay Sekhri (JIRA)]

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

Vijay Sekhri updated SOLR-5743:
---
Attachment: solr_baseline.jpg

> Faceting with BlockJoin support
> ---
>
> Key: SOLR-5743
> URL: https://issues.apache.org/jira/browse/SOLR-5743
> Project: Solr
>  Issue Type: New Feature
>  Components: faceting
>Reporter: abipc
>Assignee: Mikhail Khludnev
>  Labels: features
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> service_baseline.png, solr_baseline.jpg
>
>
> For a sample inventory(note - nested documents) like this -   
>  
> 10
> parent
> Nike
> 
> 11
> Red
> XL
> 
> 
> 12
> Blue
> XL
> 
> 
> Faceting results must contain - 
> Red(1)
> XL(1) 
> Blue(1) 
> for a "q=*" query. 
> PS : The inventory example has been taken from this blog - 
> http://blog.griddynamics.com/2013/09/solr-block-join-support.html



--
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-8621) solrconfig.xml: deprecate/replace with

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-8621:
--

bq. my outlook currently is that all the master-solr-8621 history would be 
squashed 'at the end' and going back to 'master' there would be just a single 
commit. How does that sound

That sounds just like I would prefer it to happen, so glad to see we're in 
agreement here. Just FYI, it would have been easier to do this squash if you 
rebased master-solr-8621 on origin/master. Then all our commits would stack on 
top of each other.

We can still do this though, but I think we'd need to cherry-pick all commits 
there into a separate local branch, and then squash. Not sure it matters much 
now though. I don't mind doing the final "commit" after we finish iterating on 
the changes.

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-8632) filter cache miss even when partial queries(exhaustive) are cache hits

[vibhor goel (JIRA)]

vibhor goel created SOLR-8632:
-

 Summary: filter cache miss even when partial queries(exhaustive) 
are cache hits
 Key: SOLR-8632
 URL: https://issues.apache.org/jira/browse/SOLR-8632
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 5.4
 Environment: gave 2 boolean terms in the fq, got cache miss even when 
both individually are cache hits.
Reporter: vibhor goel






--
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-5743) Faceting with BlockJoin support

[Vijay Sekhri (JIRA)]

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

Vijay Sekhri commented on SOLR-5743:


Hi Mikhail,
I did benchmark testing of this feature to determine the efficiency and 
performance .
In our stress environment I have roughly 57 Mil documents in solr index. 10 
shards and each shard hosting around 5.7 Mil documents . Each shard has one 
replica and one leader .
Like in this figure.
!cluster.jpg!

There is solrj service that connects to solr cluster hosted on 8 hosts and each 
having 3 JVM instances. So in total 24 round robin instances of solrj service 
running and issuing queries to solr cluster. 
Solr version is 5.3.1

Here is the baseline 
With a load of 50 requests per seconds to the solrj service the average 
response times in service is 290 milliseconds. Same translated into solr 
cluster results in average response Qtimes of 22 milliseconds.
Here is the picture of average response times at service 

!service_baseline.png!

Here is the picture of average response Qtime of the solr
!solr_baseline.jpg!


Now I converted most of the documents with parent child relationship . In total 
there were 27 Mil new child documents  . So the total count of the documents 
increased from 57 Mil to 83 Mil documents.  I converted all the queries into 
the format of parent child in the solrj service layer .   Now with the same 
load the average response times in service increased to 1.3 seconds and average 
response Qtimes increased to 500 milliseconds. 
The solr version is 5.4. trunk with your code in it . 

Here is the picture of average response times at service with parent child
!service_new_baseline.jpg!

Here is the picture of average response Qtime of the solr with parent child 
!solr_new_baseline.jpg!

The overall performance was 10 times slower in solr layer and 3 times slower in 
solrj service layer with the same load . 

BTW I only tested with org.apache.solr.search.join.BlockJoinFacetComponent . Do 
you think that org.apache.solr.search.join.BlockJoinDocSetFacetComponent would 
be faster? 

Vijay

> Faceting with BlockJoin support
> ---
>
> Key: SOLR-5743
> URL: https://issues.apache.org/jira/browse/SOLR-5743
> Project: Solr
>  Issue Type: New Feature
>  Components: faceting
>Reporter: abipc
>Assignee: Mikhail Khludnev
>  Labels: features
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> cluster.jpg, service_baseline.png, service_new_baseline.jpg, 
> solr_baseline.jpg, solr_new_baseline.jpg
>
>
> For a sample inventory(note - nested documents) like this -   
>  
> 10
> parent
> Nike
> 
> 11
> Red
> XL
> 
> 
> 12
> Blue
> XL
> 
> 
> Faceting results must contain - 
> Red(1)
> XL(1) 
> Blue(1) 
> for a "q=*" query. 
> PS : The inventory example has been taken from this blog - 
> http://blog.griddynamics.com/2013/09/solr-block-join-support.html



--
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-5743) Faceting with BlockJoin support

[Vijay Sekhri (JIRA)]

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

Vijay Sekhri updated SOLR-5743:
---
Attachment: solr_new_baseline.jpg
service_new_baseline.jpg

> Faceting with BlockJoin support
> ---
>
> Key: SOLR-5743
> URL: https://issues.apache.org/jira/browse/SOLR-5743
> Project: Solr
>  Issue Type: New Feature
>  Components: faceting
>Reporter: abipc
>Assignee: Mikhail Khludnev
>  Labels: features
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> service_baseline.png, service_new_baseline.jpg, solr_baseline.jpg, 
> solr_new_baseline.jpg
>
>
> For a sample inventory(note - nested documents) like this -   
>  
> 10
> parent
> Nike
> 
> 11
> Red
> XL
> 
> 
> 12
> Blue
> XL
> 
> 
> Faceting results must contain - 
> Red(1)
> XL(1) 
> Blue(1) 
> for a "q=*" query. 
> PS : The inventory example has been taken from this blog - 
> http://blog.griddynamics.com/2013/09/solr-block-join-support.html



--
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-5743) Faceting with BlockJoin support

[Vijay Sekhri (JIRA)]

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

Vijay Sekhri updated SOLR-5743:
---
Attachment: service_baseline.png

> Faceting with BlockJoin support
> ---
>
> Key: SOLR-5743
> URL: https://issues.apache.org/jira/browse/SOLR-5743
> Project: Solr
>  Issue Type: New Feature
>  Components: faceting
>Reporter: abipc
>Assignee: Mikhail Khludnev
>  Labels: features
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> service_baseline.png
>
>
> For a sample inventory(note - nested documents) like this -   
>  
> 10
> parent
> Nike
> 
> 11
> Red
> XL
> 
> 
> 12
> Blue
> XL
> 
> 
> Faceting results must contain - 
> Red(1)
> XL(1) 
> Blue(1) 
> for a "q=*" query. 
> PS : The inventory example has been taken from this blog - 
> http://blog.griddynamics.com/2013/09/solr-block-join-support.html



--
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-8507) Add information about database product name, product version, driver name, and driver version.

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8507:


Ah I thought I had fixed the issue with looping through all the nodes. I can 
update this later today most likely. I'll keep the loop just short circuit when 
the first node responds instead of comparing versions.

> Add information about database product name, product version, driver name, 
> and driver version.
> --
>
> Key: SOLR-8507
> URL: https://issues.apache.org/jira/browse/SOLR-8507
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>Priority: Minor
> Attachments: SOLR-8507.patch, SOLR-8507.patch
>
>
> DBVisualizer asks for information about database product name, product 
> version, driver name, and driver version. These should be implemented in 
> DatabaseMetaDataImpl.
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDatabaseProductName()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDatabaseProductVersion()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDriverName()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDriverVersion()



--
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-8507) Add information about database product name, product version, driver name, and driver version.

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8507:
---
Attachment: SOLR-8507.patch

Attached patch with commented out tests which short circuits when it finds 
first node that doesn't fail getting version information.

> Add information about database product name, product version, driver name, 
> and driver version.
> --
>
> Key: SOLR-8507
> URL: https://issues.apache.org/jira/browse/SOLR-8507
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>Priority: Minor
> Attachments: SOLR-8507.patch, SOLR-8507.patch, SOLR-8507.patch
>
>
> DBVisualizer asks for information about database product name, product 
> version, driver name, and driver version. These should be implemented in 
> DatabaseMetaDataImpl.
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDatabaseProductName()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDatabaseProductVersion()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDriverName()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDriverVersion()



--
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] [Resolved] (SOLR-8510) Implement DatabaseMetaDataImpl.getSchemas()

[Joel Bernstein (JIRA)]

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

Joel Bernstein resolved SOLR-8510.
--
Resolution: Implemented

> Implement DatabaseMetaDataImpl.getSchemas()
> ---
>
> Key: SOLR-8510
> URL: https://issues.apache.org/jira/browse/SOLR-8510
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8510.patch, SOLR-8510.patch
>
>
> DBVisualizer asks for information about schemas just like it does for 
> catalogs.
> 2016-01-07 13:58:49.974 FINE83 [Thread-423 - B.execute] Execute Command: 
> getSchemaNames
> 2016-01-07 13:58:49.975 FINE83 [Thread-423 - O.ￄﾔ] getSchema() for: abc
> 2016-01-07 13:58:49.975 FINE83 [pool-3-thread-12 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getSchemas()
> 2016-01-07 13:58:49.976 INFO83 [Thread-423 - L.ￄﾂ] Error getting schemas 
> for: abc
> java.lang.IllegalArgumentException: model passed to DefaultTableModelWrapper 
> cannot be null
>   at com.jidesoft.grid.TableModelWrapperImpl.(Unknown Source)
>   at com.jidesoft.grid.DefaultTableModelWrapper.(Unknown Source)
>   at com.jidesoft.grid.FilterableTableModel.(Unknown Source)
>   at com.jidesoft.grid.FilterableTreeTableModel.(Unknown Source)
>   at com.onseven.dbvis.K.B._.(Z:1161)
>   at com.onseven.dbvis.db.AbstractFacade.executeAndGet(Z:975)
>   at com.onseven.dbvis.db.AbstractFacade.getSchemaNames(Z:921)
>   at com.onseven.dbvis.L.L.ￄﾂ(Z:2202)
>   at com.onseven.dbvis.F.F$A.run(Z:3578)
>   at java.lang.Thread.run(Thread.java:745)



--
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-8502) Improve Solr JDBC Driver to support SQL Clients like DBVisualizer

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8502:


Including: SOLR-8508, SOLR-8510, SOLR-8631, and SOLR-8507

DBVisualizer with screenshot-4.png

JiSQL
{code}
java -cp 
/opt/jisql/lib/jisql-2.0.11.jar:/opt/jisql/lib/jopt-simple-3.2.jar:/opt/solr/dist/solrj-lib/*:/opt/solr/dist/solr-solrj-6.0.0-SNAPSHOT.jar
 com.xigole.util.sql.Jisql -user test -password test -driver 
org.apache.solr.client.solrj.io.sql.DriverImpl -cstring 
'jdbc:solr://docker.vm:9983?collection=test=map_reduce' -c \; 
-query 'select fielda, fieldb, fieldc, fieldd_s, fielde_i from test limit 10;'

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.
SLF4J: Failed to load class "org.slf4j.impl.StaticMDCBinder".
SLF4J: Defaulting to no-operation MDCAdapter implementation.
SLF4J: See http://www.slf4j.org/codes.html#no_static_mdc_binder for further 
details.
fielda | fieldb | fieldc | fieldd_s | fielde_i |
---+++--+--|
a1 | b1 |  1 |   d1 |1 |
a2 | b2 |  2 |   d1 |2 |
a1 | b3 |  3 | NULL |1 |
a1 | b4 |  4 |   d2 | NULL |
a2 | b2 |   NULL |   d2 |2 |
{code}

> Improve Solr JDBC Driver to support SQL Clients like DBVisualizer
> -
>
> Key: SOLR-8502
> URL: https://issues.apache.org/jira/browse/SOLR-8502
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>  Labels: jdbc
> Fix For: Trunk
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> screenshot-4.png
>
>
> Currently when trying to connect to Solr with the JDBC driver with a SQL 
> client the driver must implement more methods and metadata to allow 
> connections. This JIRA is designed to act as an umbrella for the JDBC changes.
> An initial pass from a few months ago is here: 
> https://github.com/risdenk/lucene-solr/tree/expand-jdbc. This needs to be 
> broken up and create patches for the related sub tasks.



--
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] [Comment Edited] (SOLR-5730) make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector configurable in Solr

[Shai Erera (JIRA)]

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

Shai Erera edited comment on SOLR-5730 at 2/2/16 6:10 PM:
--

[~hossman], this issue is now on hold until we finish with SOLR-8621 (see 
[~cpoerschke] earlier comment).

[~jkrupan] the intention of SOLR-8621 and this issue is to allow users to 
define compound merge policies in {{solrconfig.xml}} with ease. Currently, it's 
impossible and if you want to use something like {{UpgradeIndexMergePolicy}}, 
you have to create your own MP class which will delegate internally to 
{{UpgradeIndexMP}}. For users who still want to define simple merge policies 
like {{TieredMergePolicy}}, the structure in the XML will not be much 
different. Instead of:

{code}

  42

{code}

They will need to specify

{code}

  42

{code}

The factory allows more advanced users to create whatever MP they want, rather 
easily. Also, with this change, we deprecate some settings that are now defined 
globally (like _mergeFactor_), and move them inside the 
{{}} section, where they belong.

Hope this clarifies it better.


was (Author: shaie):
[~hossman], this issue is now on hold until we finish with SOLR-8621 (see 
[~cpoerschke] earlier comment).

[~jkrupan] the intention of SOLR-8621 and this issue is to allow users to 
define compound merge policies in {{solrconfig.xml}} with ease. Currently, it's 
impossible and if you want to use something like {{UpgradeIndexMergePolicy}}, 
you have to create your own MP class which will delegate internally to 
{{UpgradeIndexMP}}. For users who still want to define simple merge policies 
like {{TieredMergePolicy}}, the structure in the XML will not be much 
different. Instead of:

{code}

  42

{code}

They will need to specify

{code}

  42

{code}

The factory allows more advanced users to create whatever MP they want, rather 
easily. Also, with this change, we deprecate some settings that are now defined 
globally (like _mergeFactor_), and move them inside the 
{{}} section, where they belong.

Hope this clarifies it better.

> make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector 
> configurable in Solr
> --
>
> Key: SOLR-5730
> URL: https://issues.apache.org/jira/browse/SOLR-5730
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-5730-part1of2.patch, SOLR-5730-part1of2.patch, 
> SOLR-5730-part2of2.patch, SOLR-5730-part2of2.patch
>
>
> *Example configuration (solrconfig.xml) - corresponding to latest attached 
> patch:*
> {noformat}
> 
>   timestamp desc
> 
> {noformat}
> *Example configuration (solrconfig.xml) - corresponding to current 
> (work-in-progress master-solr-8621) SOLR-8621 efforts:*
> {noformat}
> -
> +
> +  TieredMergePolicyFactory
> +  timestamp desc
> +
> {noformat}
> *Example use (EarlyTerminatingSortingCollector):*
> {noformat}
> =timestamp+desc=true
> {noformat}



--
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-8631) Throw UnsupportedOperationException for DatabaseMetaDataImpl.getTypeInfo()

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8631:
---

Commit 70ad8316f4964d1b62b53f02e5fdf7798d5a8350 in lucene-solr's branch 
refs/heads/master from jbernste
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=70ad831 ]

SOLR-8631: Throw UnsupportedOperationException for 
DatabaseMetaDataImpl.getTypeInfo()


> Throw UnsupportedOperationException for DatabaseMetaDataImpl.getTypeInfo()
> --
>
> Key: SOLR-8631
> URL: https://issues.apache.org/jira/browse/SOLR-8631
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Fix For: Trunk
>
> Attachments: SOLR-8631.patch
>
>
> Once getSchemas (SOLR-8510) is implemented, DBVisualizer tries to get type 
> information with getDataTypes and fails with a NPE. A short term workaround 
> is to an UnsupportedOperationException instead of returning null.
> {code}
> 2016-02-01 21:27:33.868 FINE   647 [pool-3-thread-4 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getTypeInfo()
> 2016-02-01 21:27:33.870 FINE   647 [AWT-EventQueue-0 - B.executionFinished] 
> Exception while Connecting
> com.onseven.dbvis.K.B.P: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:2680)
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:1521)
>   at com.onseven.dbvis.K.B.L$3.run(Z:3032)
>   at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
>   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
>   at java.awt.EventQueue.access$500(EventQueue.java:97)
>   at java.awt.EventQueue$3.run(EventQueue.java:709)
>   at java.awt.EventQueue$3.run(EventQueue.java:703)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
>   at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
>   at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
>   at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
>   at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
>   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
>   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
>   at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122)
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192)
>   at javax.swing.SwingWorker.get(SwingWorker.java:602)
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:990)
>   ... 16 more
> Caused by: java.lang.NullPointerException
>   at com.onseven.dbvis.db.AbstractFacade.getDataTypes(Z:3212)
>   at com.onseven.dbvis.db.AbstractFacade.runConnectionSetup(Z:1260)
>   at com.onseven.dbvis.db.A.I.ￄﾷ(Z:3512)
>   at com.onseven.dbvis.db.A.B.execute(Z:2933)
>   at com.onseven.dbvis.K.B.Z.ￄﾁ(Z:2285)
>   at com.onseven.dbvis.K.B.L.ￄﾂ(Z:1374)
>   at com.onseven.dbvis.K.B.L.doInBackground(Z:1521)
>   at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at javax.swing.SwingWorker.run(SwingWorker.java:334)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



--
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-8502) Improve Solr JDBC Driver to support SQL Clients like DBVisualizer

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8502:
--

I think we can close out SOLR-8502 before finishing SOLR-8521. I think we 
should add a short page of documentation specifically for the JDBC Driver and 
we can include a section about connecting with DBVisualizer.

> Improve Solr JDBC Driver to support SQL Clients like DBVisualizer
> -
>
> Key: SOLR-8502
> URL: https://issues.apache.org/jira/browse/SOLR-8502
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>  Labels: jdbc
> Fix For: Trunk
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> Currently when trying to connect to Solr with the JDBC driver with a SQL 
> client the driver must implement more methods and metadata to allow 
> connections. This JIRA is designed to act as an umbrella for the JDBC changes.
> An initial pass from a few months ago is here: 
> https://github.com/risdenk/lucene-solr/tree/expand-jdbc. This needs to be 
> broken up and create patches for the related sub tasks.



--
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-8308) Core gets inaccessible after RENAME operation with special characters

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8308:
---

Commit 70f87420ab106989c9501870f2f851d5f5f85ea5 in lucene-solr's branch 
refs/heads/master from [~erickerickson]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=70f8742 ]

SOLR-8308: Core gets inaccessible after RENAME operation with special characters


> Core gets inaccessible after RENAME operation with special characters
> -
>
> Key: SOLR-8308
> URL: https://issues.apache.org/jira/browse/SOLR-8308
> Project: Solr
>  Issue Type: Bug
>Reporter: Adam Johnson
>Assignee: Erick Erickson
> Attachments: SOLR-8308.patch, SOLR-8308.patch, SOLR-8308.patch, 
> SOLR-8308.patch
>
>
> You can rename a core using the following modified URL 
> https://SOLR:PORT/solr/admin/cores?wt=json=false=RENAME=test_app_shared2_replica2=%3Csvg+onload%3Dalert(1)%3E&_=1445468005152.
>  The core becomes inaccessible / unusable.  There should be more form 
> validation to the core name assignment



--
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-5743) Faceting with BlockJoin support

[Vijay Sekhri (JIRA)]

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

Vijay Sekhri updated SOLR-5743:
---
Attachment: cluster.jpg

> Faceting with BlockJoin support
> ---
>
> Key: SOLR-5743
> URL: https://issues.apache.org/jira/browse/SOLR-5743
> Project: Solr
>  Issue Type: New Feature
>  Components: faceting
>Reporter: abipc
>Assignee: Mikhail Khludnev
>  Labels: features
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, SOLR-5743.patch, 
> cluster.jpg, service_baseline.png, service_new_baseline.jpg, 
> solr_baseline.jpg, solr_new_baseline.jpg
>
>
> For a sample inventory(note - nested documents) like this -   
>  
> 10
> parent
> Nike
> 
> 11
> Red
> XL
> 
> 
> 12
> Blue
> XL
> 
> 
> Faceting results must contain - 
> Red(1)
> XL(1) 
> Blue(1) 
> for a "q=*" query. 
> PS : The inventory example has been taken from this blog - 
> http://blog.griddynamics.com/2013/09/solr-block-join-support.html



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

[JENKINS] Lucene-Solr-trunk-Solaris (64bit/jdk1.8.0) - Build # 374 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/374/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test

Error Message:
Error from server at https://127.0.0.1:45523/ao_/awholynewcollection_0: non ok 
status: 500, message:Server Error

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:45523/ao_/awholynewcollection_0: non ok 
status: 500, message:Server Error
at 
__randomizedtesting.SeedInfo.seed([B6D281C53D8EBED7:3E86BE1F9372D32F]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:511)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForNon403or404or503(AbstractFullDistribZkTestBase.java:1773)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:664)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:160)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[jira] [Commented] (SOLR-8510) Implement DatabaseMetaDataImpl.getSchemas()

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8510:
--

This latest patch is looking good. Will commit shortly without changes.

> Implement DatabaseMetaDataImpl.getSchemas()
> ---
>
> Key: SOLR-8510
> URL: https://issues.apache.org/jira/browse/SOLR-8510
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8510.patch, SOLR-8510.patch
>
>
> DBVisualizer asks for information about schemas just like it does for 
> catalogs.
> 2016-01-07 13:58:49.974 FINE83 [Thread-423 - B.execute] Execute Command: 
> getSchemaNames
> 2016-01-07 13:58:49.975 FINE83 [Thread-423 - O.ￄﾔ] getSchema() for: abc
> 2016-01-07 13:58:49.975 FINE83 [pool-3-thread-12 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getSchemas()
> 2016-01-07 13:58:49.976 INFO83 [Thread-423 - L.ￄﾂ] Error getting schemas 
> for: abc
> java.lang.IllegalArgumentException: model passed to DefaultTableModelWrapper 
> cannot be null
>   at com.jidesoft.grid.TableModelWrapperImpl.(Unknown Source)
>   at com.jidesoft.grid.DefaultTableModelWrapper.(Unknown Source)
>   at com.jidesoft.grid.FilterableTableModel.(Unknown Source)
>   at com.jidesoft.grid.FilterableTreeTableModel.(Unknown Source)
>   at com.onseven.dbvis.K.B._.(Z:1161)
>   at com.onseven.dbvis.db.AbstractFacade.executeAndGet(Z:975)
>   at com.onseven.dbvis.db.AbstractFacade.getSchemaNames(Z:921)
>   at com.onseven.dbvis.L.L.ￄﾂ(Z:2202)
>   at com.onseven.dbvis.F.F$A.run(Z:3578)
>   at java.lang.Thread.run(Thread.java:745)



--
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-8507) Add information about database product name, product version, driver name, and driver version.

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8507:
--

I think it makes sense to commit this now so since it's working with manual 
testing. Then come back in another ticket and work with the test framework to 
support these calls.

I would like to make one change to the implementation though, which is to call 
only one node to get the version information. Calling each live node could be 
quite a large number of calls with a large cluster.

> Add information about database product name, product version, driver name, 
> and driver version.
> --
>
> Key: SOLR-8507
> URL: https://issues.apache.org/jira/browse/SOLR-8507
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>Priority: Minor
> Attachments: SOLR-8507.patch, SOLR-8507.patch
>
>
> DBVisualizer asks for information about database product name, product 
> version, driver name, and driver version. These should be implemented in 
> DatabaseMetaDataImpl.
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDatabaseProductName()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDatabaseProductVersion()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDriverName()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDriverVersion()



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

[GitHub] lucene-solr pull request:

[iorixxx]

Github user iorixxx commented on the pull request:


https://github.com/apache/lucene-solr/commit/a48ba5090beafc725ab04e67996e42f0b3f31348#commitcomment-15838444
  
Wouldn’t it be nice to use 
`TimeUnit.MILLISECONDS.convert(System.nanoTime() - t0, TimeUnit.NANOSECONDS)` 
here?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Updated] (SOLR-8502) Improve Solr JDBC Driver to support SQL Clients like DBVisualizer

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8502:
---
Attachment: screenshot-4.png

> Improve Solr JDBC Driver to support SQL Clients like DBVisualizer
> -
>
> Key: SOLR-8502
> URL: https://issues.apache.org/jira/browse/SOLR-8502
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>  Labels: jdbc
> Fix For: Trunk
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> screenshot-4.png
>
>
> Currently when trying to connect to Solr with the JDBC driver with a SQL 
> client the driver must implement more methods and metadata to allow 
> connections. This JIRA is designed to act as an umbrella for the JDBC changes.
> An initial pass from a few months ago is here: 
> https://github.com/risdenk/lucene-solr/tree/expand-jdbc. This needs to be 
> broken up and create patches for the related sub tasks.



--
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-8507) Add information about database product name, product version, driver name, and driver version.

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8507:
--

Read through patch and made some slight changes. It's now exiting out of the 
loop even if there is an error on first live node. I don't want to get into a 
situation where we cycle through each node getting errors. I'll attach a patch 
with the changes. I'll take a little time manually testing this with 
DbVisualizer before committing.

Once this is committed do you feel we're ready to close out SOLR-8502 and add 
it to CHANGES.txt?

> Add information about database product name, product version, driver name, 
> and driver version.
> --
>
> Key: SOLR-8507
> URL: https://issues.apache.org/jira/browse/SOLR-8507
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>Priority: Minor
> Attachments: SOLR-8507.patch, SOLR-8507.patch, SOLR-8507.patch
>
>
> DBVisualizer asks for information about database product name, product 
> version, driver name, and driver version. These should be implemented in 
> DatabaseMetaDataImpl.
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDatabaseProductName()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDatabaseProductVersion()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDriverName()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDriverVersion()



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

[GitHub] lucene-solr pull request:

[mikemccand]

Github user mikemccand commented on the pull request:


https://github.com/apache/lucene-solr/commit/a48ba5090beafc725ab04e67996e42f0b3f31348#commitcomment-15840601
  
Yes it would @lorixxx!  Maybe open an issue / PR at Lucene for this?  
Thanks.

There are many places doing the conversion "directly" now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (SOLR-8627) Retrieve position ranking in json facets

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8627:


Thanks for the idea Pablo, that does sound like an interesting feature...

> Retrieve position ranking in json facets
> 
>
> Key: SOLR-8627
> URL: https://issues.apache.org/jira/browse/SOLR-8627
> Project: Solr
>  Issue Type: New Feature
>Reporter: Pablo Anzorena
>
> It would be fantastic to have the position (in terms of a specific stat or 
> count) ranking in the json facets. Let's suppose we have the field "client" 
> of type string and we make a facet to see the top 10 (limit:10, offset:0), so 
> the first bucket will have the ranking 1, the second bucket will have the 
> ranking 2, and so on. Now we ask for the top 10 starting from 10 (limit:10, 
> offset:10) so the first bucket will have the ranking 11, the second one 
> ranking 12, and so on. Until now, there is no big deal, you just sum the 
> offset with the bucket position.
> But what happens if I want to know the ranking of a specific client (or a 
> list of them)? One possible way would be to ask for all clients (limit:-1), 
> but it will have performance issues on fields with big cardinality.
> So, I'm asking for an option that receives a list of terms and a stat, and 
> returns the list of terms with their respective position (or ranking) that 
> produce the query.



--
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] (LUCENE-7008) TestSortingMergePolicy.testForceMergeNotNeeded fails

[Shai Erera (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15129009#comment-15129009
 ] 

Shai Erera commented on LUCENE-7008:


I believe I found the cause. The test sets noCFSRatio randomly (and with that 
seed to {{0.0}}), however since {{MergePolicy#setNoCFSRatio()}} is final, the 
call doesn't get through to the wrapped {{TieredMergePolicy}}. Because of that, 
it leads to finding the last segment to not be compound, and therefore it 
triggers a merge of the last segment to make it compound.

As a workaround, I've slightly changed the test to call setNoCFSRatio in a 
protected method, and overrode in {{TestSortingMergePolicy}}. Now the test 
passes with that seed.

However, I wonder if we don't need a better solution, i.e. removing 'final' 
from methods on {{MergePolicy}}, so that delegating MPs can override them 
properly. This also affects {{UpgradeIndexMergePolicy}}. We can do that in a 
separate issue though.

> TestSortingMergePolicy.testForceMergeNotNeeded fails
> 
>
> Key: LUCENE-7008
> URL: https://issues.apache.org/jira/browse/LUCENE-7008
> Project: Lucene - Core
>  Issue Type: Test
>Affects Versions: 5.5, Trunk
>Reporter: Christine Poerschke
>
> {{TestSortingMergePolicy.testForceMergeNotNeeded}} (recently added by 
> LUCENE-7006) regularly and reproducibly fails e.g.
> {code}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestSortingMergePolicy -Dtests.method=testForceMergeNotNeeded 
> -Dtests.seed=BAF97ED1D97DDEEE -Dtests.slow=true -Dtests.locale=nl-NL 
> -Dtests.timezone=CST6CDT -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
> {code}
> Stack Trace:
> {code}
> java.lang.AssertionError
> at 
> __randomizedtesting.SeedInfo.seed([BAF97ED1D97DDEEE:A6DA06CB422235FB]:0)
> at 
> org.apache.lucene.index.BaseMergePolicyTestCase$1.merge(BaseMergePolicyTestCase.java:44)
> at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1931)
> at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1764)
> at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1721)
> at 
> org.apache.lucene.index.BaseMergePolicyTestCase.testForceMergeNotNeeded(BaseMergePolicyTestCase.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> 

[jira] [Created] (SOLR-8633) DistributedUpdateProcess.processCommit calls finish() - violates lifecycle, causes finish to be called twice (redundent code execution)

[Hoss Man (JIRA)]

Hoss Man created SOLR-8633:
--

 Summary: DistributedUpdateProcess.processCommit calls finish() - 
violates lifecycle, causes finish to be called twice (redundent code execution)
 Key: SOLR-8633
 URL: https://issues.apache.org/jira/browse/SOLR-8633
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man


trying to wrap my head around a weird bug in my experiements with SOLR-445, i 
realized that {{DUP.processDelete}} has a direct call to {{finish()}}.

This violates the normal lifecycle of an UpdateProcessor (finish is only 
suppose to be called exactly once after processing any/all UpdateCommands) and 
could potentially break any UpdateProcessors configured after DUP (or in my 
case: processors configured _before_ DUP that expect to be in charge of calling 
finish, and catching any resulting exceptions, as part of the normal life cycle)

Independent of how it impacts other update processors, this also means that:
# all the logic in {{DUP.doFinish}} is getting executed twice -- which seems 
kind of expensive/dangerous to me since there is leader initiated recovery 
involved in this method
# {{SolrCmdDistributor.finish()}} gets called twice, which means 
{{StreamingSolrClients.shutdown()}} gets called twice, which means 
{{ConcurrentUpdateSolrClient.close()}} gets called twice ... it seems like 
we're just getting really lucky that (as configured by DUP) all of these 
resources are still usable after being finished/shutdown/closed






--
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-8507) Add information about database product name, product version, driver name, and driver version.

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8507:
-
Attachment: SOLR-8507.patch

Patch with slight changes on error handling.

> Add information about database product name, product version, driver name, 
> and driver version.
> --
>
> Key: SOLR-8507
> URL: https://issues.apache.org/jira/browse/SOLR-8507
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>Priority: Minor
> Attachments: SOLR-8507.patch, SOLR-8507.patch, SOLR-8507.patch, 
> SOLR-8507.patch
>
>
> DBVisualizer asks for information about database product name, product 
> version, driver name, and driver version. These should be implemented in 
> DatabaseMetaDataImpl.
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDatabaseProductName()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDatabaseProductVersion()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDriverName()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDriverVersion()



--
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-8213) SolrJ JDBC support authentication

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8213:
---
Issue Type: Improvement  (was: Sub-task)
Parent: (was: SOLR-8502)

> SolrJ JDBC support authentication
> -
>
> Key: SOLR-8213
> URL: https://issues.apache.org/jira/browse/SOLR-8213
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>
> SolrJ JDBC doesn't support authentication where as Solr supports Basic and 
> Kerberos authentication currently. 



--
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-8633) DistributedUpdateProcess.processCommit calls finish() - violates lifecycle, causes finish to be called twice (redundent code execution)

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8633:



I suspect that the _intended_ goal here (in processCommit) is to do the same 
sort of "force sequential ordering" type logic as doDeleteByQuery -- in which 
case we can/should replace the call to {{finish()}} with a call to 
{{cmdDistrib.finish()}} ... except that i'm still concerned about 
shutdown/closing of clients done by that method, and wonder if _both_ 
processCommit & processDelete should be calling 
{{SolrCmdDistributor.blockAndDoRetries()}} directly? (we would just need to 
make that method public)

Hoping folks like [~markrmil...@gmail.com] / [~tim.potter] might have some 
ideas about this?

> DistributedUpdateProcess.processCommit calls finish() - violates lifecycle, 
> causes finish to be called twice (redundent code execution)
> ---
>
> Key: SOLR-8633
> URL: https://issues.apache.org/jira/browse/SOLR-8633
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> trying to wrap my head around a weird bug in my experiements with SOLR-445, i 
> realized that {{DUP.processDelete}} has a direct call to {{finish()}}.
> This violates the normal lifecycle of an UpdateProcessor (finish is only 
> suppose to be called exactly once after processing any/all UpdateCommands) 
> and could potentially break any UpdateProcessors configured after DUP (or in 
> my case: processors configured _before_ DUP that expect to be in charge of 
> calling finish, and catching any resulting exceptions, as part of the normal 
> life cycle)
> Independent of how it impacts other update processors, this also means that:
> # all the logic in {{DUP.doFinish}} is getting executed twice -- which seems 
> kind of expensive/dangerous to me since there is leader initiated recovery 
> involved in this method
> # {{SolrCmdDistributor.finish()}} gets called twice, which means 
> {{StreamingSolrClients.shutdown()}} gets called twice, which means 
> {{ConcurrentUpdateSolrClient.close()}} gets called twice ... it seems like 
> we're just getting really lucky that (as configured by DUP) all of these 
> resources are still usable after being finished/shutdown/closed



--
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] (LUCENE-5666) Add UninvertingReader

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15129040#comment-15129040
 ] 

Mikhail Khludnev commented on LUCENE-5666:
--

Hello, 
I want to clarify 
DeleteByQueryWrapper 
[refers|https://github.com/apache/lucene-solr/commit/ff8e841fa1b26875a95fd3ec67cd785649ba35b3#diff-6f6dad2e619f95bbe7a7985700ab3060R38]
 to some caching
{{Even though we wrap for each query, UninvertingReader's core cache key is the 
inner one, so it still reuses fieldcaches and so on.}} 
We evidence that indexing stuck on repeatedly building UninversionMap for every 
deleteByQuery 
{code}  
 AtomicReader wrap(AtomicReader reader) {
return new UninvertingReader(reader, schema.getUninversionMap(reader));  
}
{code}
Is there any chance to make it faster? 

> Add UninvertingReader
> -
>
> Key: LUCENE-5666
> URL: https://issues.apache.org/jira/browse/LUCENE-5666
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-5666.patch
>
>
> Currently the fieldcache is not pluggable at all. It would be better if 
> everything used the docvalues apis.
> This would allow people to customize the implementation, extend the classes 
> with custom subclasses with additional stuff, etc etc.
> FieldCache can be accessed via the docvalues apis, using the FilterReader api.



--
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] (LUCENE-7008) TestSortingMergePolicy.testForceMergeNotNeeded fails

[Shai Erera (JIRA)]

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

Shai Erera updated LUCENE-7008:
---
Attachment: LUCENE-7008.patch

Patch fixes the test.

> TestSortingMergePolicy.testForceMergeNotNeeded fails
> 
>
> Key: LUCENE-7008
> URL: https://issues.apache.org/jira/browse/LUCENE-7008
> Project: Lucene - Core
>  Issue Type: Test
>Affects Versions: 5.5, Trunk
>Reporter: Christine Poerschke
> Attachments: LUCENE-7008.patch
>
>
> {{TestSortingMergePolicy.testForceMergeNotNeeded}} (recently added by 
> LUCENE-7006) regularly and reproducibly fails e.g.
> {code}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestSortingMergePolicy -Dtests.method=testForceMergeNotNeeded 
> -Dtests.seed=BAF97ED1D97DDEEE -Dtests.slow=true -Dtests.locale=nl-NL 
> -Dtests.timezone=CST6CDT -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
> {code}
> Stack Trace:
> {code}
> java.lang.AssertionError
> at 
> __randomizedtesting.SeedInfo.seed([BAF97ED1D97DDEEE:A6DA06CB422235FB]:0)
> at 
> org.apache.lucene.index.BaseMergePolicyTestCase$1.merge(BaseMergePolicyTestCase.java:44)
> at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1931)
> at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1764)
> at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1721)
> at 
> org.apache.lucene.index.BaseMergePolicyTestCase.testForceMergeNotNeeded(BaseMergePolicyTestCase.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at 
> 

[jira] [Created] (SOLR-8634) Math FunctionQuery improper data types

[Curtis Fehr (JIRA)]

Curtis Fehr created SOLR-8634:
-

 Summary: Math FunctionQuery improper data types
 Key: SOLR-8634
 URL: https://issues.apache.org/jira/browse/SOLR-8634
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.4.1, 5.4, 5.3.1, 5.3
Reporter: Curtis Fehr


When performing sum(), div(), mod() or other math functions on a 64 bit numeric 
field, the returned values are incorrect.  This is due to these functions being 
restricted to using floats.  It would make more sense for sum() and div() to be 
using doubles, and mod() to be using longs.

--the culprit
http://apaste.info/vJH

--in case the above link expires
http://svn.apache.org/viewvc/lucene/dev/tags/lucene_solr_5_3_2/solr/core/src/java/org/apache/solr/search/ValueSourceParser.java?revision=1726288=markup=file



--
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-8502) Improve Solr JDBC Driver to support SQL Clients like DBVisualizer

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8502:
--

The screen shot looks good! 

I'll play around some with DbVisualizer in the next couple of days and commit 
SOLR-8507.


> Improve Solr JDBC Driver to support SQL Clients like DBVisualizer
> -
>
> Key: SOLR-8502
> URL: https://issues.apache.org/jira/browse/SOLR-8502
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>  Labels: jdbc
> Fix For: Trunk
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> screenshot-4.png
>
>
> Currently when trying to connect to Solr with the JDBC driver with a SQL 
> client the driver must implement more methods and metadata to allow 
> connections. This JIRA is designed to act as an umbrella for the JDBC changes.
> An initial pass from a few months ago is here: 
> https://github.com/risdenk/lucene-solr/tree/expand-jdbc. This needs to be 
> broken up and create patches for the related sub tasks.



--
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-8507) Add information about database product name, product version, driver name, and driver version.

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8507:


Yea that sounds good to me. I can move the remaining subtasks (SOLR-8613, 
SOLR-8213, and SOLR-8521) from SOLR-8502 to SOLR-8125. 

> Add information about database product name, product version, driver name, 
> and driver version.
> --
>
> Key: SOLR-8507
> URL: https://issues.apache.org/jira/browse/SOLR-8507
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>Priority: Minor
> Attachments: SOLR-8507.patch, SOLR-8507.patch, SOLR-8507.patch, 
> SOLR-8507.patch
>
>
> DBVisualizer asks for information about database product name, product 
> version, driver name, and driver version. These should be implemented in 
> DatabaseMetaDataImpl.
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDatabaseProductName()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDatabaseProductVersion()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDriverName()
> 2016-01-07 13:30:10.814 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getDriverVersion()



--
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-8613) SolrJ JDBC - SQL queries with limit do not fail when a bad column is provided

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8613:
---
Issue Type: Bug  (was: Sub-task)
Parent: (was: SOLR-8502)

> SolrJ JDBC - SQL queries with limit do not fail when a bad column is provided
> -
>
> Key: SOLR-8613
> URL: https://issues.apache.org/jira/browse/SOLR-8613
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Fix For: Trunk
>
>
> This was found exporting SOLR-8602. Without a limit, the query fails with 
> unable to read the first tuple due to a bad column being provided. When using 
> a limit, there is no error and the column is returned as all nulls.



--
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-5730) make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector configurable in Solr

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-5730:
--

Let me try again... again, my apologies for not commenting much earlier before 
things got a bit complicated. Let me see if I have this straight:

1. There are three related tickets: SOLR-4654, SOLR-5730, SOLR-8621.
2. There are three key features of interest: UpgradeIndexMergePolicy, 
SortingMergePolicy , and EarlyTerminatingSortingCollector.
3. The first ticket is kind of the umbrella.
4. The second ticket is focused on the second and third features.
5. The third ticket is the foundation for all three features.
6. The third ticket has some user impact and delivers some additional minor 
benefits, but enabling those other three features is its true purpose.
7. SortingMergePolicy and EarlyTerminatingSortingCollector are really two sides 
of a single feature, the index side and the query side of (in my words) 
"pre-sorted indexing".

Now, I have only one remaining question area: Isn't the forceMerge method the 
only real benefit of UpgradeIndexMergePolicy? Is that purely for the Solr 
optimize option, or is there some intent to surface it for users some other way 
in Solr? Isn't it more of a one-time operation rather than something that 
should be in place for all merge operations? Or is it so cheap if not used that 
we should simply pre-configure it all the time?

> make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector 
> configurable in Solr
> --
>
> Key: SOLR-5730
> URL: https://issues.apache.org/jira/browse/SOLR-5730
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-5730-part1of2.patch, SOLR-5730-part1of2.patch, 
> SOLR-5730-part2of2.patch, SOLR-5730-part2of2.patch
>
>
> *Example configuration (solrconfig.xml) - corresponding to latest attached 
> patch:*
> {noformat}
> 
>   timestamp desc
> 
> {noformat}
> *Example configuration (solrconfig.xml) - corresponding to current 
> (work-in-progress master-solr-8621) SOLR-8621 efforts:*
> {noformat}
> -
> +
> +  TieredMergePolicyFactory
> +  timestamp desc
> +
> {noformat}
> *Example use (EarlyTerminatingSortingCollector):*
> {noformat}
> =timestamp+desc=true
> {noformat}



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

[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.7.0_80) - Build # 5458 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5458/
Java: 32bit/jdk1.7.0_80 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.MultiThreadedOCPTest.test

Error Message:
Mutual exclusion failed. Found more than one task running for the same 
collection

Stack Trace:
java.lang.AssertionError: Mutual exclusion failed. Found more than one task 
running for the same collection
at 
__randomizedtesting.SeedInfo.seed([BE9CDC6BDC295FB3:36C8E3B172D5324B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.testTaskExclusivity(MultiThreadedOCPTest.java:140)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.test(MultiThreadedOCPTest.java:59)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  

[jira] [Commented] (SOLR-8135) SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible failure

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-8135:
--

I can fix the test to wait longer after it issues a config change but that will 
mask a race condition that the SolrConfigHandler refreshconf thread attempts to 
refresh a core that is being shutdown down.

{code}
   [junit4]   2> 42606 INFO  (qtp1036148039-29) [n:127.0.0.1:58528_] 
o.a.s.c.SolrCore [gettingstarted_shard1_replica1]  CLOSING SolrCore 
org.apache.solr.core.SolrCore@53fda895
{code}

and then later in the log, you have: 

{code}
   [junit4]   2> 42629 INFO  (SolrConfigHandler-refreshconf) 
[n:127.0.0.1:58528_ c:gettingstarted s:shard1 r:core_node4 
x:gettingstarted_shard1_replica1] o.a.s.c.ConfigSetProperties Did not find 
ConfigSet properties, assuming default properties: Can't find resource 
'configsetprops.json' in classpath or '/configs/gettingstarted', 
cwd=/home/hossman/lucene/dev/solr/build/solr-core/test/J0
   [junit4]   2> 42629 INFO  (SolrConfigHandler-refreshconf) 
[n:127.0.0.1:58528_ c:gettingstarted s:shard1 r:core_node4 
x:gettingstarted_shard1_replica1] o.a.s.c.CoreContainer Reloading SolrCore 
'gettingstarted_shard1_replica1' using configuration from collection 
gettingstarted
   [junit4]   2> 42630 ERROR (SolrConfigHandler-refreshconf) 
[n:127.0.0.1:58528_ c:gettingstarted s:shard1 r:core_node4 
x:gettingstarted_shard1_replica1] o.a.s.h.SolrConfigHandler Unable to refresh 
conf
   [junit4]   2> org.apache.solr.common.SolrException: Unable to reload core 
[gettingstarted_shard1_replica1]
   [junit4]   2>at 
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:837)
   [junit4]   2>at 
org.apache.solr.core.SolrCore$11.run(SolrCore.java:2602)
   [junit4]   2>at 
org.apache.solr.handler.SolrConfigHandler$Command$1.run(SolrConfigHandler.java:212)
{code}

I see some checks for whether the core is closed, so maybe there's nothing we 
can do better to detect this race condition, but would appreciate if 
[~noble.paul] could take a closer look at the checks? If not, the only fix here 
is to wait longer for the config changes to take effect before issuing the 
delete.

> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible 
> failure
> --
>
> Key: SOLR-8135
> URL: https://issues.apache.org/jira/browse/SOLR-8135
> Project: Solr
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Hoss Man
> Attachments: SOLR-8135.failure.log, SOLR-8135.patch
>
>
> No idea what's going on here, noticed it while testing out an unrelated patch 
> -- seed reproduces against pristine trunk...
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=SolrCloudExampleTest 
> -Dtests.method=testLoadDocsIntoGettingStartedCollection 
> -Dtests.seed=59EA523FFF6CB60F -Dtests.slow=true -Dtests.locale=es_MX 
> -Dtests.timezone=Africa/Porto-Novo -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 49.5s | 
> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Delete action failed!
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([59EA523FFF6CB60F:4A896050CE030FA9]:0)
>[junit4]>  at 
> org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
>[junit4]>  at 
> org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
> {noformat}



--
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-8627) Retrieve position ranking in json facets

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8627:


For an API, perhaps adding bucketVals and bucketPos parameters?
{code}
type:field,
field:customer,
[...]
bucketVals:["customer10","customer345","customer72"],
bucketPos:true  // returns the position of the bucket in the full list of 
buckets
{code}

And in the response, each bucket could have a "pos" attribute if 
bucketPos==true (since bucketVals by itself can still be useful).

> Retrieve position ranking in json facets
> 
>
> Key: SOLR-8627
> URL: https://issues.apache.org/jira/browse/SOLR-8627
> Project: Solr
>  Issue Type: New Feature
>  Components: Facet Module
>Reporter: Pablo Anzorena
>
> It would be fantastic to have the position (in terms of a specific stat or 
> count) ranking in the json facets. Let's suppose we have the field "client" 
> of type string and we make a facet to see the top 10 (limit:10, offset:0), so 
> the first bucket will have the ranking 1, the second bucket will have the 
> ranking 2, and so on. Now we ask for the top 10 starting from 10 (limit:10, 
> offset:10) so the first bucket will have the ranking 11, the second one 
> ranking 12, and so on. Until now, there is no big deal, you just sum the 
> offset with the bucket position.
> But what happens if I want to know the ranking of a specific client (or a 
> list of them)? One possible way would be to ask for all clients (limit:-1), 
> but it will have performance issues on fields with big cardinality.
> So, I'm asking for an option that receives a list of terms and a stat, and 
> returns the list of terms with their respective position (or ranking) that 
> produce the query.



--
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-8627) Retrieve position ranking in json facets

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-8627:
---
Component/s: Facet Module

> Retrieve position ranking in json facets
> 
>
> Key: SOLR-8627
> URL: https://issues.apache.org/jira/browse/SOLR-8627
> Project: Solr
>  Issue Type: New Feature
>  Components: Facet Module
>Reporter: Pablo Anzorena
>
> It would be fantastic to have the position (in terms of a specific stat or 
> count) ranking in the json facets. Let's suppose we have the field "client" 
> of type string and we make a facet to see the top 10 (limit:10, offset:0), so 
> the first bucket will have the ranking 1, the second bucket will have the 
> ranking 2, and so on. Now we ask for the top 10 starting from 10 (limit:10, 
> offset:10) so the first bucket will have the ranking 11, the second one 
> ranking 12, and so on. Until now, there is no big deal, you just sum the 
> offset with the bucket position.
> But what happens if I want to know the ranking of a specific client (or a 
> list of them)? One possible way would be to ask for all clients (limit:-1), 
> but it will have performance issues on fields with big cardinality.
> So, I'm asking for an option that receives a list of terms and a stat, and 
> returns the list of terms with their respective position (or ranking) that 
> produce the query.



--
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-8308) Core gets inaccessible after RENAME operation with special characters

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8308:
---

Commit 2c0a66bfbc5937907d290b799e025d15c0ba098e in lucene-solr's branch 
refs/heads/master from [~erickerickson]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2c0a66b ]

Took out duplicate mention of SOLR-8308 (was only in trunk)


> Core gets inaccessible after RENAME operation with special characters
> -
>
> Key: SOLR-8308
> URL: https://issues.apache.org/jira/browse/SOLR-8308
> Project: Solr
>  Issue Type: Bug
>Reporter: Adam Johnson
>Assignee: Erick Erickson
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8308.patch, SOLR-8308.patch, SOLR-8308.patch, 
> SOLR-8308.patch
>
>
> You can rename a core using the following modified URL 
> https://SOLR:PORT/solr/admin/cores?wt=json=false=RENAME=test_app_shared2_replica2=%3Csvg+onload%3Dalert(1)%3E&_=1445468005152.
>  The core becomes inaccessible / unusable.  There should be more form 
> validation to the core name assignment



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

[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 922 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/922/

2 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test

Error Message:
Error from server at http://127.0.0.1:36914/a_yj/gx: collection already exists: 
halfdeletedcollection2

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:36914/a_yj/gx: collection already exists: 
halfdeletedcollection2
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:576)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1547)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1602)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:252)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:168)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-8308) Core gets inaccessible after RENAME operation with special characters

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8308:
---

Commit 7dcb07723cdd90066857bacac7d5e31eda22f8ce in lucene-solr's branch 
refs/heads/branch_5x from [~erickerickson]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7dcb077 ]

SOLR-8308: Core gets inaccessible after RENAME operation with special characters
(cherry picked from commit 70f8742)


> Core gets inaccessible after RENAME operation with special characters
> -
>
> Key: SOLR-8308
> URL: https://issues.apache.org/jira/browse/SOLR-8308
> Project: Solr
>  Issue Type: Bug
>Reporter: Adam Johnson
>Assignee: Erick Erickson
> Attachments: SOLR-8308.patch, SOLR-8308.patch, SOLR-8308.patch, 
> SOLR-8308.patch
>
>
> You can rename a core using the following modified URL 
> https://SOLR:PORT/solr/admin/cores?wt=json=false=RENAME=test_app_shared2_replica2=%3Csvg+onload%3Dalert(1)%3E&_=1445468005152.
>  The core becomes inaccessible / unusable.  There should be more form 
> validation to the core name assignment



--
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-8308) Core gets inaccessible after RENAME operation with special characters

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8308:
---

Commit 4de5f1d99d3ed36b2b09c147a5e4797caecc2ac8 in lucene-solr's branch 
refs/heads/branch_5x from [~erickerickson]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4de5f1d ]

SOLR-8308: Core gets inaccessible after RENAME operation with special characters
(cherry picked from commit 70f8742)


> Core gets inaccessible after RENAME operation with special characters
> -
>
> Key: SOLR-8308
> URL: https://issues.apache.org/jira/browse/SOLR-8308
> Project: Solr
>  Issue Type: Bug
>Reporter: Adam Johnson
>Assignee: Erick Erickson
> Attachments: SOLR-8308.patch, SOLR-8308.patch, SOLR-8308.patch, 
> SOLR-8308.patch
>
>
> You can rename a core using the following modified URL 
> https://SOLR:PORT/solr/admin/cores?wt=json=false=RENAME=test_app_shared2_replica2=%3Csvg+onload%3Dalert(1)%3E&_=1445468005152.
>  The core becomes inaccessible / unusable.  There should be more form 
> validation to the core name assignment



--
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] [Resolved] (SOLR-8308) Core gets inaccessible after RENAME operation with special characters

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-8308.
--
   Resolution: Fixed
Fix Version/s: Trunk
   5.5

OK, my first-ever Git fix, let me know what's wrong. 

Sorry for the gratuitous newline changes, I think I've fixed my IntelliJ to not 
do that any more, but this patch is small enough that I don't think they're 
worth fixing.

P.S. I already know about the double entry for this JIRA in CHANGES.txt, fixing 
momentarily.

> Core gets inaccessible after RENAME operation with special characters
> -
>
> Key: SOLR-8308
> URL: https://issues.apache.org/jira/browse/SOLR-8308
> Project: Solr
>  Issue Type: Bug
>Reporter: Adam Johnson
>Assignee: Erick Erickson
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8308.patch, SOLR-8308.patch, SOLR-8308.patch, 
> SOLR-8308.patch
>
>
> You can rename a core using the following modified URL 
> https://SOLR:PORT/solr/admin/cores?wt=json=false=RENAME=test_app_shared2_replica2=%3Csvg+onload%3Dalert(1)%3E&_=1445468005152.
>  The core becomes inaccessible / unusable.  There should be more form 
> validation to the core name assignment



--
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-8633) DistributedUpdateProcess.processCommit calls finish() - violates lifecycle, causes finish to be called twice (redundent code execution)

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-8633:
---
Attachment: SOLR-8633.patch

attaching a strawman patch that has asserts ensuring that {{finish()}} is never 
called more then once on either DUP or SolrCmdDistributor, and makes 
{{blockAndDoRetries()}} public so DUP can call it instead of {{finish()}}

all tests pass ... anyone see any problems with this? 

any reason why the previous code (where all the logic in DUP.finish() was 
getting executed twice when there was an explicit commit) was better/needed ?

> DistributedUpdateProcess.processCommit calls finish() - violates lifecycle, 
> causes finish to be called twice (redundent code execution)
> ---
>
> Key: SOLR-8633
> URL: https://issues.apache.org/jira/browse/SOLR-8633
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8633.patch
>
>
> trying to wrap my head around a weird bug in my experiements with SOLR-445, i 
> realized that {{DUP.processDelete}} has a direct call to {{finish()}}.
> This violates the normal lifecycle of an UpdateProcessor (finish is only 
> suppose to be called exactly once after processing any/all UpdateCommands) 
> and could potentially break any UpdateProcessors configured after DUP (or in 
> my case: processors configured _before_ DUP that expect to be in charge of 
> calling finish, and catching any resulting exceptions, as part of the normal 
> life cycle)
> Independent of how it impacts other update processors, this also means that:
> # all the logic in {{DUP.doFinish}} is getting executed twice -- which seems 
> kind of expensive/dangerous to me since there is leader initiated recovery 
> involved in this method
> # {{SolrCmdDistributor.finish()}} gets called twice, which means 
> {{StreamingSolrClients.shutdown()}} gets called twice, which means 
> {{ConcurrentUpdateSolrClient.close()}} gets called twice ... it seems like 
> we're just getting really lucky that (as configured by DUP) all of these 
> resources are still usable after being finished/shutdown/closed



--
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-8135) SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible failure

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-8135:
--

The other interesting thing to note is that the SolrConfigHandler does try to 
wait up to 30 seconds for agreement across all cores, but that does not mean 
the config has been applied on all cores, apparently. For instance, in the log 
you see:

{code}
   [junit4]   2> 41864 INFO  (qtp1735783147-155) [n:127.0.0.1:35628_ 
c:gettingstarted s:shard2 r:core_node1 x:gettingstarted_shard2_replica2] 
o.a.s.h.SolrConfigHandler Took 905.0ms to set the property overlay to be of 
version 0 for collection gettingstarted
{code}

But there is still config loading activity going on in the cores after this 
point, so that wait is somewhat misleading. I still think the fix here is to 
have the test wait longer before issuing the delete, but we should also revisit 
whether the SolrConfigHandler can do better at detecting a core is shutting 
down?

> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible 
> failure
> --
>
> Key: SOLR-8135
> URL: https://issues.apache.org/jira/browse/SOLR-8135
> Project: Solr
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Hoss Man
> Attachments: SOLR-8135.failure.log, SOLR-8135.patch
>
>
> No idea what's going on here, noticed it while testing out an unrelated patch 
> -- seed reproduces against pristine trunk...
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=SolrCloudExampleTest 
> -Dtests.method=testLoadDocsIntoGettingStartedCollection 
> -Dtests.seed=59EA523FFF6CB60F -Dtests.slow=true -Dtests.locale=es_MX 
> -Dtests.timezone=Africa/Porto-Novo -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 49.5s | 
> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Delete action failed!
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([59EA523FFF6CB60F:4A896050CE030FA9]:0)
>[junit4]>  at 
> org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
>[junit4]>  at 
> org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
> {noformat}



--
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-8135) SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible failure

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-8135:
--

Chatting with [~hossman_luc...@fucit.org], it seems like the SolrConfigHandler 
should be able to leverage the CloseHook support in SolrCore to be able to 
detect a core is being closed and stop its attempts at refreshing config.

Moreover, as I thought about the previous comment some more, I actually think 
the true bug here is the config handler returns before the config change has 
been applied (it seems from the log anyway) ... not sure why anyone would want 
a config update request to return to them before the change has been applied 
across the cluster? Seems hard for a client app to reason about whether a 
change is fully applied or not with the way things are w/o adding arbitrary 
waits, which would just be a bandaid in the SolrCloudExampleTest.

> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible 
> failure
> --
>
> Key: SOLR-8135
> URL: https://issues.apache.org/jira/browse/SOLR-8135
> Project: Solr
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Hoss Man
> Attachments: SOLR-8135.failure.log, SOLR-8135.patch
>
>
> No idea what's going on here, noticed it while testing out an unrelated patch 
> -- seed reproduces against pristine trunk...
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=SolrCloudExampleTest 
> -Dtests.method=testLoadDocsIntoGettingStartedCollection 
> -Dtests.seed=59EA523FFF6CB60F -Dtests.slow=true -Dtests.locale=es_MX 
> -Dtests.timezone=Africa/Porto-Novo -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 49.5s | 
> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Delete action failed!
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([59EA523FFF6CB60F:4A896050CE030FA9]:0)
>[junit4]>  at 
> org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
>[junit4]>  at 
> org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
> {noformat}



--
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-5730) make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector configurable in Solr

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-5730:
--

[~hossman], this issue is now on hold until we finish with SOLR-8621 (see 
[~cpoerschke] earlier comment).

[~jkrupan] the intention of SOLR-8621 and this issue is to allow users to 
define compound merge policies in {{solrconfig.xml}} with ease. Currently, it's 
impossible and if you want to use something like {{UpgradeIndexMergePolicy}}, 
you have to create your own MP class which will delegate internally to 
{{UpgradeIndexMP}}. For users who still want to define simple merge policies 
like {{TieredMergePolicy}}, the structure in the XML will not be much 
different. Instead of:

{code}

  42

{code}

They will need to specify

{code}

  42

{code}

The factory allows more advanced users to create whatever MP they want, rather 
easily. Also, with this change, we deprecate some settings that are now defined 
globally (like _mergeFactor_), and move them inside the 
{{}} section, where they belong.

Hope this clarifies it better.

> make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector 
> configurable in Solr
> --
>
> Key: SOLR-5730
> URL: https://issues.apache.org/jira/browse/SOLR-5730
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-5730-part1of2.patch, SOLR-5730-part1of2.patch, 
> SOLR-5730-part2of2.patch, SOLR-5730-part2of2.patch
>
>
> *Example configuration (solrconfig.xml) - corresponding to latest attached 
> patch:*
> {noformat}
> 
>   timestamp desc
> 
> {noformat}
> *Example configuration (solrconfig.xml) - corresponding to current 
> (work-in-progress master-solr-8621) SOLR-8621 efforts:*
> {noformat}
> -
> +
> +  TieredMergePolicyFactory
> +  timestamp desc
> +
> {noformat}
> *Example use (EarlyTerminatingSortingCollector):*
> {noformat}
> =timestamp+desc=true
> {noformat}



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

[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_72) - Build # 5591 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5591/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  org.apache.solr.client.solrj.impl.CloudSolrClientTest.test

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([A3EAEF58F3B36E12:2BBED0825D4F03EA]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.allTests(CloudSolrClientTest.java:273)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 

[jira] [Created] (LUCENE-7009) Add expectThrows utility to LuceneTestCase

[Ryan Ernst (JIRA)]

Ryan Ernst created LUCENE-7009:
--

 Summary: Add expectThrows utility to LuceneTestCase
 Key: LUCENE-7009
 URL: https://issues.apache.org/jira/browse/LUCENE-7009
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Ryan Ernst


In junit5, a neat assertion method is added which makes testing expected
failures a little more straightforward. The block of code that is
expected to throw is passed in with a lambda expression, and the caught
exception returned for inspection. The usage looks something like this:

{code}
IOException e = expectThrows(IOException.class, () -> {
throw new IOException("some io error");
});
// assert stuff here about the exception
{code}

We should add this to LuceneTestCase until junit5 is available.



--
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-7240) redirect / to /solr

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-7240:


hmm, I'm noticing that the "trunk" patch for this (and 5.3.1 release files) 
contains these lines:

{code}

+ 
+   
{code}

Is this part of the config working as expected? The [documentation for 
Jetty|http://www.eclipse.org/jetty/documentation/9.2.2.v20140723/reference-section.html#jetty-xml-ref]
 seems to say that this shoud be 

{code}

+ 
+   
{code}

If it's all working as expected then I guess the fact that Intellij flags an 
error here (duplicate id attributes) is not a big deal. However, if something 
is awry here maybe we need to open a new ticket to deal with it (since this one 
is already closed). I haven't (yet) run into a symptom, but this looks funny...

> redirect / to /solr 
> 
>
> Key: SOLR-7240
> URL: https://issues.apache.org/jira/browse/SOLR-7240
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Timothy Potter
>Priority: Blocker
> Fix For: 5.1
>
> Attachments: SOLR-7240.patch, SOLR-7240_start_jar_branch5x.patch, 
> SOLR-7240_trunk.patch
>
>
> Prior to Solr 5, we avoided doing anything fancy with our jetty configs 
> because we didn't want to overly customize "the example" beyond things that 
> involved loading the solr.war.
> That's not longer an issue, so we might as well plop in some jetty config 
> features to redirect / to /solr.



--
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-8510) Implement DatabaseMetaDataImpl.getSchemas()

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8510:
---

Commit 2419a3873ae0fc7d51bc80a10950743f45762679 in lucene-solr's branch 
refs/heads/master from jbernste
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2419a38 ]

SOLR-8510: Implement DatabaseMetaDataImpl.getSchemas()


> Implement DatabaseMetaDataImpl.getSchemas()
> ---
>
> Key: SOLR-8510
> URL: https://issues.apache.org/jira/browse/SOLR-8510
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8510.patch, SOLR-8510.patch
>
>
> DBVisualizer asks for information about schemas just like it does for 
> catalogs.
> 2016-01-07 13:58:49.974 FINE83 [Thread-423 - B.execute] Execute Command: 
> getSchemaNames
> 2016-01-07 13:58:49.975 FINE83 [Thread-423 - O.ￄﾔ] getSchema() for: abc
> 2016-01-07 13:58:49.975 FINE83 [pool-3-thread-12 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getSchemas()
> 2016-01-07 13:58:49.976 INFO83 [Thread-423 - L.ￄﾂ] Error getting schemas 
> for: abc
> java.lang.IllegalArgumentException: model passed to DefaultTableModelWrapper 
> cannot be null
>   at com.jidesoft.grid.TableModelWrapperImpl.(Unknown Source)
>   at com.jidesoft.grid.DefaultTableModelWrapper.(Unknown Source)
>   at com.jidesoft.grid.FilterableTableModel.(Unknown Source)
>   at com.jidesoft.grid.FilterableTreeTableModel.(Unknown Source)
>   at com.onseven.dbvis.K.B._.(Z:1161)
>   at com.onseven.dbvis.db.AbstractFacade.executeAndGet(Z:975)
>   at com.onseven.dbvis.db.AbstractFacade.getSchemaNames(Z:921)
>   at com.onseven.dbvis.L.L.ￄﾂ(Z:2202)
>   at com.onseven.dbvis.F.F$A.run(Z:3578)
>   at java.lang.Thread.run(Thread.java:745)



--
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-7240) redirect / to /solr

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-7240:
-

I assume both will work for compatibility reasons. But IntelliJ is right, you 
cannot have duplicate id values. Same we know from ant: {{}} pointing to {{}}.

> redirect / to /solr 
> 
>
> Key: SOLR-7240
> URL: https://issues.apache.org/jira/browse/SOLR-7240
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Timothy Potter
>Priority: Blocker
> Fix For: 5.1
>
> Attachments: SOLR-7240.patch, SOLR-7240_start_jar_branch5x.patch, 
> SOLR-7240_trunk.patch
>
>
> Prior to Solr 5, we avoided doing anything fancy with our jetty configs 
> because we didn't want to overly customize "the example" beyond things that 
> involved loading the solr.war.
> That's not longer an issue, so we might as well plop in some jetty config 
> features to redirect / to /solr.



--
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-8621) solrconfig.xml: deprecate/replace with

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8621:
---

bq. I've pushed my changes to the branch. You're welcome to review it.

Great, thanks! Will take a look, very likely not before Thursday though.

bq. I've one question about the branch you created. ...

Correct, I used {{git merge master}} to merge the latest (at the time) changes 
from master onto master-solr-8621 branch. _(This unexpectedly added updates to 
the tickets concerned which might be confusing, but that's a separate 
discussion for elsewhere.)_ My intention was for the master-solr-8621 history 
to reflect its detailed history. As far as 'committing to master' is concerned 
(at least with respect to this SOLR-8621 ticket here) my outlook currently is 
that all the master-solr-8621 history would be squashed 'at the end' and going 
back to 'master' there would be just a single commit. How does that sound (with 
respect to this ticket, not generally speaking)?

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-8633) DistributedUpdateProcess.processCommit calls finish() - violates lifecycle, causes finish to be called twice (redundent code execution)

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8633:
---

Healing. Happy to review soon (this week). 

> DistributedUpdateProcess.processCommit calls finish() - violates lifecycle, 
> causes finish to be called twice (redundent code execution)
> ---
>
> Key: SOLR-8633
> URL: https://issues.apache.org/jira/browse/SOLR-8633
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8633.patch
>
>
> trying to wrap my head around a weird bug in my experiements with SOLR-445, i 
> realized that {{DUP.processDelete}} has a direct call to {{finish()}}.
> This violates the normal lifecycle of an UpdateProcessor (finish is only 
> suppose to be called exactly once after processing any/all UpdateCommands) 
> and could potentially break any UpdateProcessors configured after DUP (or in 
> my case: processors configured _before_ DUP that expect to be in charge of 
> calling finish, and catching any resulting exceptions, as part of the normal 
> life cycle)
> Independent of how it impacts other update processors, this also means that:
> # all the logic in {{DUP.doFinish}} is getting executed twice -- which seems 
> kind of expensive/dangerous to me since there is leader initiated recovery 
> involved in this method
> # {{SolrCmdDistributor.finish()}} gets called twice, which means 
> {{StreamingSolrClients.shutdown()}} gets called twice, which means 
> {{ConcurrentUpdateSolrClient.close()}} gets called twice ... it seems like 
> we're just getting really lucky that (as configured by DUP) all of these 
> resources are still usable after being finished/shutdown/closed



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

[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.7.0_80) - Build # 15448 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15448/
Java: 32bit/jdk1.7.0_80 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
[index.20160202220838598, replication.properties, index.properties, 
index.20160202220900786] expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: [index.20160202220838598, replication.properties, 
index.properties, index.20160202220900786] expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([ACCA72832368C706:776172452640AEB5]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:820)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:787)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-8409) Complex q param in Streaming Expression results in a bad query

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-8409:
---

Yeah. Planning to commit tomorrow.

> Complex q param in Streaming Expression results in a bad query
> --
>
> Key: SOLR-8409
> URL: https://issues.apache.org/jira/browse/SOLR-8409
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
>  Labels: streaming, streaming_api
> Attachments: SOLR-8409.patch
>
>
> When providing an expression like 
> {code}
> stream=search(people, fl="id,first", sort="first asc", 
> q="presentTitles:\"chief executive officer\" AND age:[36 TO *]")
> {code}
> the following error is seen.
> {code}
> no field name specified in query and no default specified via 'df' param
> {code}
> I believe the issue is related to the \" (escaped quotes) and the spaces in 
> the q field. If I remove the spaces then the query returns results as 
> expected (though I've yet to validate if those results are accurate).
> This requires some investigation to get down to the root cause. I would like 
> to fix it before Solr 6 is cut.



--
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-8135) SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible failure

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-8135:
-
Attachment: (was: SOLR-8135.patch)

> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible 
> failure
> --
>
> Key: SOLR-8135
> URL: https://issues.apache.org/jira/browse/SOLR-8135
> Project: Solr
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Hoss Man
>Assignee: Noble Paul
> Attachments: SOLR-8135.failure.log, SOLR-8135.patch, SOLR-8135.patch
>
>
> No idea what's going on here, noticed it while testing out an unrelated patch 
> -- seed reproduces against pristine trunk...
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=SolrCloudExampleTest 
> -Dtests.method=testLoadDocsIntoGettingStartedCollection 
> -Dtests.seed=59EA523FFF6CB60F -Dtests.slow=true -Dtests.locale=es_MX 
> -Dtests.timezone=Africa/Porto-Novo -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 49.5s | 
> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Delete action failed!
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([59EA523FFF6CB60F:4A896050CE030FA9]:0)
>[junit4]>  at 
> org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
>[junit4]>  at 
> org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
> {noformat}



--
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-8135) SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible failure

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-8135:
-
Attachment: SOLR-8135.patch
SOLR-8135.patch

Diagnosis: This happens because of a race condition. We have multiple threads 
in parallel that invoked an unload/or reload. Race condition caused one of the 
threads to fail. In our code any failure in reload() would put this core as a 
permanent failure. It is not a failure , it is just that two threads 
simultaneously tried to perform the reload/unload. 

Solution: We need to handle this Exception differently . So I just created a 
new Exception called {{CoreIsClosedException}} this wouldn't add the core to 
permanently failed cores as {{IndexWriter has been closed}}. 

Follow Question up for others : If I'm trying to perform a reload and it fails 
, should we retry?

> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible 
> failure
> --
>
> Key: SOLR-8135
> URL: https://issues.apache.org/jira/browse/SOLR-8135
> Project: Solr
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Hoss Man
>Assignee: Noble Paul
> Attachments: SOLR-8135.failure.log, SOLR-8135.patch, SOLR-8135.patch
>
>
> No idea what's going on here, noticed it while testing out an unrelated patch 
> -- seed reproduces against pristine trunk...
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=SolrCloudExampleTest 
> -Dtests.method=testLoadDocsIntoGettingStartedCollection 
> -Dtests.seed=59EA523FFF6CB60F -Dtests.slow=true -Dtests.locale=es_MX 
> -Dtests.timezone=Africa/Porto-Novo -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 49.5s | 
> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Delete action failed!
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([59EA523FFF6CB60F:4A896050CE030FA9]:0)
>[junit4]>  at 
> org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
>[junit4]>  at 
> org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
> {noformat}



--
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-8621) solrconfig.xml: deprecate/replace with

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-8621:
--

bq. Will both the  and  elements will be deprecated 
as well

Yes

{quote}
IIUC, the motivation here is to permit any number of merge policies to be 
configured with the goal of supporting wrapping of merge policies. Okay, but 
what tells Solr which MP is the outer/default MP?
{quote}

The intention is to have a {{MergePolicyFactory}} which creates a 
{{MergePolicy}} instance. See [~cpoerschke] description above for the proposed 
structure in {{solrconfig.xml}}. If you want to construct your own MP, maybe 
it's a compound MP, you can simply define the class name of your factory, and 
then pass whatever arguments inside.

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



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

RE: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+102) - Build # 15740 - Still Failing!

[Uwe Schindler]

Oh oh,

same error also with SuperWords disabled!? But this time at another place (also 
happened here a while ago), maybe 2 different problems?

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


> -Original Message-
> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> Sent: Tuesday, February 02, 2016 9:07 AM
> To: dev@lucene.apache.org
> Subject: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+102) - Build #
> 15740 - Still Failing!
> Importance: Low
> 
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15740/
> Java: 32bit/jdk-9-ea+102 -server -XX:+UseG1GC -XX:-CompactStrings -XX:-
> UseSuperWord
> 
> All tests passed
> 
> Build Log:
> [...truncated 396 lines...]
>[junit4] JVM J2: stdout was not empty, see:
> /home/jenkins/workspace/Lucene-Solr-trunk-
> Linux/lucene/build/core/test/temp/junit4-J2-20160202_075817_353.sysout
>[junit4] >>> JVM J2 emitted unexpected output (verbatim) 
>[junit4] #
>[junit4] # A fatal error has been detected by the Java Runtime
> Environment:
>[junit4] #
>[junit4] #  SIGSEGV (0xb) at pc=0xf7249300, pid=31605, tid=31729
>[junit4] #
>[junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+102) (build 9-
> ea+102-2016-01-21-001243.javare.4316.nc)
>[junit4] # Java VM: Java HotSpot(TM) Server VM (9-ea+102-2016-01-21-
> 001243.javare.4316.nc, mixed mode, tiered, g1 gc, linux-x86)
>[junit4] # Problematic frame:
>[junit4] # V  [libjvm.so+0x9b3300]  Type::cmp(Type const*, Type
> const*)+0x10
>[junit4] #
>[junit4] # No core dump will be written. Core dumps have been disabled. To
> enable core dumping, try "ulimit -c unlimited" before starting Java again
>[junit4] #
>[junit4] # An error report file with more information is saved as:
>[junit4] # /home/jenkins/workspace/Lucene-Solr-trunk-
> Linux/lucene/build/core/test/J2/hs_err_pid31605.log
>[junit4] #
>[junit4] # Compiler replay data is saved as:
>[junit4] # /home/jenkins/workspace/Lucene-Solr-trunk-
> Linux/lucene/build/core/test/J2/replay_pid31605.log
>[junit4] #
>[junit4] # If you would like to submit a bug report, please visit:
>[junit4] #   http://bugreport.java.com/bugreport/crash.jsp
>[junit4] #
>[junit4] <<< JVM J2: EOF 
> 
> [...truncated 990 lines...]
>[junit4] ERROR: JVM J2 ended with an exception, command line:
> /home/jenkins/tools/java/32bit/jdk-9-ea+102/bin/java -server -
> XX:+UseG1GC -XX:-CompactStrings -XX:-UseSuperWord -
> XX:+HeapDumpOnOutOfMemoryError -
> XX:HeapDumpPath=/home/jenkins/workspace/Lucene-Solr-trunk-
> Linux/heapdumps -ea -esa -Dtests.prefix=tests -
> Dtests.seed=19C3334016770730 -Xmx512M -Dtests.iters= -
> Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -
> Dtests.postingsformat=random -Dtests.docvaluesformat=random -
> Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -
> Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=6.0.0 -
> Dtests.cleanthreads=perMethod -
> Djava.util.logging.config.file=/home/jenkins/workspace/Lucene-Solr-trunk-
> Linux/lucene/tools/junit4/logging.properties -Dtests.nightly=false -
> Dtests.weekly=false -Dtests.monster=false -Dtests.slow=true -
> Dtests.asserts=true -Dtests.multiplier=3 -DtempDir=./temp -
> Djava.io.tmpdir=./temp -
> Djunit4.tempDir=/home/jenkins/workspace/Lucene-Solr-trunk-
> Linux/lucene/build/core/test/temp -
> Dcommon.dir=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene -
> Dclover.db.dir=/home/jenkins/workspace/Lucene-Solr-trunk-
> Linux/lucene/build/clover/db -
> Djava.security.policy=/home/jenkins/workspace/Lucene-Solr-trunk-
> Linux/lucene/tools/junit4/tests.policy -Dtests.LUCENE_VERSION=6.0.0 -
> Djetty.testMode=1 -Djetty.insecurerandom=1 -
> Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -
> Djava.awt.headless=true -Djdk.map.althashing.threshold=0 -
> Djunit4.childvm.cwd=/home/jenkins/workspace/Lucene-Solr-trunk-
> Linux/lucene/build/core/test/J2 -Djunit4.childvm.id=2 -
> Djunit4.childvm.count=3 -Dtests.leaveTemporary=false -
> Dtests.filterstacks=true -Dtests.disableHdfs=true -
> Djava.security.manager=org.apache.lucene.util.TestSecurityManager -
> Dfile.encoding=ISO-8859-1 -classpath /home/jenkins/workspace/Lucene-
> Solr-trunk-
> Linux/lucene/build/codecs/classes/java:/home/jenkins/workspace/Lucene-
> Solr-trunk-Linux/lucene/build/test-
> framework/classes/java:/home/jenkins/workspace/Lucene-Solr-trunk-
> Linux/lucene/test-framework/lib/junit-
> 4.10.jar:/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-
> framework/lib/randomizedtesting-runner-
> 2.3.2.jar:/home/jenkins/workspace/Lucene-Solr-trunk-
> Linux/lucene/build/core/classes/java:/home/jenkins/workspace/Lucene-
> Solr-trunk-
> Linux/lucene/build/core/classes/test:/var/lib/jenkins/tools/hudson.tasks.An
> t_AntInstallation/ANT_1.8.2/lib/ant-
> launcher.jar:/var/lib/jenkins/.ant/lib/ivy-
> 

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 3056 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/3056/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  'X val changed' for path 'x' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{"wt":"json"},   
"context":{ "webapp":"", "path":"/test1", "httpMethod":"GET"},   
"class":"org.apache.solr.core.BlobStoreTestRequestHandler",   "x":"X val"}

Stack Trace:
java.lang.AssertionError: Could not get expected value  'X val changed' for 
path 'x' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"",
"path":"/test1",
"httpMethod":"GET"},
  "class":"org.apache.solr.core.BlobStoreTestRequestHandler",
  "x":"X val"}
at 
__randomizedtesting.SeedInfo.seed([82A7D91C27B20DC1:5AEAF44BD06FA861]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:458)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:257)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-7281) Add an overseer action to publish an entire node as 'down'

[Stephan Lagraulet (JIRA)]

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

Stephan Lagraulet commented on SOLR-7281:
-

Can you please remove Fix version 5.2 ?

> Add an overseer action to publish an entire node as 'down'
> --
>
> Key: SOLR-7281
> URL: https://issues.apache.org/jira/browse/SOLR-7281
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Mark Miller
> Fix For: 5.2, Trunk
>
> Attachments: SOLR-7281.patch
>
>
> A node restart currently iterates through each core and publishes an item to 
> the Overseer queue to mark that core as 'down'. This is inefficient if each 
> node has many cores and causes overseer to be overwhelmed with requests. We 
> can publish a single 'down' status for the entire node and have the overseer 
> do the rest.



--
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-7281) Add an overseer action to publish an entire node as 'down'

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-7281:

Fix Version/s: (was: 5.2)
   5.5

> Add an overseer action to publish an entire node as 'down'
> --
>
> Key: SOLR-7281
> URL: https://issues.apache.org/jira/browse/SOLR-7281
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Mark Miller
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-7281.patch
>
>
> A node restart currently iterates through each core and publishes an item to 
> the Overseer queue to mark that core as 'down'. This is inefficient if each 
> node has many cores and causes overseer to be overwhelmed with requests. We 
> can publish a single 'down' status for the entire node and have the overseer 
> do the rest.



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

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+102) - Build # 15740 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15740/
Java: 32bit/jdk-9-ea+102 -server -XX:+UseG1GC -XX:-CompactStrings 
-XX:-UseSuperWord

All tests passed

Build Log:
[...truncated 396 lines...]
   [junit4] JVM J2: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp/junit4-J2-20160202_075817_353.sysout
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  SIGSEGV (0xb) at pc=0xf7249300, pid=31605, tid=31729
   [junit4] #
   [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+102) (build 
9-ea+102-2016-01-21-001243.javare.4316.nc)
   [junit4] # Java VM: Java HotSpot(TM) Server VM 
(9-ea+102-2016-01-21-001243.javare.4316.nc, mixed mode, tiered, g1 gc, 
linux-x86)
   [junit4] # Problematic frame:
   [junit4] # V  [libjvm.so+0x9b3300]  Type::cmp(Type const*, Type const*)+0x10
   [junit4] #
   [junit4] # No core dump will be written. Core dumps have been disabled. To 
enable core dumping, try "ulimit -c unlimited" before starting Java again
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/J2/hs_err_pid31605.log
   [junit4] #
   [junit4] # Compiler replay data is saved as:
   [junit4] # 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/J2/replay_pid31605.log
   [junit4] #
   [junit4] # If you would like to submit a bug report, please visit:
   [junit4] #   http://bugreport.java.com/bugreport/crash.jsp
   [junit4] #
   [junit4] <<< JVM J2: EOF 

[...truncated 990 lines...]
   [junit4] ERROR: JVM J2 ended with an exception, command line: 
/home/jenkins/tools/java/32bit/jdk-9-ea+102/bin/java -server -XX:+UseG1GC 
-XX:-CompactStrings -XX:-UseSuperWord -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/heapdumps -ea 
-esa -Dtests.prefix=tests -Dtests.seed=19C3334016770730 -Xmx512M -Dtests.iters= 
-Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
-Dtests.postingsformat=random -Dtests.docvaluesformat=random 
-Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random 
-Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=6.0.0 
-Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=3 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Djunit4.tempDir=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp
 -Dcommon.dir=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene 
-Dclover.db.dir=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/clover/db
 
-Djava.security.policy=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/junit4/tests.policy
 -Dtests.LUCENE_VERSION=6.0.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Djunit4.childvm.cwd=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/J2
 -Djunit4.childvm.id=2 -Djunit4.childvm.count=3 -Dtests.leaveTemporary=false 
-Dtests.filterstacks=true -Dtests.disableHdfs=true 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dfile.encoding=ISO-8859-1 -classpath 

[jira] [Commented] (SOLR-8621) solrconfig.xml: deprecate/replace with

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-8621:
--

[~cpoerschke] about the commit, I have few comments:

* {{MergePolicyFactory}}, IMO, should belong to Solr. I don't see it being used 
by Lucene users, as they already construct {{IndexWriterConfig}} which takes a 
{{MergePolicy}} instance. The factory, again IMO, is useful in Solr-land, 
because Solr is configured from a file and therefore being able to construct an 
MP from a set of properties will be useful to Solr users.

* I don't fully get the purpose of {{MergePolicyFactoryHelper}}. Did you create 
that abstraction so we can use it in Solr? If we move MPF to Solr, I think we 
can get rid of it? Its only purpose as I can tell is to create an instance of 
an MP, but I thought that's what the factory will do?

* {{SimpleMergePolicyFactory}} is what I had in mind for the simple MPs. I 
wonder if we took the actual MPs class name in the properties, we wouldn't need 
{{TieredMPF}}, and will also simply support {{LogMP}}. What do you think? The 
XML element would look like:

{code}

  solr.TieredMergePolicy
  ...

{code}

What do you think?

* Is it OK if I make some changes to the code and push to the branch, or are 
you actively working on it?

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-5730) make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector configurable in Solr

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-5730:
--
Description: 
*Example configuration (solrconfig.xml) - corresponding to latest attached 
patch:*
{noformat}

  timestamp desc

{noformat}

*Example configuration (solrconfig.xml) - corresponding to current 
(work-in-progress master-solr-8621) SOLR-8621 efforts:*
{noformat}
-
+
+  TieredMergePolicyFactory
+  timestamp desc
+
{noformat}

*Example use (EarlyTerminatingSortingCollector):*
{noformat}
=timestamp+desc=true
{noformat}

  was:
*Example configuration (solrconfig.xml) - corresponding to latest attached 
patch:*
{noformat}

  timestamp desc

{noformat}

*Alternative Example configuration (solrconfig.xml) - corresponding to current 
(work-in-progress master-solr-8621) SOLR-8621 efforts:*
{noformat}
-
+
+  TieredMergePolicyFactory
+  timestamp desc
+
{noformat}

*Example use (EarlyTerminatingSortingCollector):*
{noformat}
=timestamp+desc=true
{noformat}


> make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector 
> configurable in Solr
> --
>
> Key: SOLR-5730
> URL: https://issues.apache.org/jira/browse/SOLR-5730
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-5730-part1of2.patch, SOLR-5730-part1of2.patch, 
> SOLR-5730-part2of2.patch, SOLR-5730-part2of2.patch
>
>
> *Example configuration (solrconfig.xml) - corresponding to latest attached 
> patch:*
> {noformat}
> 
>   timestamp desc
> 
> {noformat}
> *Example configuration (solrconfig.xml) - corresponding to current 
> (work-in-progress master-solr-8621) SOLR-8621 efforts:*
> {noformat}
> -
> +
> +  TieredMergePolicyFactory
> +  timestamp desc
> +
> {noformat}
> *Example use (EarlyTerminatingSortingCollector):*
> {noformat}
> =timestamp+desc=true
> {noformat}



--
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-8614) Add simple SolrClient.setUseXmlFormat

[Shashank Tyagi (JIRA)]

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

Shashank Tyagi commented on SOLR-8614:
--

Even though  if developer sets communication in SolrClient still there is 
chance to that calling code can send requestwriter in request which might be 
not necessarily appropriate according to format.

> Add simple SolrClient.setUseXmlFormat
> -
>
> Key: SOLR-8614
> URL: https://issues.apache.org/jira/browse/SOLR-8614
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Reporter: David Smiley
>  Labels: newdev
>
> It'd be nice if there was a SolrClient one-liner to set all communication 
> (req & rsp) to be XML or binary as a toggle, without having to know which 
> classes to the parsing/writing as that's really an implementation/internal 
> detail. It's nice to make such a flag configurable in the client's software 
> to ease upgrades.



--
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-5730) make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector configurable in Solr

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-5730:
--
Description: 
*Example configuration (solrconfig.xml) - corresponding to latest attached 
patch:*
{noformat}

  timestamp desc

{noformat}

*Alternative Example configuration (solrconfig.xml) - corresponding to 
(work-in-progress) SOLR-8621 efforts:*
{noformat}
-
+
+  TieredMergePolicyFactory
+  42
+  timestamp desc
+
{noformat}

*Example use (EarlyTerminatingSortingCollector):*
{noformat}
=timestamp+desc=true
{noformat}

  was:
*Example configuration (solrconfig.xml):*
{noformat}

  timestamp desc

{noformat}

*Example use (EarlyTerminatingSortingCollector):*
{noformat}
=timestamp+desc=true
{noformat}


> make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector 
> configurable in Solr
> --
>
> Key: SOLR-5730
> URL: https://issues.apache.org/jira/browse/SOLR-5730
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-5730-part1of2.patch, SOLR-5730-part1of2.patch, 
> SOLR-5730-part2of2.patch, SOLR-5730-part2of2.patch
>
>
> *Example configuration (solrconfig.xml) - corresponding to latest attached 
> patch:*
> {noformat}
> 
>   timestamp desc
> 
> {noformat}
> *Alternative Example configuration (solrconfig.xml) - corresponding to 
> (work-in-progress) SOLR-8621 efforts:*
> {noformat}
> -
> +
> +  TieredMergePolicyFactory
> +  42
> +  timestamp desc
> +
> {noformat}
> *Example use (EarlyTerminatingSortingCollector):*
> {noformat}
> =timestamp+desc=true
> {noformat}



--
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-5730) make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector configurable in Solr

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-5730:
--
Description: 
*Example configuration (solrconfig.xml) - corresponding to latest attached 
patch:*
{noformat}

  timestamp desc

{noformat}

*Alternative Example configuration (solrconfig.xml) - corresponding to current 
(work-in-progress master-solr-8621) SOLR-8621 efforts:*
{noformat}
-
+
+  TieredMergePolicyFactory
+  timestamp desc
+
{noformat}

*Example use (EarlyTerminatingSortingCollector):*
{noformat}
=timestamp+desc=true
{noformat}

  was:
*Example configuration (solrconfig.xml) - corresponding to latest attached 
patch:*
{noformat}

  timestamp desc

{noformat}

*Alternative Example configuration (solrconfig.xml) - corresponding to 
(work-in-progress) SOLR-8621 efforts:*
{noformat}
-
+
+  TieredMergePolicyFactory
+  42
+  timestamp desc
+
{noformat}

*Example use (EarlyTerminatingSortingCollector):*
{noformat}
=timestamp+desc=true
{noformat}


> make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector 
> configurable in Solr
> --
>
> Key: SOLR-5730
> URL: https://issues.apache.org/jira/browse/SOLR-5730
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-5730-part1of2.patch, SOLR-5730-part1of2.patch, 
> SOLR-5730-part2of2.patch, SOLR-5730-part2of2.patch
>
>
> *Example configuration (solrconfig.xml) - corresponding to latest attached 
> patch:*
> {noformat}
> 
>   timestamp desc
> 
> {noformat}
> *Alternative Example configuration (solrconfig.xml) - corresponding to 
> current (work-in-progress master-solr-8621) SOLR-8621 efforts:*
> {noformat}
> -
> +
> +  TieredMergePolicyFactory
> +  timestamp desc
> +
> {noformat}
> *Example use (EarlyTerminatingSortingCollector):*
> {noformat}
> =timestamp+desc=true
> {noformat}



--
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-5730) make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector configurable in Solr

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-5730:
---

[~jkrupan] - it's never too late to join the party here :-) I've just updated 
the summary to reflect the latest patch state (though exact SOLR-8621 details 
are still a work-in-progress). Hope that clarifies things. Thanks for your 
input.

> make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector 
> configurable in Solr
> --
>
> Key: SOLR-5730
> URL: https://issues.apache.org/jira/browse/SOLR-5730
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-5730-part1of2.patch, SOLR-5730-part1of2.patch, 
> SOLR-5730-part2of2.patch, SOLR-5730-part2of2.patch
>
>
> *Example configuration (solrconfig.xml) - corresponding to latest attached 
> patch:*
> {noformat}
> 
>   timestamp desc
> 
> {noformat}
> *Alternative Example configuration (solrconfig.xml) - corresponding to 
> current (work-in-progress master-solr-8621) SOLR-8621 efforts:*
> {noformat}
> -
> +
> +  TieredMergePolicyFactory
> +  timestamp desc
> +
> {noformat}
> *Example use (EarlyTerminatingSortingCollector):*
> {noformat}
> =timestamp+desc=true
> {noformat}



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

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+102) - Build # 15745 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15745/
Java: 32bit/jdk-9-ea+102 -client -XX:+UseParallelGC -XX:-CompactStrings 
-XX:-UseSuperWord

No tests ran.

Build Log:
[...truncated 211 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp/junit4-J1-20160202_144927_208.syserr
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp/junit4-J0-20160202_144927_208.syserr
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp/junit4-J2-20160202_144927_208.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] Unrecognized VM option 'UseSuperWord'
   [junit4] Error: Could not create the Java Virtual Machine.
   [junit4] Error: A fatal exception has occurred. Program will exit.
   [junit4] <<< JVM J2: EOF 

[...truncated 11 lines...]
   [junit4] ERROR: JVM J0 ended with an exception, command line: 
/home/jenkins/tools/java/32bit/jdk-9-ea+102/bin/java -client -XX:+UseParallelGC 
-XX:-CompactStrings -XX:-UseSuperWord -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/heapdumps -ea 
-esa -Dtests.prefix=tests -Dtests.seed=78C6761B51D8721F -Xmx512M -Dtests.iters= 
-Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
-Dtests.postingsformat=random -Dtests.docvaluesformat=random 
-Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random 
-Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=6.0.0 
-Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=3 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Djunit4.tempDir=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp
 -Dcommon.dir=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene 
-Dclover.db.dir=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/clover/db
 
-Djava.security.policy=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/junit4/tests.policy
 -Dtests.LUCENE_VERSION=6.0.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Djunit4.childvm.cwd=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/J0
 -Djunit4.childvm.id=0 -Djunit4.childvm.count=3 -Dtests.leaveTemporary=false 
-Dtests.filterstacks=true -Dtests.disableHdfs=true 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dfile.encoding=ISO-8859-1 -classpath 

Re: More Managed Filters?

[Jan Høydahl]

Good reminder :)

Looking at the code, the ones that are configured from simple set of words (one 
per line) like StopFilter are fairly easy to implement.
So perhaps start with those. You would first check JIRA if an issue is already 
filed for the filter you want, and if not, file a new feature request for e.g. 
ManagedKeepWordFilterFactory.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 2. feb. 2016 kl. 13.22 skrev Markus Kalkbrenner 
> :
> 
> Hi,
> 
> my name is Markus Kalkbrenner and I’m the maintainer of the 
> apachesolr_multilingual module for drupal: 
> https://www.drupal.org/project/apachesolr_multilingual
> I’m also a co-maintainer of the apachesolr and search_api_solr modules.
> 
> For drupal 8 we leverage the managed schema to be able to dynamically add or 
> modify language specific field types using solr’s REST API.
> It’s a big improvement that this way a drupal administrator is able to fine 
> tune the search within the drupal cms itself.
> 
> In this context we already use the ManagedStopFilter and ManagedSynonymFilter 
> to manage the word lists within drupal.
> 
> It would be great if we could use the similar approach for other word lists 
> as well.
> Unfortunately there’re not yet any corresponding solutions for other filters 
> we use like DictionaryCompoundWordTokenFilter, the protected words of 
> SnowballPorterFilter or the text files for MappingCharFilter.
> 
> Even if we don’t use these filters at the moment, the same will be true for 
> any other filter that uses word lists like CommonGramsFilter, KeepWordFilter, 
> SuggestStopFilter, TypeTokenFilter, and WordDelimiterFilter.
> 
> Are there any plans to extend the approach of managed word lists to cover the 
> other filters as well?
> 
> Regards,
> Markus
> 
> 
> 
> -
> 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

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_72) - Build # 15741 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15741/
Java: 32bit/jdk1.8.0_72 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.lucene.index.TestSortingMergePolicy.testForceMergeNotNeeded

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([BE0A4F0968365D58:A2293713F369B64D]:0)
at 
org.apache.lucene.index.BaseMergePolicyTestCase$1.merge(BaseMergePolicyTestCase.java:44)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1917)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1750)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1707)
at 
org.apache.lucene.index.BaseMergePolicyTestCase.testForceMergeNotNeeded(BaseMergePolicyTestCase.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 7459 lines...]
   [junit4] Suite: org.apache.lucene.index.TestSortingMergePolicy
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestSortingMergePolicy -Dtests.method=testForceMergeNotNeeded 
-Dtests.seed=BE0A4F0968365D58 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=et-EE -Dtests.timezone=SystemV/PST8 -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] FAILURE 1.52s J0 | 

[JENKINS] Lucene-Solr-trunk-Solaris (64bit/jdk1.8.0) - Build # 373 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/373/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.lucene.index.TestSortingMergePolicy.testForceMergeNotNeeded

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([42D1D0E1D1322EFF:5EF2A8FB4A6DC5EA]:0)
at 
org.apache.lucene.index.BaseMergePolicyTestCase$1.merge(BaseMergePolicyTestCase.java:44)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1917)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1750)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1707)
at 
org.apache.lucene.index.BaseMergePolicyTestCase.testForceMergeNotNeeded(BaseMergePolicyTestCase.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 7341 lines...]
   [junit4] Suite: org.apache.lucene.index.TestSortingMergePolicy
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestSortingMergePolicy -Dtests.method=testForceMergeNotNeeded 
-Dtests.seed=42D1D0E1D1322EFF -Dtests.slow=true -Dtests.locale=es-PA 
-Dtests.timezone=Asia/Jayapura -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] FAILURE 0.60s J0 | 

[GitHub] lucene-solr pull request:

[GeReinhart]

Github user GeReinhart commented on the pull request:


https://github.com/apache/lucene-solr/commit/c397fe723462cfe4069304fe3b3bcea648217060#commitcomment-15823558
  
In lucene/core/src/java/org/apache/lucene/util/QueryBuilder.java:
In lucene/core/src/java/org/apache/lucene/util/QueryBuilder.java on line 
423:
Hi, we are migrating from Solr4 to Solr5. We were overriding this method to 
customize the generated query. Do you know have we can do now ?
Thanks 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[JENKINS] Lucene-Solr-5.x-Solaris (multiarch/jdk1.7.0) - Build # 365 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Solaris/365/
Java: multiarch/jdk1.7.0 -d32 -client -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
timed out waiting for collection1 startAt time to exceed: Tue Feb 02 21:20:58 
AEDT 2016

Stack Trace:
java.lang.AssertionError: timed out waiting for collection1 startAt time to 
exceed: Tue Feb 02 21:20:58 AEDT 2016
at 
__randomizedtesting.SeedInfo.seed([E184581BA795D4C3:3A2F58DDA2BDBD70]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.handler.TestReplicationHandler.watchCoreStartAt(TestReplicationHandler.java:1419)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:771)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11326 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_72) - Build # 15742 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15742/
Java: 32bit/jdk1.8.0_72 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.lucene.index.TestSortingMergePolicy.testForceMergeNotNeeded

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([83C8D59CD8D0BC8F:9FEBAD86438F579A]:0)
at 
org.apache.lucene.index.BaseMergePolicyTestCase$1.merge(BaseMergePolicyTestCase.java:44)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1917)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1750)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1707)
at 
org.apache.lucene.index.BaseMergePolicyTestCase.testForceMergeNotNeeded(BaseMergePolicyTestCase.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 28 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at 

[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 3001 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/3001/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.lucene.index.TestSortingMergePolicy.testForceMergeNotNeeded

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([CB8A5B0C5F36ADC1:D7A92316C46946D4]:0)
at 
org.apache.lucene.index.BaseMergePolicyTestCase$1.merge(BaseMergePolicyTestCase.java:44)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1931)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1764)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1721)
at 
org.apache.lucene.index.BaseMergePolicyTestCase.testForceMergeNotNeeded(BaseMergePolicyTestCase.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 7677 lines...]
   [junit4] Suite: org.apache.lucene.index.TestSortingMergePolicy
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestSortingMergePolicy -Dtests.method=testForceMergeNotNeeded 
-Dtests.seed=CB8A5B0C5F36ADC1 -Dtests.slow=true -Dtests.locale=sl-SI 
-Dtests.timezone=Brazil/West -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
   [junit4] FAILURE 0.57s J0 | TestSortingMergePolicy.testForceMergeNotNeeded 

[jira] [Commented] (SOLR-8621) solrconfig.xml: deprecate/replace with

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8621:
---

[~shaie] - thanks for your comments.

* Yes, the purpose of {{MergePolicyFactoryHelper}} was to allow the {{lucene}} 
factory to use the method currently used by {{solr}} to create new instances 
but if the factories belonged to Solr instead of Lucene then no helper would be 
needed.
* {{SimpleMergePolicyFactory}} with a {{class}} property - yes, that sounds 
good to me.
* master-solr-8621 just updated to merge in LUCENE-7005 and LUCENE-7006 from 
master. I've got one more push to the branch in the next hour or so but then 
don't expect to be working on it until Thursday at the earliest, though hoping 
take a look at the LUCENE-7006 TestSortingMergePolicy test failure at some 
point.

> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



--
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-8600) add & use ReRankQParserPlugin parameter [default] constants

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8600:
---

Commit 8e27c14aeda817df4e6a6394595104a47f6f8fac in lucene-solr's branch 
refs/heads/master-solr-8621 from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8e27c14 ]

SOLR-8600: add & use ReRankQParserPlugin parameter [default] constants, changed 
ReRankQuery.toString to use StringBuilder.


> add & use ReRankQParserPlugin parameter [default] constants
> ---
>
> Key: SOLR-8600
> URL: https://issues.apache.org/jira/browse/SOLR-8600
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8600.patch, SOLR-8600.patch
>
>
> * add & use {{RERANK_(QUERY|(DOCS|WEIGHT)\[_DEFAULT\])}} constants
> * add {{TestReRankQParserPlugin.testReRankQParserPluginConstants()}}
> * also: changed {{ReRankQuery.toString}} to use {{StringBuilder}}



--
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-8607) The Schema API refuses to add new fields that match existing dynamic fields

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8607:
---

Commit 064c0ac00fed662183c4cb117f6aeb6d0f9fe1a1 in lucene-solr's branch 
refs/heads/master-solr-8621 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=064c0ac ]

SOLR-8607: The Schema API refuses to add new fields that match existing dynamic 
fields


> The Schema API refuses to add new fields that match existing dynamic fields
> ---
>
> Key: SOLR-8607
> URL: https://issues.apache.org/jira/browse/SOLR-8607
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.3.1
>Reporter: kiran
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8607.patch, SOLR-8607.patch
>
>
> If the all catch dynamic field '*' is present in a managed schema collection, 
> then any field creation requests through Schema API return the 
> confusing/weird error "Field $\{FIELD_NAME\} already exists".
> *Schema of a test collection*: 
> {code}
> curl -X GET http://localhost:8983/solr/testSQLQueries-eventsim/schema
> {
>   "responseHeader":{
> "status":0,
> "QTime":0},
>   "schema":{
> "name":"example",
> "version":1.5,
> "uniqueKey":"id",
> "fieldTypes":[{
> "name":"boolean",
> "class":"solr.BoolField",
> "sortMissingLast":true},
>   {
> "name":"double",
> "class":"solr.TrieDoubleField",
> "positionIncrementGap":"0",
> "precisionStep":"0"},
>   {
> "name":"float",
> "class":"solr.TrieFloatField",
> "positionIncrementGap":"0",
> "precisionStep":"0"},
>   {
> "name":"int",
> "class":"solr.TrieIntField",
> "positionIncrementGap":"0",
> "precisionStep":"0"},
>   {
> "name":"long",
> "class":"solr.TrieLongField",
> "precisionStep":"6"},
>   {
> "name":"string",
> "class":"solr.StrField",
> "sortMissingLast":true},
>   {
> "name":"tdate",
> "class":"solr.TrieDateField",
> "positionIncrementGap":"0",
> "precisionStep":"6"}],
> "fields":[{
> "name":"_root_",
> "type":"string",
> "indexed":true,
> "stored":false},
>   {
> "name":"_version_",
> "type":"long",
> "indexed":true,
> "stored":true},
>   {
> "name":"id",
> "type":"string",
> "indexed":true,
> "required":true,
> "stored":true}],
> "dynamicFields":[{
> "name":"*_tdt",
> "type":"tdate",
> "indexed":true,
> "stored":true},
>   {
> "name":"*_txt",
> "type":"string",
> "multiValued":true,
> "indexed":true,
> "stored":true},
>   {
> "name":"*_ss",
> "type":"string",
> "multiValued":true,
> "indexed":true,
> "stored":true},
>   {
> "name":"*_ii",
> "type":"int",
> "multiValued":true,
> "indexed":true,
> "stored":true},
>   {
> "name":"*_ls",
> "type":"long",
> "multiValued":true,
> "indexed":true,
> "stored":true},
>   {
> "name":"*_i",
> "type":"int",
> "indexed":true,
> "stored":true},
>   {
> "name":"*_s",
> "type":"string",
> "indexed":true,
> "stored":true},
>   {
> "name":"*_l",
> "type":"long",
> "indexed":true,
> "stored":true},
>   {
> "name":"*_b",
> "type":"boolean",
> "indexed":true,
> "stored":true},
>   {
> "name":"*_f",
> "type":"float",
> "indexed":true,
> "stored":true},
>   {
> "name":"*_d",
> "type":"double",
> "indexed":true,
> "stored":true},
>   {
> "name":"*",
> "type":"string",
> "indexed":true,
> "stored":true}],
> "copyFields":[]}}
> {code}
> *Create new field 'userId' using Schema API*
> {code}
> curl -X POST -H "Content-type:application/json" --data-binary '{"add-field": 
> {"name":"userId","type":"string","indexed":"true","stored":"true"}}' 
> http://localhost:8983/solr/testSQLQueries-eventsim/schema
> {
>   "responseHeader":{
> "status":0,
> "QTime":6},
>   "errors":[{
>   "add-field":{
> "name":"userId",
> "type":"string",
> "indexed":"true",
> "stored":"true"},
>   "errorMessages":["Field 'userId' already exists.\n"]}]}
> {code}
> The field 'userId' 

[jira] [Commented] (LUCENE-7005) TieredMergePolicy tweaks (>= vs. >, @see get vs. set)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15127986#comment-15127986
 ] 

ASF subversion and git services commented on LUCENE-7005:
-

Commit fce97a6ca6e14b3d0216957cee1621327c452dfc in lucene-solr's branch 
refs/heads/master-solr-8621 from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fce97a6 ]

LUCENE-7005: TieredMergePolicy tweaks (>= vs. >, @see get vs. set)


> TieredMergePolicy tweaks (>= vs. >, @see get vs. set)
> -
>
> Key: LUCENE-7005
> URL: https://issues.apache.org/jira/browse/LUCENE-7005
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: LUCENE-7005.patch
>
>
> {code}
> -   * @see #getMaxMergedSegmentMB */
> +   * @see #setMaxMergedSegmentMB */
>public double getMaxMergedSegmentMB() {
> {code}
> and
> {code}
>public TieredMergePolicy setFloorSegmentMB(double v) {
>  if (v <= 0.0) {
> -  throw new IllegalArgumentException("floorSegmentMB must be >= 0.0 (got 
> " + v + ")");
> +  throw new IllegalArgumentException("floorSegmentMB must be > 0.0 (got 
> " + v + ")");
> {code}



--
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-8625) SQL: Wrong error msg if stmt param is missing

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8625:
---

Commit c136bd7dc737096843ff538e172762026b895f5b in lucene-solr's branch 
refs/heads/master-solr-8621 from jbernste
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c136bd7 ]

SOLR-8625: SQL: Wrong error msg if stmt param is missing


> SQL: Wrong error msg if stmt param is missing
> -
>
> Key: SOLR-8625
> URL: https://issues.apache.org/jira/browse/SOLR-8625
> Project: Solr
>  Issue Type: Bug
>  Components: Parallell SQL
>Affects Versions: Trunk
>Reporter: Jan Høydahl
> Fix For: 6.0
>
>
> If you call {{/sql?}} without {{stmt}}, the following error msg is printed:
> {code}
> "EXCEPTION": "sql parameter cannot be null"
> {code}



--
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] (LUCENE-7006) increase BaseMergePolicyTestCase use

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15127987#comment-15127987
 ] 

ASF subversion and git services commented on LUCENE-7006:
-

Commit ce0b931da890bb62448ae11ed5f9c0cb41017ede in lucene-solr's branch 
refs/heads/master-solr-8621 from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ce0b931 ]

LUCENE-7006: increase BaseMergePolicyTestCase use (TestNoMergePolicy and 
TestSortingMergePolicy now extend it, TestUpgradeIndexMergePolicy added)


> increase BaseMergePolicyTestCase use
> 
>
> Key: LUCENE-7006
> URL: https://issues.apache.org/jira/browse/LUCENE-7006
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7006.patch
>
>
> * {{TestNoMergePolicy}} to extend {{BaseMergePolicyTestCase}}
> * {{TestSortingMergePolicy}} to extend {{BaseMergePolicyTestCase}}
> * add {{TestUpgradeIndexMergePolicy}} (which for now simply extends 
> {{BaseMergePolicyTestCase}})



--
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-8508) Implement DatabaseMetaDataImpl.getCatalogs()

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8508:
---

Commit edf665988d6f7acf95ec49ed16a3afc30ffcb342 in lucene-solr's branch 
refs/heads/master-solr-8621 from jbernste
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=edf6659 ]

SOLR-8508: Implement DatabaseMetaDataImpl.getCatalogs()


> Implement DatabaseMetaDataImpl.getCatalogs()
> 
>
> Key: SOLR-8508
> URL: https://issues.apache.org/jira/browse/SOLR-8508
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8508.patch, SOLR-8508.patch, SOLR-8508.patch, 
> SOLR-8508.patch
>
>
> DBVisualizer users DatabaseMetaDataImpl.getCatalogs() to populate information 
> after connecting. It causes the below error and shows up in the connection 
> window.
> 2016-01-07 13:30:10.848 FINE83 [ExecutorRunner-pool-2-thread-10 - 
> B.execute] Execute Command: getCatalogs
> 2016-01-07 13:30:10.848 FINE83 [ExecutorRunner-pool-2-thread-10 - O.ￄﾘ] 
> getCatalogs() for: abc
> 2016-01-07 13:30:10.848 FINE83 [pool-3-thread-10 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getCatalogs()
> 2016-01-07 13:30:10.851 FINE83 [AWT-EventQueue-0 - B.executionFinished] 
> Exception while Connecting
> com.onseven.dbvis.K.B.P: java.util.concurrent.ExecutionException: 
> java.lang.IllegalArgumentException: model passed to DefaultTableModelWrapper 
> cannot be null
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:2680)
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:1521)
>   at com.onseven.dbvis.K.B.L$3.run(Z:3032)
>   at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
>   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
>   at java.awt.EventQueue.access$500(EventQueue.java:97)
>   at java.awt.EventQueue$3.run(EventQueue.java:709)
>   at java.awt.EventQueue$3.run(EventQueue.java:703)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
>   at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
>   at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
>   at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
>   at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
>   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
>   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
>   at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.IllegalArgumentException: model passed to DefaultTableModelWrapper 
> cannot be null
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122)
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192)
>   at javax.swing.SwingWorker.get(SwingWorker.java:602)
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:990)
>   ... 16 more
> Caused by: java.lang.IllegalArgumentException: model passed to 
> DefaultTableModelWrapper cannot be null
>   at com.jidesoft.grid.TableModelWrapperImpl.(Unknown Source)
>   at com.jidesoft.grid.DefaultTableModelWrapper.(Unknown Source)
>   at com.jidesoft.grid.FilterableTableModel.(Unknown Source)
>   at com.jidesoft.grid.FilterableTreeTableModel.(Unknown Source)
>   at com.onseven.dbvis.K.B._.(Z:1161)
>   at com.onseven.dbvis.db.AbstractFacade.executeAndGet(Z:975)
>   at com.onseven.dbvis.db.AbstractFacade.getCatalogNames(Z:621)
>   at com.onseven.dbvis.db.AbstractFacade.runConnectionSetup(Z:2515)
>   at com.onseven.dbvis.db.A.I.ￄﾷ(Z:3512)
>   at com.onseven.dbvis.db.A.B.execute(Z:2933)
>   at com.onseven.dbvis.K.B.Z.ￄﾁ(Z:2285)
>   at com.onseven.dbvis.K.B.L.ￄﾂ(Z:1374)
>   at com.onseven.dbvis.K.B.L.doInBackground(Z:1521)
>   at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at javax.swing.SwingWorker.run(SwingWorker.java:334)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)



--
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-7968) Allow extending QueryComponent

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-7968:
---

Commit 4cdce3db77cde2506ac77dc9ced8c1f91ed9800f in lucene-solr's branch 
refs/heads/master-solr-8621 from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4cdce3d ]

SOLR-7968: Make QueryComponent extensible


> Allow extending QueryComponent
> --
>
> Key: SOLR-7968
> URL: https://issues.apache.org/jira/browse/SOLR-7968
> Project: Solr
>  Issue Type: Improvement
>  Components: SearchComponents - other
>Affects Versions: 5.2.1
>Reporter: Markus Jelsma
>Assignee: David Smiley
>Priority: Minor
> Fix For: 5.5
>
> Attachments: SOLR-7968.patch, SOLR-7968.patch
>
>
> QueryComponent is, after all this time, still not extendable. Overriding a 
> simple method is mostly impossible due to members being private or usage of 
> non-public classes. Copying all code to an external class is also not going 
> to work because of this. This patch finally allows overriding QueryComponent 
> methods such as createMainQuery and mergeIds.



--
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-8621) solrconfig.xml: deprecate/replace with

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8621:
---

Commit 43671b3e0dc998bab73fd53bcd4df829d8eb273d in lucene-solr's branch 
refs/heads/master-solr-8621 from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=43671b3 ]

for SOLR-8621 work-in-progress branch:
 * adds LogByteSizeMergePolicyFactory and LogDocMergePolicyFactory
 * removes subPackages arg from MergePolicyFactoryHelper.newInstance signature
 * adds BaseMergePolicyTestCase.testMergePolicyFactory method (and the things 
it calls)


> solrconfig.xml: deprecate/replace  with 
> -
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>
> * end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge 
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces  support
> * solr 5.5(\?) deprecates (but maintains)  support
> * solr 6.0(\?) removes  support 
> +work-in-progress git branch:+ 
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]



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

Re: More Managed Filters?

[Shawn Heisey]

On 2/2/2016 7:26 AM, Jan Høydahl wrote:
> Good reminder :)
>
> Looking at the code, the ones that are configured from simple set of words 
> (one per line) like StopFilter are fairly easy to implement.
> So perhaps start with those. You would first check JIRA if an issue is 
> already filed for the filter you want, and if not, file a new feature request 
> for e.g. ManagedKeepWordFilterFactory.

I wonder whether these objects could be combined into a single generic
object, managing any list-type text file within the config, and
rebuilding the schema object after each change.  This idea might not be
workable in practice, just something I thought of.

Thanks,
Shawn


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

[jira] [Commented] (SOLR-8631) Implement DatabaseMetaDataImpl.getTypeInfo()

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8631:
--

Great, I'll commit this today.

> Implement DatabaseMetaDataImpl.getTypeInfo()
> 
>
> Key: SOLR-8631
> URL: https://issues.apache.org/jira/browse/SOLR-8631
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Fix For: Trunk
>
> Attachments: SOLR-8631.patch
>
>
> Once getSchemas (SOLR-8510) is implemented, DBVisualizer tries to get type 
> information with getDataTypes and fails with a NPE. A short term workaround 
> is to an UnsupportedOperationException instead of returning null.
> {code}
> 2016-02-01 21:27:33.868 FINE   647 [pool-3-thread-4 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getTypeInfo()
> 2016-02-01 21:27:33.870 FINE   647 [AWT-EventQueue-0 - B.executionFinished] 
> Exception while Connecting
> com.onseven.dbvis.K.B.P: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:2680)
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:1521)
>   at com.onseven.dbvis.K.B.L$3.run(Z:3032)
>   at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
>   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
>   at java.awt.EventQueue.access$500(EventQueue.java:97)
>   at java.awt.EventQueue$3.run(EventQueue.java:709)
>   at java.awt.EventQueue$3.run(EventQueue.java:703)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
>   at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
>   at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
>   at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
>   at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
>   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
>   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
>   at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122)
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192)
>   at javax.swing.SwingWorker.get(SwingWorker.java:602)
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:990)
>   ... 16 more
> Caused by: java.lang.NullPointerException
>   at com.onseven.dbvis.db.AbstractFacade.getDataTypes(Z:3212)
>   at com.onseven.dbvis.db.AbstractFacade.runConnectionSetup(Z:1260)
>   at com.onseven.dbvis.db.A.I.ￄﾷ(Z:3512)
>   at com.onseven.dbvis.db.A.B.execute(Z:2933)
>   at com.onseven.dbvis.K.B.Z.ￄﾁ(Z:2285)
>   at com.onseven.dbvis.K.B.L.ￄﾂ(Z:1374)
>   at com.onseven.dbvis.K.B.L.doInBackground(Z:1521)
>   at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at javax.swing.SwingWorker.run(SwingWorker.java:334)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



--
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] (LUCENE-7008) TestSortingMergePolicy.testForceMergeNotNeeded fails

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15128433#comment-15128433
 ] 

ASF subversion and git services commented on LUCENE-7008:
-

Commit 5dbe7d9a73bc4fd890a927b738c692314177ab17 in lucene-solr's branch 
refs/heads/branch_5x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5dbe7d9 ]

LUCENE-7008: make TestSortingMergePolicy.testForceMergeNotNeeded a no-op until 
we figure out why the (super class) test fails.


> TestSortingMergePolicy.testForceMergeNotNeeded fails
> 
>
> Key: LUCENE-7008
> URL: https://issues.apache.org/jira/browse/LUCENE-7008
> Project: Lucene - Core
>  Issue Type: Test
>Affects Versions: Trunk
>Reporter: Christine Poerschke
>
> {{TestSortingMergePolicy.testForceMergeNotNeeded}} (recently added by 
> LUCENE-7006) regularly and reproducibly fails e.g.
> {code}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestSortingMergePolicy -Dtests.method=testForceMergeNotNeeded 
> -Dtests.seed=BAF97ED1D97DDEEE -Dtests.slow=true -Dtests.locale=nl-NL 
> -Dtests.timezone=CST6CDT -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
> {code}
> Stack Trace:
> {code}
> java.lang.AssertionError
> at 
> __randomizedtesting.SeedInfo.seed([BAF97ED1D97DDEEE:A6DA06CB422235FB]:0)
> at 
> org.apache.lucene.index.BaseMergePolicyTestCase$1.merge(BaseMergePolicyTestCase.java:44)
> at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1931)
> at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1764)
> at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1721)
> at 
> org.apache.lucene.index.BaseMergePolicyTestCase.testForceMergeNotNeeded(BaseMergePolicyTestCase.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> 

[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1667: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1667/

No tests ran.

Build Log:
[...truncated 27593 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/build.xml:756: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/build.xml:299: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/lucene/build.xml:420:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/lucene/common-build.xml:2187:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/lucene/analysis/build.xml:122:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/lucene/analysis/build.xml:38:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/lucene/common-build.xml:1681:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/lucene/common-build.xml:594:
 Error deploying artifact 'org.apache.lucene:lucene-analyzers-kuromoji:jar': 
Error deploying artifact: Error transferring file

Total time: 25 minutes 59 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Updated] (SOLR-8631) Implement DatabaseMetaDataImpl.getTypeInfo()

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8631:
---
Attachment: SOLR-8631.patch

Initial patch just throwing unsupported operation.

[~joel.bernstein] - I agree that this requires a lot of metadata to be sent 
back. Maybe we can leave this open and implement it at a later date?

> Implement DatabaseMetaDataImpl.getTypeInfo()
> 
>
> Key: SOLR-8631
> URL: https://issues.apache.org/jira/browse/SOLR-8631
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Fix For: Trunk
>
> Attachments: SOLR-8631.patch
>
>
> Once getSchemas (SOLR-8510) is implemented, DBVisualizer tries to get type 
> information with getDataTypes and fails with a NPE. A short term workaround 
> is to an UnsupportedOperationException instead of returning null.
> {code}
> 2016-02-01 21:27:33.868 FINE   647 [pool-3-thread-4 - E.ￄﾁ] RootConnection: 
> DatabaseMetaDataImpl.getTypeInfo()
> 2016-02-01 21:27:33.870 FINE   647 [AWT-EventQueue-0 - B.executionFinished] 
> Exception while Connecting
> com.onseven.dbvis.K.B.P: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:2680)
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:1521)
>   at com.onseven.dbvis.K.B.L$3.run(Z:3032)
>   at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
>   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
>   at java.awt.EventQueue.access$500(EventQueue.java:97)
>   at java.awt.EventQueue$3.run(EventQueue.java:709)
>   at java.awt.EventQueue$3.run(EventQueue.java:703)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
>   at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
>   at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
>   at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
>   at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
>   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
>   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
>   at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122)
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192)
>   at javax.swing.SwingWorker.get(SwingWorker.java:602)
>   at com.onseven.dbvis.K.B.L.ￄﾁ(Z:990)
>   ... 16 more
> Caused by: java.lang.NullPointerException
>   at com.onseven.dbvis.db.AbstractFacade.getDataTypes(Z:3212)
>   at com.onseven.dbvis.db.AbstractFacade.runConnectionSetup(Z:1260)
>   at com.onseven.dbvis.db.A.I.ￄﾷ(Z:3512)
>   at com.onseven.dbvis.db.A.B.execute(Z:2933)
>   at com.onseven.dbvis.K.B.Z.ￄﾁ(Z:2285)
>   at com.onseven.dbvis.K.B.L.ￄﾂ(Z:1374)
>   at com.onseven.dbvis.K.B.L.doInBackground(Z:1521)
>   at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at javax.swing.SwingWorker.run(SwingWorker.java:334)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



--
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] (LUCENE-7008) TestSortingMergePolicy.testForceMergeNotNeeded fails

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated LUCENE-7008:

Affects Version/s: 5.5

> TestSortingMergePolicy.testForceMergeNotNeeded fails
> 
>
> Key: LUCENE-7008
> URL: https://issues.apache.org/jira/browse/LUCENE-7008
> Project: Lucene - Core
>  Issue Type: Test
>Affects Versions: 5.5, Trunk
>Reporter: Christine Poerschke
>
> {{TestSortingMergePolicy.testForceMergeNotNeeded}} (recently added by 
> LUCENE-7006) regularly and reproducibly fails e.g.
> {code}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestSortingMergePolicy -Dtests.method=testForceMergeNotNeeded 
> -Dtests.seed=BAF97ED1D97DDEEE -Dtests.slow=true -Dtests.locale=nl-NL 
> -Dtests.timezone=CST6CDT -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
> {code}
> Stack Trace:
> {code}
> java.lang.AssertionError
> at 
> __randomizedtesting.SeedInfo.seed([BAF97ED1D97DDEEE:A6DA06CB422235FB]:0)
> at 
> org.apache.lucene.index.BaseMergePolicyTestCase$1.merge(BaseMergePolicyTestCase.java:44)
> at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1931)
> at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1764)
> at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1721)
> at 
> org.apache.lucene.index.BaseMergePolicyTestCase.testForceMergeNotNeeded(BaseMergePolicyTestCase.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at 
> 

[jira] [Resolved] (LUCENE-7006) increase BaseMergePolicyTestCase use

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved LUCENE-7006.
-
   Resolution: Fixed
Fix Version/s: Trunk
   5.5

> increase BaseMergePolicyTestCase use
> 
>
> Key: LUCENE-7006
> URL: https://issues.apache.org/jira/browse/LUCENE-7006
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: LUCENE-7006.patch
>
>
> * {{TestNoMergePolicy}} to extend {{BaseMergePolicyTestCase}}
> * {{TestSortingMergePolicy}} to extend {{BaseMergePolicyTestCase}}
> * add {{TestUpgradeIndexMergePolicy}} (which for now simply extends 
> {{BaseMergePolicyTestCase}})



--
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] (LUCENE-7007) Reduce block-tree GC/CPU cost when flushing or merging postings

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-7007:
--

 Summary: Reduce block-tree GC/CPU cost when flushing or merging 
postings
 Key: LUCENE-7007
 URL: https://issues.apache.org/jira/browse/LUCENE-7007
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless


Writing postings is a GC and CPU heavy operation now, in part because of how
block tree recursively builds up the tree structure, by creating many
tiny FSTs which it inefficiently merges together as it walks up the
tree eventually to the root block.

So I tried a quick prototype (patch attached) to use a
less-RAM-efficient, but much fewer tiny FST related objects, when
writing postings.

But in some quick indexing performance tests (luceneutil), it makes no
measurable improvements to indexing performance.

So I'm putting my patch up here for posterity ... I don't intend to
commit it unless we can iterate it further.  It adds code complexity,
it's not committable as-is (we need to conditionalize it so it
sometimes does use FSTs, for segments with many terms), etc.




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