[jira] [Commented] (LUCENE-4352) only the test runner should be able to System.exit
[ https://issues.apache.org/jira/browse/LUCENE-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447509#comment-13447509 ] Dawid Weiss commented on LUCENE-4352: - bq. The access checks must be done with the SecurityManager's access context, otherwise things like getting stack trace could be denied Stack traces are retrieved from all over the place in the test framework too (on test timeouts, on thread leaks). Will it work? only the test runner should be able to System.exit -- Key: LUCENE-4352 URL: https://issues.apache.org/jira/browse/LUCENE-4352 Project: Lucene - Core Issue Type: Bug Components: general/test Affects Versions: 4.0-BETA Reporter: Robert Muir Assignee: Uwe Schindler Fix For: 5.0, 4.0 Attachments: LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch All others should get SecurityException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4352) only the test runner should be able to System.exit
[ https://issues.apache.org/jira/browse/LUCENE-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447511#comment-13447511 ] Uwe Schindler commented on LUCENE-4352: --- bq. Stack traces are retrieved from all over the place in the test framework too (on test timeouts, on thread leaks). Will it work? If you install a SecurityManager that does not allow this, it will of course not work. The thing here is more special and has nothing to do with Test-Framework: If the Security Manager itsself has to do additional checks that may be denied, it must du this using his own security context (thats what AccessController is doing here) and not with the one of the caller. only the test runner should be able to System.exit -- Key: LUCENE-4352 URL: https://issues.apache.org/jira/browse/LUCENE-4352 Project: Lucene - Core Issue Type: Bug Components: general/test Affects Versions: 4.0-BETA Reporter: Robert Muir Assignee: Uwe Schindler Fix For: 5.0, 4.0 Attachments: LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch All others should get SecurityException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4352) only the test runner should be able to System.exit
[ https://issues.apache.org/jira/browse/LUCENE-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447513#comment-13447513 ] Dawid Weiss commented on LUCENE-4352: - Ok, I get it. only the test runner should be able to System.exit -- Key: LUCENE-4352 URL: https://issues.apache.org/jira/browse/LUCENE-4352 Project: Lucene - Core Issue Type: Bug Components: general/test Affects Versions: 4.0-BETA Reporter: Robert Muir Assignee: Uwe Schindler Fix For: 5.0, 4.0 Attachments: LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch All others should get SecurityException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4352) only the test runner should be able to System.exit
[ https://issues.apache.org/jira/browse/LUCENE-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447515#comment-13447515 ] Uwe Schindler commented on LUCENE-4352: --- For the test-framework an example for using AccessControler.doPrivileged() would be: - Policy denies e.g. file access outside the test runner JAR (which may be a good idea) - untrusted code - But Policy allows writing files outside the J0 working directory for the test-framework.jar file itself - trusted code The problem here would be: - untrusted code calls trusted code, e.g. the test (untrusted) calls a method from test-framework that writes outside base directory. The calling untrusted code is not allowed to do this, but the test-framework itsself (trusted) is allowed to do this. - SecurityManager would disallow this, but that may not what we want. The naming of AccessController.doPrivileged is a little bit misleading. It does not mean something is privileged, it just tells that the closure should not be handled by access checks of the code calling you, but with the context of your own code. This is always needed when untrusted code calls trusted code which would normally have higher rights. The above example might be a good solution (limit write access to test-runner's local private J0 directory only). only the test runner should be able to System.exit -- Key: LUCENE-4352 URL: https://issues.apache.org/jira/browse/LUCENE-4352 Project: Lucene - Core Issue Type: Bug Components: general/test Affects Versions: 4.0-BETA Reporter: Robert Muir Assignee: Uwe Schindler Fix For: 5.0, 4.0 Attachments: LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch All others should get SecurityException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3597) seems like a lot of wasted whitespace at the top of the admin screens
[ https://issues.apache.org/jira/browse/SOLR-3597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3597: Attachment: SOLR-3597.patch Right, didn't notice that .. updated Patch attached seems like a lot of wasted whitespace at the top of the admin screens - Key: SOLR-3597 URL: https://issues.apache.org/jira/browse/SOLR-3597 Project: Solr Issue Type: Improvement Components: web gui Reporter: Hoss Man Assignee: Stefan Matheis (steffkes) Fix For: 4.0 Attachments: error-divs-overlap.png, SOLR-3597-hack.patch, SOLR-3597.patch, SOLR-3597.patch because of how the UI is laid out, the solr logo is all by itself above the main table, leaving a lot of whitespace to the right of the solr logo. this seems like a waste that should be easily curable? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3734) Forever loop in schema browser
[ https://issues.apache.org/jira/browse/SOLR-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3734: Attachment: SOLR-3734.patch First Draft, just a quick hack. Forever loop in schema browser -- Key: SOLR-3734 URL: https://issues.apache.org/jira/browse/SOLR-3734 Project: Solr Issue Type: Bug Components: Schema and Analysis, web gui Reporter: Lance Norskog Attachments: SOLR-3734.patch, SOLR-3734_schema_browser_blocks_solr_conf_dir.zip When I start Solr with the attached conf directory, and hit the Schema Browser, the loading circle spins permanently. I don't know if the problem is in the UI or in Solr. The UI does not display the Ajax solr calls, and I don't have a debugging proxy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-4352) only the test runner should be able to System.exit
[ https://issues.apache.org/jira/browse/LUCENE-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447515#comment-13447515 ] Uwe Schindler edited comment on LUCENE-4352 at 9/4/12 6:04 PM: --- For the test-framework an example for using AccessControler.doPrivileged() would be: - Policy denies e.g. file access outside the test runner J0 working dir (which may be a good idea) - untrusted code - But Policy allows writing files outside the J0 working directory for the test-framework.jar file itself - trusted code The problem here would be: - untrusted code calls trusted code, e.g. the test (untrusted) calls a method from test-framework that writes outside base directory. The calling untrusted code is not allowed to do this, but the test-framework itsself (trusted) is allowed to do this. - SecurityManager would disallow this, but that may not what we want. The naming of AccessController.doPrivileged is a little bit misleading. It does not mean something is privileged, it just tells that the closure should not be handled by access checks of the code calling you, but with the context of your own code. This is always needed when untrusted code calls trusted code which would normally have higher rights. The above example might be a good solution (limit write access to test-runner's local private J0 directory only). was (Author: thetaphi): For the test-framework an example for using AccessControler.doPrivileged() would be: - Policy denies e.g. file access outside the test runner JAR (which may be a good idea) - untrusted code - But Policy allows writing files outside the J0 working directory for the test-framework.jar file itself - trusted code The problem here would be: - untrusted code calls trusted code, e.g. the test (untrusted) calls a method from test-framework that writes outside base directory. The calling untrusted code is not allowed to do this, but the test-framework itsself (trusted) is allowed to do this. - SecurityManager would disallow this, but that may not what we want. The naming of AccessController.doPrivileged is a little bit misleading. It does not mean something is privileged, it just tells that the closure should not be handled by access checks of the code calling you, but with the context of your own code. This is always needed when untrusted code calls trusted code which would normally have higher rights. The above example might be a good solution (limit write access to test-runner's local private J0 directory only). only the test runner should be able to System.exit -- Key: LUCENE-4352 URL: https://issues.apache.org/jira/browse/LUCENE-4352 Project: Lucene - Core Issue Type: Bug Components: general/test Affects Versions: 4.0-BETA Reporter: Robert Muir Assignee: Uwe Schindler Fix For: 5.0, 4.0 Attachments: LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch All others should get SecurityException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3679) Core Admin UI gives no feedback if Add Core fails
[
https://issues.apache.org/jira/browse/SOLR-3679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-3679:
Attachment: SOLR-3679.patch
Combined Patch for SOLR-3680 and SOLR-3679
The current Error Message seems to wrap the original Exception so that we
always get the same Text?
Complete Stacktrace:
{code}SEVERE: org.apache.solr.common.SolrException: Error executing default
implementation of CREATE
at
org.apache.solr.handler.admin.CoreAdminHandler.handleCreateAction(CoreAdminHandler.java:389)
at
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:134)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at
org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:371)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:180)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:351)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.io.IOException: Can't find resource 'solrconfig.xml' in
classpath or 'solr/new_core/conf/', cwd=/opt/solr/trunk/solr/example
at
org.apache.solr.core.SolrResourceLoader.openResource(SolrResourceLoader.java:317)
at
org.apache.solr.core.SolrResourceLoader.openConfig(SolrResourceLoader.java:283)
at org.apache.solr.core.Config.init(Config.java:111)
at org.apache.solr.core.Config.init(Config.java:78)
at org.apache.solr.core.SolrConfig.init(SolrConfig.java:117)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:780)
at
org.apache.solr.handler.admin.CoreAdminHandler.handleCreateAction(CoreAdminHandler.java:384)
... 29 more{code}
Core Admin UI gives no feedback if Add Core fails
---
Key: SOLR-3679
URL: https://issues.apache.org/jira/browse/SOLR-3679
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0-ALPHA
Reporter: Hoss Man
Assignee: Stefan Matheis (steffkes)
Attachments: SOLR-3679.patch
* start the example
* load the admin ui, click on core admin
* click on Add Core
* fill the form out with giberish and submit.
The form stays on the screen w/o any feedback that an error occurred
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LUCENE-4353) Document deletions not applied to non-flushed segments
Sivan Yogev created LUCENE-4353: --- Summary: Document deletions not applied to non-flushed segments Key: LUCENE-4353 URL: https://issues.apache.org/jira/browse/LUCENE-4353 Project: Lucene - Core Issue Type: Bug Components: core/index Reporter: Sivan Yogev Fix For: 5.0 Document deletions seems not to be applied to the current in-memory segments, only to flushed ones. Adding a test which fails on this, adding a commit before deletion makes the test pass. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4353) Document deletions not applied to non-flushed segments
[ https://issues.apache.org/jira/browse/LUCENE-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sivan Yogev updated LUCENE-4353: Attachment: TestNonFlushedSegmentDeletion.java Document deletions not applied to non-flushed segments -- Key: LUCENE-4353 URL: https://issues.apache.org/jira/browse/LUCENE-4353 Project: Lucene - Core Issue Type: Bug Components: core/index Reporter: Sivan Yogev Fix For: 5.0 Attachments: TestNonFlushedSegmentDeletion.java Original Estimate: 336h Remaining Estimate: 336h Document deletions seems not to be applied to the current in-memory segments, only to flushed ones. Adding a test which fails on this, adding a commit before deletion makes the test pass. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4353) Document deletions not applied to non-flushed segments
[ https://issues.apache.org/jira/browse/LUCENE-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-4353. - Resolution: Not A Problem docFreq doesn't reflect deletes. Document deletions not applied to non-flushed segments -- Key: LUCENE-4353 URL: https://issues.apache.org/jira/browse/LUCENE-4353 Project: Lucene - Core Issue Type: Bug Components: core/index Reporter: Sivan Yogev Fix For: 5.0 Attachments: TestNonFlushedSegmentDeletion.java Original Estimate: 336h Remaining Estimate: 336h Document deletions seems not to be applied to the current in-memory segments, only to flushed ones. Adding a test which fails on this, adding a commit before deletion makes the test pass. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3783) Facet pivots produces NPE when facet.missing is turned on
Tanguy Moal created SOLR-3783:
-
Summary: Facet pivots produces NPE when facet.missing is turned on
Key: SOLR-3783
URL: https://issues.apache.org/jira/browse/SOLR-3783
Project: Solr
Issue Type: Bug
Components: SearchComponents - other
Reporter: Tanguy Moal
Priority: Minor
We get an http 500 as follow :
{!code:xml}
lst name=error
str name=tracejava.lang.NullPointerException/str
int name=code500/int
/lst
{code}
When facet.missing is turned on and combined with facet.pivot (if one of the
pivot-faceted fields have missing counts ^-^)
Ideally, the decission tree could be computing for the missing entries using
the -field:[* TO *] query but it might be a performance issue on a large index
(I guess)
The fallback to this could be to raise a 400 error with a clean message telling
that both parameters can't be combined and then the documentation should be
modified accordingly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3783) Facet pivots produces NPE when facet.missing is turned on
[
https://issues.apache.org/jira/browse/SOLR-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanguy Moal updated SOLR-3783:
--
Description:
We get an http 500 as follow :
{code:xml}
lst name=error
str name=tracejava.lang.NullPointerException/str
int name=code500/int
/lst
{code}
When facet.missing is turned on and combined with facet.pivot (if one of the
pivot-faceted fields have missing counts ^-^)
Ideally, the decission tree could be computing for the missing entries using
the {noformat} -field:[* TO *] {noformat} query but it might be a performance
issue on a large index (I guess)
The fallback to this could be to raise a 400 error with a clean message telling
that both parameters can't be combined and then the documentation should be
modified accordingly.
was:
We get an http 500 as follow :
{code:xml}
lst name=error
str name=tracejava.lang.NullPointerException/str
int name=code500/int
/lst
{code}
When facet.missing is turned on and combined with facet.pivot (if one of the
pivot-faceted fields have missing counts ^-^)
Ideally, the decission tree could be computing for the missing entries using
the -field:[* TO *] query but it might be a performance issue on a large index
(I guess)
The fallback to this could be to raise a 400 error with a clean message telling
that both parameters can't be combined and then the documentation should be
modified accordingly.
Facet pivots produces NPE when facet.missing is turned on
-
Key: SOLR-3783
URL: https://issues.apache.org/jira/browse/SOLR-3783
Project: Solr
Issue Type: Bug
Components: SearchComponents - other
Reporter: Tanguy Moal
Priority: Minor
We get an http 500 as follow :
{code:xml}
lst name=error
str name=tracejava.lang.NullPointerException/str
int name=code500/int
/lst
{code}
When facet.missing is turned on and combined with facet.pivot (if one of the
pivot-faceted fields have missing counts ^-^)
Ideally, the decission tree could be computing for the missing entries
using the {noformat} -field:[* TO *] {noformat} query but it might be a
performance issue on a large index (I guess)
The fallback to this could be to raise a 400 error with a clean message
telling that both parameters can't be combined and then the documentation
should be modified accordingly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3783) Facet pivots produces NPE when facet.missing is turned on
[
https://issues.apache.org/jira/browse/SOLR-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanguy Moal updated SOLR-3783:
--
Description:
We get an http 500 as follow :
{code:xml}
lst name=error
str name=tracejava.lang.NullPointerException/str
int name=code500/int
/lst
{code}
When facet.missing is turned on and combined with facet.pivot (if one of the
pivot-faceted fields have missing counts ^-^)
Ideally, the decission tree could be computing for the missing entries using
the -field:[* TO *] query but it might be a performance issue on a large index
(I guess)
The fallback to this could be to raise a 400 error with a clean message telling
that both parameters can't be combined and then the documentation should be
modified accordingly.
was:
We get an http 500 as follow :
{!code:xml}
lst name=error
str name=tracejava.lang.NullPointerException/str
int name=code500/int
/lst
{code}
When facet.missing is turned on and combined with facet.pivot (if one of the
pivot-faceted fields have missing counts ^-^)
Ideally, the decission tree could be computing for the missing entries using
the -field:[* TO *] query but it might be a performance issue on a large index
(I guess)
The fallback to this could be to raise a 400 error with a clean message telling
that both parameters can't be combined and then the documentation should be
modified accordingly.
Facet pivots produces NPE when facet.missing is turned on
-
Key: SOLR-3783
URL: https://issues.apache.org/jira/browse/SOLR-3783
Project: Solr
Issue Type: Bug
Components: SearchComponents - other
Reporter: Tanguy Moal
Priority: Minor
We get an http 500 as follow :
{code:xml}
lst name=error
str name=tracejava.lang.NullPointerException/str
int name=code500/int
/lst
{code}
When facet.missing is turned on and combined with facet.pivot (if one of the
pivot-faceted fields have missing counts ^-^)
Ideally, the decission tree could be computing for the missing entries
using the -field:[* TO *] query but it might be a performance issue on a
large index (I guess)
The fallback to this could be to raise a 400 error with a clean message
telling that both parameters can't be combined and then the documentation
should be modified accordingly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3784) Schema-Browser hangs because of similarity
Stefan Matheis (steffkes) created SOLR-3784:
---
Summary: Schema-Browser hangs because of similarity
Key: SOLR-3784
URL: https://issues.apache.org/jira/browse/SOLR-3784
Project: Solr
Issue Type: Bug
Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Greg Bowyer
Opening the Schema-Browser with the Default Configuration, switching the
selection to type=int throws an error:
{code}Uncaught TypeError: Cannot call method 'esc' of undefined //
schema-browser.js:893{code}
On the first Look, this was introduced by SOLR-3572 .. right?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3784) Schema-Browser hangs because of similarity
[
https://issues.apache.org/jira/browse/SOLR-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-3784:
Attachment: SOLR-3784.patch
Not sure if that Patch works for all cases, but for the default configuration
.. it's okay. Greg would you mind to have a look and see what checks are needed?
Schema-Browser hangs because of similarity
--
Key: SOLR-3784
URL: https://issues.apache.org/jira/browse/SOLR-3784
Project: Solr
Issue Type: Bug
Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Greg Bowyer
Attachments: SOLR-3784.patch
Opening the Schema-Browser with the Default Configuration, switching the
selection to type=int throws an error:
{code}Uncaught TypeError: Cannot call method 'esc' of undefined //
schema-browser.js:893{code}
On the first Look, this was introduced by SOLR-3572 .. right?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3784) Schema-Browser hangs because of similarity
[
https://issues.apache.org/jira/browse/SOLR-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447583#comment-13447583
]
Stefan Matheis (steffkes) commented on SOLR-3784:
-
This is the given structure/information for the int-type:
{code}int: {
// ...
similarity: { }
}{code}
which is why the current check passes, but similarity.details is {{undefined}}
Schema-Browser hangs because of similarity
--
Key: SOLR-3784
URL: https://issues.apache.org/jira/browse/SOLR-3784
Project: Solr
Issue Type: Bug
Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Greg Bowyer
Attachments: SOLR-3784.patch
Opening the Schema-Browser with the Default Configuration, switching the
selection to type=int throws an error:
{code}Uncaught TypeError: Cannot call method 'esc' of undefined //
schema-browser.js:893{code}
On the first Look, this was introduced by SOLR-3572 .. right?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4340) Move all codecs but Lucene40 to a module
[ https://issues.apache.org/jira/browse/LUCENE-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-4340: - Attachment: LUCENE-4340.patch LUCENE-4340.sh Thanks, Steven! First patch. To apply, first run the bash script and then apply the patch. There are some things I am still unsure about: - should the fact that lucene-codecs now is a test dependency of lucene-core be reflected in dev-tools/maven/lucene/core/pom.xml.template (I thought it should, but I was surprised test-framework is not listed here), - I modified the IDEA configuration files to add an entry for this new module but I didn't test, - Solr lets users configure postings formats on a per-field basis but now only the default Lucene40PostingsFormat will be available by default, should we add lucene-codecs to Solr WAR or do we expect expert users to drop this JAR in their lib directory? Move all codecs but Lucene40 to a module Key: LUCENE-4340 URL: https://issues.apache.org/jira/browse/LUCENE-4340 Project: Lucene - Core Issue Type: Task Components: core/codecs, general/build Reporter: Adrien Grand Fix For: 5.0, 4.0 Attachments: LUCENE-4340.patch, LUCENE-4340.sh We should move all concrete postings formats and codecs but Lucene40 to a module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-4353) Document deletions not applied to non-flushed segments
[ https://issues.apache.org/jira/browse/LUCENE-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sivan Yogev reopened LUCENE-4353: - Lucene Fields: New,Patch Available (was: New) Adding a new version of the test using DocsAndPositionsEnum instead of docFreq, still fails. Document deletions not applied to non-flushed segments -- Key: LUCENE-4353 URL: https://issues.apache.org/jira/browse/LUCENE-4353 Project: Lucene - Core Issue Type: Bug Components: core/index Reporter: Sivan Yogev Fix For: 5.0 Attachments: TestNonFlushedSegmentDeletion.java Original Estimate: 336h Remaining Estimate: 336h Document deletions seems not to be applied to the current in-memory segments, only to flushed ones. Adding a test which fails on this, adding a commit before deletion makes the test pass. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4353) Document deletions not applied to non-flushed segments
[ https://issues.apache.org/jira/browse/LUCENE-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sivan Yogev updated LUCENE-4353: Attachment: TestNonFlushedSegmentDeletion.java Document deletions not applied to non-flushed segments -- Key: LUCENE-4353 URL: https://issues.apache.org/jira/browse/LUCENE-4353 Project: Lucene - Core Issue Type: Bug Components: core/index Reporter: Sivan Yogev Fix For: 5.0 Attachments: TestNonFlushedSegmentDeletion.java Original Estimate: 336h Remaining Estimate: 336h Document deletions seems not to be applied to the current in-memory segments, only to flushed ones. Adding a test which fails on this, adding a commit before deletion makes the test pass. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4353) Document deletions not applied to non-flushed segments
[ https://issues.apache.org/jira/browse/LUCENE-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sivan Yogev updated LUCENE-4353: Attachment: (was: TestNonFlushedSegmentDeletion.java) Document deletions not applied to non-flushed segments -- Key: LUCENE-4353 URL: https://issues.apache.org/jira/browse/LUCENE-4353 Project: Lucene - Core Issue Type: Bug Components: core/index Reporter: Sivan Yogev Fix For: 5.0 Attachments: TestNonFlushedSegmentDeletion.java Original Estimate: 336h Remaining Estimate: 336h Document deletions seems not to be applied to the current in-memory segments, only to flushed ones. Adding a test which fails on this, adding a commit before deletion makes the test pass. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4353) Document deletions not applied to non-flushed segments
[ https://issues.apache.org/jira/browse/LUCENE-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447608#comment-13447608 ] Sivan Yogev commented on LUCENE-4353: - BufferedDeletes has a terms map which maps each deleted term to the doc id from which the delete should not be applied. However, in FrozenBufferedDeletes only the keySet of the map is taken and the doc ids are ignored. Document deletions not applied to non-flushed segments -- Key: LUCENE-4353 URL: https://issues.apache.org/jira/browse/LUCENE-4353 Project: Lucene - Core Issue Type: Bug Components: core/index Reporter: Sivan Yogev Fix For: 5.0 Attachments: TestNonFlushedSegmentDeletion.java Original Estimate: 336h Remaining Estimate: 336h Document deletions seems not to be applied to the current in-memory segments, only to flushed ones. Adding a test which fails on this, adding a commit before deletion makes the test pass. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4354) add validate-maven task to check maven dependencies
Robert Muir created LUCENE-4354: --- Summary: add validate-maven task to check maven dependencies Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4354: Attachment: LUCENE-4354.patch here's a prototype: it should really be using the maven-ant-tasks plugin and not 'exec' but its a start. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[
https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447612#comment-13447612
]
Robert Muir commented on LUCENE-4354:
-
lucene/ fails because maven is pulling in an extra jar (duplicates removed
below):
{noformat}
-maven-check-licenses:
[echo] License check under:
/home/rmuir/workspace/lucene-trunk/lucene/../maven-build/lucene
[licenses] MISSING sha1 checksum file for:
/home/rmuir/workspace/lucene-trunk/maven-build/lucene/analysis/common/target/dependency/hamcrest-core-1.1.jar
...
{noformat}
solr/ fails due to several extra jars (duplicates removed below):
{noformat}
[licenses] MISSING sha1 checksum file for:
/home/rmuir/workspace/lucene-trunk/maven-build/solr/contrib/analysis-extras/target/dependency/commons-logging-1.1.1.jar
[licenses] MISSING sha1 checksum file for:
/home/rmuir/workspace/lucene-trunk/maven-build/solr/contrib/analysis-extras/target/dependency/hamcrest-core-1.1.jar
[licenses] MISSING sha1 checksum file for:
/home/rmuir/workspace/lucene-trunk/maven-build/solr/contrib/analysis-extras/target/dependency/javax.servlet-3.0.0.v201112011016.jar
[licenses] MISSING sha1 checksum file for:
/home/rmuir/workspace/lucene-trunk/maven-build/solr/contrib/analysis-extras/target/dependency/servlet-api-2.4.jar
[licenses] MISSING sha1 checksum file for:
/home/rmuir/workspace/lucene-trunk/maven-build/solr/contrib/clustering/target/dependency/ehcache-core-1.7.2.jar
[licenses] MISSING sha1 checksum file for:
/home/rmuir/workspace/lucene-trunk/maven-build/solr/contrib/clustering/target/dependency/jdom-1.1.jar
[licenses] MISSING sha1 checksum file for:
/home/rmuir/workspace/lucene-trunk/maven-build/solr/contrib/clustering/target/dependency/morfologik-stemming-1.5.1.jar
[licenses] MISSING sha1 checksum file for:
/home/rmuir/workspace/lucene-trunk/maven-build/solr/contrib/clustering/target/dependency/rome-1.0.0.jar
[licenses] MISSING sha1 checksum file for:
/home/rmuir/workspace/lucene-trunk/maven-build/solr/contrib/clustering/target/dependency/rome-fetcher-1.0.0.jar
{noformat}
add validate-maven task to check maven dependencies
---
Key: LUCENE-4354
URL: https://issues.apache.org/jira/browse/LUCENE-4354
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Attachments: LUCENE-4354.patch
We had a situation where the maven artifacts depended on the wrong version of
tika: we should test that the maven dependencies are correct.
An easy way to do this is to force it to download all of its dependencies,
and then run our existing license checks over that.
This currently fails: maven is bringing in some extra 3rd party libraries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447617#comment-13447617 ] Chris Male commented on LUCENE-4354: hamcrest is a transitive dependency of junit, we'll need to exclude that specifically in our poms. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4353) Document deletions not applied to non-flushed segments
[ https://issues.apache.org/jira/browse/LUCENE-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-4353. - Resolution: Not A Problem You are passing null to the liveDocs argument instead of the indexreader's liveDocs (thus ignoring deletions). Document deletions not applied to non-flushed segments -- Key: LUCENE-4353 URL: https://issues.apache.org/jira/browse/LUCENE-4353 Project: Lucene - Core Issue Type: Bug Components: core/index Reporter: Sivan Yogev Fix For: 5.0 Attachments: TestNonFlushedSegmentDeletion.java Original Estimate: 336h Remaining Estimate: 336h Document deletions seems not to be applied to the current in-memory segments, only to flushed ones. Adding a test which fails on this, adding a commit before deletion makes the test pass. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447622#comment-13447622 ] Robert Muir commented on LUCENE-4354: - Yeah some of this might be false fails. i just wanted to get it up here as a prototype. I think its a good check we could add to e.g. our nightly jenkins runs once we get it sorted out to prevent problems. Its true running the tests with maven is good: but this would fail in a more obvious way (e.g. the tika situation), and wouldn't rely upon having tests that ensure all dependencies are correct (I know we don't have this today!) add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4352) only the test runner should be able to System.exit
[ https://issues.apache.org/jira/browse/LUCENE-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447625#comment-13447625 ] Robert Muir commented on LUCENE-4352: - Thanks for working on this! only the test runner should be able to System.exit -- Key: LUCENE-4352 URL: https://issues.apache.org/jira/browse/LUCENE-4352 Project: Lucene - Core Issue Type: Bug Components: general/test Affects Versions: 4.0-BETA Reporter: Robert Muir Assignee: Uwe Schindler Fix For: 5.0, 4.0 Attachments: LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch, LUCENE-4352.patch All others should get SecurityException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447628#comment-13447628 ] selckin commented on LUCENE-4354: - If you add '-DincludeScope=runtime' to the copy call, quite a few disappear, one hamcrest still there, probably from test-framework ? Also ant clean doesn't remove the copied jars add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447630#comment-13447630 ] Robert Muir commented on LUCENE-4354: - I think any dependencies should be checked? I don't think we should hide ones only used for test-framework or whatever (its still a maven artifact published out there, unless that is intended to change). 'ant clean' doesnt remove anything maven-related: there is a maven-related clean task (clean-maven-build) that does that, I think its documented in the README.maven add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447634#comment-13447634 ] Chris Male commented on LUCENE-4354: Ignoring the scope issue, the validation has revealed valid issues. For example the jdom, rome and servlet dependencies all have different versions to our license files. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447633#comment-13447633 ] selckin commented on LUCENE-4354: - Well only things from the runtime scope will end up in the war, and i thought i saw other issues where the policy was to ignore license and other checks for build only jars. But i guess it can't hurt to force all the deps to be the same, so ignore me add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4355) improve AtomicReader sugar apis
Robert Muir created LUCENE-4355: --- Summary: improve AtomicReader sugar apis Key: LUCENE-4355 URL: https://issues.apache.org/jira/browse/LUCENE-4355 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir I thought about this after looking @ LUCENE-4353: AtomicReader has some sugar APIs that are over top of the flex apis (Fields, Terms, ...). But these might be a little trappy/confusing compared to 3.x. # I dont think we need AtomicReader.termDocsEnum(Bits, ...) and .termPositionsEnum(Bits, ...). I also don't think we need variants that take flags here. We should simplify these to be less trappy. I think we only need (String, BytesRef) here. # This means you need to use the flex apis for more expert usage: but we make this a bit too hard since we only let you get a Terms (which you must null check, then call .iterator() on, then seekExact, ...). I think it could help if we balanced this out by adding some sugar like AtomicReader.termsEnum? 3.x had a method that let you get a 'positioned termsenum'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447638#comment-13447638 ] Chris Male commented on LUCENE-4354: It's not just an issue of what ends up in the war since we also publish individual artifacts / poms. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447639#comment-13447639 ] Robert Muir commented on LUCENE-4354: - Right, the check here is the same set of license exclusions etc used for the 'normal artifacts' that are put on the apache download site. Maven shouldnt have any extra dependencies beyond that. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[
https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447640#comment-13447640
]
Uwe Schindler commented on LUCENE-4354:
---
There is a trick with maven-ant-tasks to get a refid to a fileset/ with all
maven dependencies (something like that, maybe Steven knows how to set this up):
{code:xml}
maven:dependencies xmlns:maven=urn:maven-artifact-ant
filesetId=foobar.fileset useScope=runtime/
{code}
After that the ANT fileset should point (like ivy:cachefilset) to all
dependency jars. It should be easy to run the license checker on top of this
fileset (refid=foobar.fileset).
See also for a code example:
http://ptrthomas.wordpress.com/2009/03/08/why-you-should-use-the-maven-ant-tasks-instead-of-maven-or-ivy/
add validate-maven task to check maven dependencies
---
Key: LUCENE-4354
URL: https://issues.apache.org/jira/browse/LUCENE-4354
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Attachments: LUCENE-4354.patch
We had a situation where the maven artifacts depended on the wrong version of
tika: we should test that the maven dependencies are correct.
An easy way to do this is to force it to download all of its dependencies,
and then run our existing license checks over that.
This currently fails: maven is bringing in some extra 3rd party libraries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447641#comment-13447641 ] Robert Muir commented on LUCENE-4354: - Thanks Uwe... this looks like the way to go to remove the mvn.exe hack :) add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3782) A leader going down while updates are coming in can cause shard inconsistency.
[ https://issues.apache.org/jira/browse/SOLR-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447644#comment-13447644 ] Markus Jelsma commented on SOLR-3782: - hi - this is in CHANGES but is it resolved? A leader going down while updates are coming in can cause shard inconsistency. -- Key: SOLR-3782 URL: https://issues.apache.org/jira/browse/SOLR-3782 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.0, 5.0 Harpoon into the head of the great whale I have been chasing for a couple weeks now. ChaosMonkey test was exposing this. Turns out the problem was the solr cmd distrib executor - when closing the leader CoreContainer, we would close the zkController while updates can still flow through the distrib executor. The result was that we would send updates from the leader briefly even though there was a new leader. I had suspected something similar to this at one point in the hunt and started adding some defensive state checks that we wanted to add anyway. I don't think they caught all of this issue due to the limited tightness one of the state checks can get to (checking the cloudstate leader from a replica against the leader indicated by the request). So the answer is to finally work out how to stop the solr cmd distrib executor - because we need to stop it before closing zkController and giving up our role as leader. I've worked that all out and the issue no longer seems to be a problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4355) improve AtomicReader sugar apis
[ https://issues.apache.org/jira/browse/LUCENE-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447649#comment-13447649 ] Uwe Schindler commented on LUCENE-4355: --- I would start with removing all these APIs except fields() from AtomicReader, fix all tests and then readd useful ones (useful for enduser). improve AtomicReader sugar apis --- Key: LUCENE-4355 URL: https://issues.apache.org/jira/browse/LUCENE-4355 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir I thought about this after looking @ LUCENE-4353: AtomicReader has some sugar APIs that are over top of the flex apis (Fields, Terms, ...). But these might be a little trappy/confusing compared to 3.x. # I dont think we need AtomicReader.termDocsEnum(Bits, ...) and .termPositionsEnum(Bits, ...). I also don't think we need variants that take flags here. We should simplify these to be less trappy. I think we only need (String, BytesRef) here. # This means you need to use the flex apis for more expert usage: but we make this a bit too hard since we only let you get a Terms (which you must null check, then call .iterator() on, then seekExact, ...). I think it could help if we balanced this out by adding some sugar like AtomicReader.termsEnum? 3.x had a method that let you get a 'positioned termsenum'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4354: Attachment: LUCENE-4354_hacked_lucene_only.patch I hacked this up a little bit for lucene/ to try to use the maven-ant-tasks fileset as Uwe suggested. It doesn't totally work: it seems to only be looking at lucene-core but not working 'recursively' on all the lucene modules. I didnt touch solr yet. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4355) improve AtomicReader sugar apis
[ https://issues.apache.org/jira/browse/LUCENE-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447666#comment-13447666 ] Robert Muir commented on LUCENE-4355: - I agree, this was mainly to start discussion about what sugar apis we should have. Currently its very inconsistent. IndexReader: * docFreq(Term) - forwards to docFreq(String, BytesRef) * docFreq(String, BytesRef) - (abstract: this can be seen as a sugar API) AtomicReader: * totalTermFreq(String, BytesRef) - strange to be treated differently than docFreq, sugar to seekExact+totalTermFreq * terms(String) - note that in 3.x terms() and terms(Term) are different and go to TermsEnum (unpositioned and positioned) * termDocsEnum(Bits, String, BytesRef) - the Bits should be implicit in the reader. if you want your own bits use flex apis? * termDocsEnum(Bits, String, BytesRef, int) - flags seems too expert * termPositionsEnum(Bits, String, BytesRef) * termPositionsEnum(Bits, String, BytesRef, int) So we should also discuss whether its useful to use Term at the indexReader level. If we are going to have sugar for docFreq(Term) then we should do this elsewhere too? Term is somewhat nice because it means users don't have to deal with BytesRef etc. I wonder if totalTermFreq sugar is necessary here too, if we instead make it easy for you to get a positioned termsenum for a specific term (you could just call it yourself then). We should also think about the names termDocsEnum/termPositionsEnum. in 3.x these were termDocs() and termPositions(), and could take Term. The only thing I feel pretty strongly about is that I think passing a custom Bits is too expert for these sugar APIs, as its something implicit from the Reader itself. improve AtomicReader sugar apis --- Key: LUCENE-4355 URL: https://issues.apache.org/jira/browse/LUCENE-4355 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir I thought about this after looking @ LUCENE-4353: AtomicReader has some sugar APIs that are over top of the flex apis (Fields, Terms, ...). But these might be a little trappy/confusing compared to 3.x. # I dont think we need AtomicReader.termDocsEnum(Bits, ...) and .termPositionsEnum(Bits, ...). I also don't think we need variants that take flags here. We should simplify these to be less trappy. I think we only need (String, BytesRef) here. # This means you need to use the flex apis for more expert usage: but we make this a bit too hard since we only let you get a Terms (which you must null check, then call .iterator() on, then seekExact, ...). I think it could help if we balanced this out by adding some sugar like AtomicReader.termsEnum? 3.x had a method that let you get a 'positioned termsenum'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] selckin updated LUCENE-4354: Attachment: LUCENE-4354-dep-fix.patch fixes some deps (ran with runtime scope) - servlet-api is confusing me - warns about common-compress in some solr contribs but it is the correct version add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447673#comment-13447673 ] Uwe Schindler commented on LUCENE-4354: --- Robert: Maybe we do the check per module? We can do this after the create-maven-artifacts module target. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3785) Cluster-state inconsistent
Per Steffensen created SOLR-3785:
Summary: Cluster-state inconsistent
Key: SOLR-3785
URL: https://issues.apache.org/jira/browse/SOLR-3785
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: Self-build Solr release built on Apache Solr revision
1355667 from 4.x branch
Reporter: Per Steffensen
Information in CloudSolrServer.getZkStateReader().getCloudState() (called
cloudState below) seems to be inconsistent.
I have a Solr running the leader of slice sliceName in collection
collectionName - no replica to take over. I shut down this Solr, and I want
to detect that there is now no leader active.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE);
{code}
This does not work. It seems like changing state of a shard does it not changed
when this Solr goes down.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE) ||
!leader.containsKey(ZkStateReader.NODE_NAME_PROP) ||
!cloudState.getLiveNodes().contains(leader.get(ZkStateReader.NODE_NAME_PROP))
{code}
Whis works.
It seems like live-nodes of cloudState is updated when Solr goes down, but that
some of the other info available through cloudState is not - e.g. getLeader().
This might already have already been solved on 4.x branch in a revision later
than 1355667. Then please just tell me - thanks.
Regards, Per Steffensen
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4354: Attachment: LUCENE-4354.patch Good idea Uwe! Here is a new patch doing that. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3785) Cluster-state inconsistent
[
https://issues.apache.org/jira/browse/SOLR-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447688#comment-13447688
]
Mark Miller commented on SOLR-3785:
---
Well, I added something like this last week, but I'm not sure it covers the
case where there is no other replica to take over as leader.
Last week, I noticed that when a leader goes down, no one removes the leader
marker from the cluster state. I changed it so that the next candidate leader
immediately does this before the leader election process kicks off - this lets
you see the leader briefly go away until a new leader is elected. There has to
be another leader candidate to publish that change currently though (this was
an easy add, that's why I did it that way).
To get it to work where there is no new leader candidate, we have to change it
so that the overseer does this I think.
Thoughts Sami?
Cluster-state inconsistent
--
Key: SOLR-3785
URL: https://issues.apache.org/jira/browse/SOLR-3785
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: Self-build Solr release built on Apache Solr revision
1355667 from 4.x branch
Reporter: Per Steffensen
Information in CloudSolrServer.getZkStateReader().getCloudState() (called
cloudState below) seems to be inconsistent.
I have a Solr running the leader of slice sliceName in collection
collectionName - no replica to take over. I shut down this Solr, and I want
to detect that there is now no leader active.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE);
{code}
This does not work. It seems like changing state of a shard does it not
changed when this Solr goes down.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE) ||
!leader.containsKey(ZkStateReader.NODE_NAME_PROP) ||
!cloudState.getLiveNodes().contains(leader.get(ZkStateReader.NODE_NAME_PROP))
{code}
Whis works.
It seems like live-nodes of cloudState is updated when Solr goes down, but
that some of the other info available through cloudState is not - e.g.
getLeader().
This might already have already been solved on 4.x branch in a revision later
than 1355667. Then please just tell me - thanks.
Regards, Per Steffensen
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447691#comment-13447691 ] Robert Muir commented on LUCENE-4354: - Thanks selckin: I think I will let Steve or someone more familiar review your patch. About the commons-compress: there is a problem somewhere. Some things are depending on 1.2 and others on 1.3. But nothing should be depending on 1.2: Thats causing the failure. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
SolrCloud terminology issue: slice vs. shard
I have seen a couple of Jira’s go by in the past few days that bring up the term “slice” in the context of SolrCloud. It was my understanding that the preferred term is now “shard”. The wiki is pure “shard” and the code still has a mix, but is “slice” now making a comeback as the preferred term? Or, is the intent simply for “shard” and “slice” to be considered synonyms? -- Jack Krupansky
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[
https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447698#comment-13447698
]
Uwe Schindler commented on LUCENE-4354:
---
Looks fine, works almost on windows, stupidity is the restrict thing that
matches also on the file separator:
{code:xml}
rsel:not
rsel:or
rsel:name name=**/lucene-*.jar handledirsep=true/
rsel:name name=**/solr-*.jar handledirsep=true/
/rsel:or
/rsel:not
{code}
The handledirsep=true is the needed magic. Otherwise looks fine, only some
dependnecies are wrong.
add validate-maven task to check maven dependencies
---
Key: LUCENE-4354
URL: https://issues.apache.org/jira/browse/LUCENE-4354
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Attachments: LUCENE-4354-dep-fix.patch,
LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch
We had a situation where the maven artifacts depended on the wrong version of
tika: we should test that the maven dependencies are correct.
An easy way to do this is to force it to download all of its dependencies,
and then run our existing license checks over that.
This currently fails: maven is bringing in some extra 3rd party libraries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3785) Cluster-state inconsistent
[
https://issues.apache.org/jira/browse/SOLR-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447709#comment-13447709
]
Per Steffensen commented on SOLR-3785:
--
I guess in my version (revision 1355667) of the code, ZkStateReader is not even
watching /collections/collection-name/leaders/. It is watching /live_nodes/.
But I guess what you are telling me is, that even though ZkStateReader was
watching /collections/collection-name/leaders/ it might not be notified that
the leader has gone unless there is another one taking over?
Did you change it so that /collections/collection-name/leaders/ is watched?
So that only thing left is to make sure the leader-marker is removed even if
there is no other to take over.
Regards, Per Steffensen
Cluster-state inconsistent
--
Key: SOLR-3785
URL: https://issues.apache.org/jira/browse/SOLR-3785
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: Self-build Solr release built on Apache Solr revision
1355667 from 4.x branch
Reporter: Per Steffensen
Information in CloudSolrServer.getZkStateReader().getCloudState() (called
cloudState below) seems to be inconsistent.
I have a Solr running the leader of slice sliceName in collection
collectionName - no replica to take over. I shut down this Solr, and I want
to detect that there is now no leader active.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE);
{code}
This does not work. It seems like changing state of a shard does it not
changed when this Solr goes down.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE) ||
!leader.containsKey(ZkStateReader.NODE_NAME_PROP) ||
!cloudState.getLiveNodes().contains(leader.get(ZkStateReader.NODE_NAME_PROP))
{code}
Whis works.
It seems like live-nodes of cloudState is updated when Solr goes down, but
that some of the other info available through cloudState is not - e.g.
getLeader().
This might already have already been solved on 4.x branch in a revision later
than 1355667. Then please just tell me - thanks.
Regards, Per Steffensen
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: SolrCloud terminology issue: slice vs. shard
On Tue, Sep 4, 2012 at 9:51 AM, Jack Krupansky j...@basetechnology.com wrote: I have seen a couple of Jira’s go by in the past few days that bring up the term “slice” in the context of SolrCloud. It was my understanding that the preferred term is now “shard”. The wiki is pure “shard” and the code still has a mix, but is “slice” now making a comeback as the preferred term? Or, is the intent simply for “shard” and “slice” to be considered synonyms? -- Jack Krupansky Until we agree on a firm stance, the current state of affairs is this: Slice always means logical shard. Shard means logical or physical shard by context. We usually use only shard in doc and slice in code. Sometimes, because context may be a less than clear guide, slice is used in email/jira. I've tried to firm this up before, but that is where we ended up sitting for a while now. -- - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4354: Attachment: LUCENE-4354.patch Updated patch: * added workCorrectlyOnWindows=true as Uwe suggested * incorporated selckin's patch. its now passing on lucene/. I will investigate solr/ now (not tested yet) add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3785) Cluster-state inconsistent
[
https://issues.apache.org/jira/browse/SOLR-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447711#comment-13447711
]
Mark Miller commented on SOLR-3785:
---
bq.
I guess in my version (revision 1355667) of the code, ZkStateReader is not even
watching /collections/collection-name/leaders/. It is watching /live_nodes/.
The overseer watches leader I believe - and publishes results to the
clusterstate.json.
bq. But I guess what you are telling me is, that even though ZkStateReader was
watching /collections/collection-name/leaders/ it might not be notified that
the leader has gone unless there is another one taking over?
Only as of a few days go. The next candidate to take over immediately publishes
a null leader which clears it from clusterstate.json
bq. Did you change it so that /collections/collection-name/leaders/ is
watched? So that only thing left is to make sure the leader-marker is removed
even if there is no other to take over.
It's already watched by the Overseer. The change is to make the Overseer remove
leaders from ClusterState.json the same way it adds them.
Cluster-state inconsistent
--
Key: SOLR-3785
URL: https://issues.apache.org/jira/browse/SOLR-3785
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: Self-build Solr release built on Apache Solr revision
1355667 from 4.x branch
Reporter: Per Steffensen
Information in CloudSolrServer.getZkStateReader().getCloudState() (called
cloudState below) seems to be inconsistent.
I have a Solr running the leader of slice sliceName in collection
collectionName - no replica to take over. I shut down this Solr, and I want
to detect that there is now no leader active.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE);
{code}
This does not work. It seems like changing state of a shard does it not
changed when this Solr goes down.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE) ||
!leader.containsKey(ZkStateReader.NODE_NAME_PROP) ||
!cloudState.getLiveNodes().contains(leader.get(ZkStateReader.NODE_NAME_PROP))
{code}
Whis works.
It seems like live-nodes of cloudState is updated when Solr goes down, but
that some of the other info available through cloudState is not - e.g.
getLeader().
This might already have already been solved on 4.x branch in a revision later
than 1355667. Then please just tell me - thanks.
Regards, Per Steffensen
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-3785) Cluster-state inconsistent
[
https://issues.apache.org/jira/browse/SOLR-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447711#comment-13447711
]
Mark Miller edited comment on SOLR-3785 at 9/5/12 1:14 AM:
---
bq. I guess in my version (revision 1355667) of the code, ZkStateReader is not
even watching /collections/collection-name/leaders/. It is watching
/live_nodes/.
The overseer watches /leaders I believe - and publishes results to the
clusterstate.json.
bq. But I guess what you are telling me is, that even though ZkStateReader was
watching /collections/collection-name/leaders/ it might not be notified that
the leader has gone unless there is another one taking over?
Only as of a few days go. The next candidate to take over immediately publishes
a null leader which clears it from clusterstate.json
bq. Did you change it so that /collections/collection-name/leaders/ is
watched? So that only thing left is to make sure the leader-marker is removed
even if there is no other to take over.
It's already watched by the Overseer. The change is to make the Overseer remove
leaders from ClusterState.json the same way it adds them.
was (Author: markrmil...@gmail.com):
bq.
I guess in my version (revision 1355667) of the code, ZkStateReader is not even
watching /collections/collection-name/leaders/. It is watching /live_nodes/.
The overseer watches leader I believe - and publishes results to the
clusterstate.json.
bq. But I guess what you are telling me is, that even though ZkStateReader was
watching /collections/collection-name/leaders/ it might not be notified that
the leader has gone unless there is another one taking over?
Only as of a few days go. The next candidate to take over immediately publishes
a null leader which clears it from clusterstate.json
bq. Did you change it so that /collections/collection-name/leaders/ is
watched? So that only thing left is to make sure the leader-marker is removed
even if there is no other to take over.
It's already watched by the Overseer. The change is to make the Overseer remove
leaders from ClusterState.json the same way it adds them.
Cluster-state inconsistent
--
Key: SOLR-3785
URL: https://issues.apache.org/jira/browse/SOLR-3785
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: Self-build Solr release built on Apache Solr revision
1355667 from 4.x branch
Reporter: Per Steffensen
Information in CloudSolrServer.getZkStateReader().getCloudState() (called
cloudState below) seems to be inconsistent.
I have a Solr running the leader of slice sliceName in collection
collectionName - no replica to take over. I shut down this Solr, and I want
to detect that there is now no leader active.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE);
{code}
This does not work. It seems like changing state of a shard does it not
changed when this Solr goes down.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE) ||
!leader.containsKey(ZkStateReader.NODE_NAME_PROP) ||
!cloudState.getLiveNodes().contains(leader.get(ZkStateReader.NODE_NAME_PROP))
{code}
Whis works.
It seems like live-nodes of cloudState is updated when Solr goes down, but
that some of the other info available through cloudState is not - e.g.
getLeader().
This might already have already been solved on 4.x branch in a revision later
than 1355667. Then please just tell me - thanks.
Regards, Per Steffensen
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447712#comment-13447712 ] selckin commented on LUCENE-4354: - Since transitive dependencies are ignored so aggressively, how about the reverse? dependencies present in lucene but not in maven? Tests should catch mosts of them i guess? add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447714#comment-13447714 ] Chris Male commented on LUCENE-4354: Yeah I think tests should be catching them. Do you have any examples? add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447716#comment-13447716 ] Robert Muir commented on LUCENE-4354: - selckin: that problem is more than maven actually, e.g. things like SOLR-3736. Really you are right, if we have a dependency we should be testing that its working :) But its good to check the inverse, at least we know we are not depending on things we didnt know about, or the wrong versions: this only complements that. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3785) Cluster-state inconsistent
[
https://issues.apache.org/jira/browse/SOLR-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447717#comment-13447717
]
Sami Siren commented on SOLR-3785:
--
bq. The overseer watches /leaders I believe - and publishes results to the
clusterstate.json.
The leader is announced by the new shard leader
(ShardLeaderElectionContextBase). It adds the leader type of even with the
required details into overseer queue. There are no watches related to this in
overseer atm. Looks like we need to add one so that the leader=true can be
cleared by overseer from clusterstate.json when the leader nodes change/go away.
perhaps we could also rearrange the hierarchy slightly so that we could get
away with only 1 watch:
/leaders/collection-name-slice-name
Cluster-state inconsistent
--
Key: SOLR-3785
URL: https://issues.apache.org/jira/browse/SOLR-3785
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: Self-build Solr release built on Apache Solr revision
1355667 from 4.x branch
Reporter: Per Steffensen
Information in CloudSolrServer.getZkStateReader().getCloudState() (called
cloudState below) seems to be inconsistent.
I have a Solr running the leader of slice sliceName in collection
collectionName - no replica to take over. I shut down this Solr, and I want
to detect that there is now no leader active.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE);
{code}
This does not work. It seems like changing state of a shard does it not
changed when this Solr goes down.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE) ||
!leader.containsKey(ZkStateReader.NODE_NAME_PROP) ||
!cloudState.getLiveNodes().contains(leader.get(ZkStateReader.NODE_NAME_PROP))
{code}
Whis works.
It seems like live-nodes of cloudState is updated when Solr goes down, but
that some of the other info available through cloudState is not - e.g.
getLeader().
This might already have already been solved on 4.x branch in a revision later
than 1355667. Then please just tell me - thanks.
Regards, Per Steffensen
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-1549) SqlEntityProcessor does not recognize onError attribute
[ https://issues.apache.org/jira/browse/SOLR-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer resolved SOLR-1549. -- Resolution: Won't Fix Closing for now as this issue has not generated interest. It doesn't seem wise to try to continue if there is an SqlException. SqlEntityProcessor does not recognize onError attribute --- Key: SOLR-1549 URL: https://issues.apache.org/jira/browse/SOLR-1549 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Affects Versions: 1.4, 1.5 Reporter: Sascha Szott Assignee: James Dyer Priority: Minor Attachments: SOLR-1549.patch Unfortunately, the SqlEntityProcessor does not recognize the value of an entity's onError attribute in DIH's data config file. Therefore, in cases where SQL exceptions are thrown somewhere inside the constructor of ResultSetIterators (which is an inner class of JdbcDataSource), Solr's import exits immediately, even though onError is set to continue or skip. In my opinion, use cases exist that will profit from database related exception handling inside of Solr (e.g., in cases where the existence of certain database tables or views is not predictable). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3782) A leader going down while updates are coming in can cause shard inconsistency.
[ https://issues.apache.org/jira/browse/SOLR-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447721#comment-13447721 ] Mark Miller commented on SOLR-3782: --- I committed a first iteration - I have more refinement/improvement coming. A leader going down while updates are coming in can cause shard inconsistency. -- Key: SOLR-3782 URL: https://issues.apache.org/jira/browse/SOLR-3782 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.0, 5.0 Harpoon into the head of the great whale I have been chasing for a couple weeks now. ChaosMonkey test was exposing this. Turns out the problem was the solr cmd distrib executor - when closing the leader CoreContainer, we would close the zkController while updates can still flow through the distrib executor. The result was that we would send updates from the leader briefly even though there was a new leader. I had suspected something similar to this at one point in the hunt and started adding some defensive state checks that we wanted to add anyway. I don't think they caught all of this issue due to the limited tightness one of the state checks can get to (checking the cloudstate leader from a replica against the leader indicated by the request). So the answer is to finally work out how to stop the solr cmd distrib executor - because we need to stop it before closing zkController and giving up our role as leader. I've worked that all out and the issue no longer seems to be a problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-1426) Allow delta-import to run continously until aborted
[ https://issues.apache.org/jira/browse/SOLR-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer resolved SOLR-1426. -- Resolution: Won't Fix Closing for now as this doesn't seem like the best approach to handling NRT with DIH. Can be reopened if someone wants to pursue this again. Allow delta-import to run continously until aborted --- Key: SOLR-1426 URL: https://issues.apache.org/jira/browse/SOLR-1426 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Affects Versions: 1.4 Reporter: Abdul Chaudhry Assignee: James Dyer Attachments: delta-import-perpetual.patch Modify the delta-import so that it takes a perpetual flag that makes it run continuously until its aborted. http://localhost:8985/solr/select/?command=delta-importclean=falseqt=/dataimportcommit=trueperpetual=true perpetual means the delta import will keep running and pause for a few seconds when running queries. The only way to stop delta import will be to explicitly issue an abort like so:- http://localhost:8985/solr/tickets/select/?command=abort -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-1787) Add ability to configure behavior of cache miss to CachedSqlEntityProcessor
[ https://issues.apache.org/jira/browse/SOLR-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer resolved SOLR-1787. -- Resolution: Won't Fix Assignee: (was: Noble Paul) Closing as this is an old issue with little activity. This can be reopened if someone wants to pursue this again later. Add ability to configure behavior of cache miss to CachedSqlEntityProcessor --- Key: SOLR-1787 URL: https://issues.apache.org/jira/browse/SOLR-1787 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Affects Versions: 1.5 Environment: jdk 1.6.x, windows xp, tomcat 6.x Reporter: Michael Henson Priority: Minor Labels: dih Attachments: solr-1787.patch The CachedSqlEntityProcessor currently builds a cache of rows it sees as it goes, so later requests for that same key can be served from data that has already been fetched. The primary query could be written to fetch all possible rows, which would then be set into the cache on the first request for a row. In that case the database would only receive another query when there is a cache miss. However, the query it would execute is the one that pulls all rows, negating any performance gain. This patch adds the ability to configure behavior on cache miss with the onCacheMiss attribute on an entity tag in the data-config.xml file. The current behavior is the default, corresponding to the setting onCacheMiss=fill. Any other value explicitly given for onCacheMiss will cause cache misses to be ignored - no query will be made to the db to fulfill them. I've encountered two cases where this capability is useful: 1. Relatively small datasets, such as category id - category name mappings, which will not change during the course of indexing. 2. Queries which are heavy on db resources per-query, particularly if the query for an individual record is slow, and can't be fixed easily on the db side for whatever reason. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3785) Cluster-state inconsistent
[
https://issues.apache.org/jira/browse/SOLR-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447725#comment-13447725
]
Mark Miller commented on SOLR-3785:
---
Ah, right, thanks. Now I remember seeing that. Probably part of why I went the
route I did for clearing it.
bq. /leaders/collection-name-slice-name
That's probably fine?
Cluster-state inconsistent
--
Key: SOLR-3785
URL: https://issues.apache.org/jira/browse/SOLR-3785
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: Self-build Solr release built on Apache Solr revision
1355667 from 4.x branch
Reporter: Per Steffensen
Information in CloudSolrServer.getZkStateReader().getCloudState() (called
cloudState below) seems to be inconsistent.
I have a Solr running the leader of slice sliceName in collection
collectionName - no replica to take over. I shut down this Solr, and I want
to detect that there is now no leader active.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE);
{code}
This does not work. It seems like changing state of a shard does it not
changed when this Solr goes down.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE) ||
!leader.containsKey(ZkStateReader.NODE_NAME_PROP) ||
!cloudState.getLiveNodes().contains(leader.get(ZkStateReader.NODE_NAME_PROP))
{code}
Whis works.
It seems like live-nodes of cloudState is updated when Solr goes down, but
that some of the other info available through cloudState is not - e.g.
getLeader().
This might already have already been solved on 4.x branch in a revision later
than 1355667. Then please just tell me - thanks.
Regards, Per Steffensen
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3611) We do not show ZooKeeper data in the UI for a node that has children.
[
https://issues.apache.org/jira/browse/SOLR-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447731#comment-13447731
]
Yonik Seeley commented on SOLR-3611:
It looks like the data should be returned by the /zookeeper handler, so it
looks like we just need a fix to the UI.
curl $URL/zookeeper?detail=truepath=/collections/collection1
{code}
{znode:{
path:/collections/collection1,prop:{
version:0,
aversion:0,
children_count:2,
ctime:Mon Sep 03 15:17:42 EDT 2012 (1346699862200),
cversion:2,
czxid:109,
dataLength:23,
ephemeralOwner:0,
mtime:Mon Sep 03 15:17:42 EDT 2012 (1346699862200),
mzxid:109,
pzxid:126},
data:{\configName\:\myconf\}},tree:[{data:{
{code}
We do not show ZooKeeper data in the UI for a node that has children.
-
Key: SOLR-3611
URL: https://issues.apache.org/jira/browse/SOLR-3611
Project: Solr
Issue Type: Bug
Components: SolrCloud, web gui
Reporter: Mark Miller
Priority: Minor
Fix For: 4.0
There is sometimes useful data at these nodes.
For example, /collections/collection1 will have children nodes, but it also
has data as well - some json that links the collection to the config name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3785) Cluster-state inconsistent
[
https://issues.apache.org/jira/browse/SOLR-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447733#comment-13447733
]
Per Steffensen commented on SOLR-3785:
--
{quote}
It's already watched by the Overseer. The change is to make the Overseer remove
leaders from ClusterState.json the same way it adds them.
{quote}
Hmmm, not in my version (revision 1355667 on 4.x branch), I guess??? I cant
find it in the code at least, but I might be wrong. The only thing I can see
Overseer watching is /overseer/queue (and /overseer/queue-work), and the
only ones I can find putting something in there is ZkController.publish and
ElectionContext.runLeaderProcess which seems to only be used on startup,
reconnect, recovery, leader-election etc, and not by any leaders-watcher. But
again, I might very well be wrong.
Fact is that clusterstate.json in ZK and clusterState on
CloudSolrServer.getZkStateReader().getCloudState() keeps reporting the shards
on the shut-down Solr as active (in revision 1355667 of 4.x branch).
Live-nodes in ZK and on CloudSolrServer.getZkStateReader().getCloudState()
reports the Solr down correctly.
Regards, Per Steffensen
Cluster-state inconsistent
--
Key: SOLR-3785
URL: https://issues.apache.org/jira/browse/SOLR-3785
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: Self-build Solr release built on Apache Solr revision
1355667 from 4.x branch
Reporter: Per Steffensen
Information in CloudSolrServer.getZkStateReader().getCloudState() (called
cloudState below) seems to be inconsistent.
I have a Solr running the leader of slice sliceName in collection
collectionName - no replica to take over. I shut down this Solr, and I want
to detect that there is now no leader active.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE);
{code}
This does not work. It seems like changing state of a shard does it not
changed when this Solr goes down.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE) ||
!leader.containsKey(ZkStateReader.NODE_NAME_PROP) ||
!cloudState.getLiveNodes().contains(leader.get(ZkStateReader.NODE_NAME_PROP))
{code}
Whis works.
It seems like live-nodes of cloudState is updated when Solr goes down, but
that some of the other info available through cloudState is not - e.g.
getLeader().
This might already have already been solved on 4.x branch in a revision later
than 1355667. Then please just tell me - thanks.
Regards, Per Steffensen
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447736#comment-13447736 ] Uwe Schindler commented on LUCENE-4354: --- Looks fine now for Lucene! For consistency with the other maven macros, i would rename macrodef name=validate-maven-dependencies to macrodef name=m2-validate-dependencies, then it is consistent with others. And maybe move it up to be next to each other, so not distributes over whole common-build.xml. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3755) shard splitting
[ https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447738#comment-13447738 ] Mark Miller commented on SOLR-3755: --- Yeah, I like the first option as well. shard splitting --- Key: SOLR-3755 URL: https://issues.apache.org/jira/browse/SOLR-3755 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Yonik Seeley Attachments: SOLR-3755.patch, SOLR-3755.patch We can currently easily add replicas to handle increases in query volume, but we should also add a way to add additional shards dynamically by splitting existing shards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[
https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447739#comment-13447739
]
Uwe Schindler commented on LUCENE-4354:
---
One thing that is annoying:
{noformat}
dist-maven-common:
[artifact:dependencies] [INFO] snapshot
org.apache.lucene:lucene-core:5.0-SNAPSHOT: checking for updates from
sonatype.releases
[artifact:dependencies] [INFO] snapshot
org.apache.lucene:lucene-core:5.0-SNAPSHOT: checking for updates from
apache.snapshots
[artifact:dependencies] Downloading:
org/apache/lucene/lucene-core/5.0-SNAPSHOT/lucene-core-5.0-20120903.170333-49.pom
from reposito
ry apache.snapshots at http://repository.apache.org/snapshots
[artifact:dependencies] Downloading:
org/apache/lucene/lucene-core/5.0-SNAPSHOT/lucene-core-5.0-20120903.170333-49.jar
from reposito
ry apache.snapshots at http://repository.apache.org/snapshots
[artifact:dependencies] Transferring 2200K from apache.snapshots
[echo] Checking Maven dependencies for C:\Users\Uwe
Schindler\Projects\lucene\trunk-lusolr2\lucene\build\poms\lucene\test-frame
work\pom.xml:
com\carrotsearch\randomizedtesting\randomizedtesting-runner\2.0.0.rc5\randomizedtesting-runner-2.0.0.rc5.jar;junit\jun
it\4.10\junit-4.10.jar;org\apache\lucene\lucene-core\5.0-SNAPSHOT\lucene-core-5.0-20120903.170333-49.jar
[licenses] Scanned 2 JAR file(s) for licenses (in 0.01s.), 0 error(s).
[artifact:install-provider] Installing provider:
org.apache.maven.wagon:wagon-ssh:jar:1.0-beta-7:runtime
[artifact:deploy] Deploying to file://C:\Users\Uwe
Schindler\Projects\lucene\trunk-lusolr2\lucene\dist\maven
[artifact:deploy] [INFO] Retrieving previous build number from
${m2.repository.id}
[artifact:deploy] [INFO] repository metadata for: 'snapshot
org.apache.lucene:lucene-test-framework:5.0-SNAPSHOT' could not be found
on repository: ${m2.repository.id}, so will be created
[artifact:deploy] Uploading:
org/apache/lucene/lucene-test-framework/5.0-SNAPSHOT/lucene-test-framework-5.0-20120904.150305-1.jar
to
repository ${m2.repository.id} at file://C:\Users\Uwe
Schindler\Projects\lucene\trunk-lusolr2\lucene\dist\maven
[artifact:deploy] Transferring 5945K from ${m2.repository.id}
[artifact:deploy] Uploaded 5945K
[artifact:deploy] [INFO] Retrieving previous metadata from ${m2.repository.id}
[artifact:deploy] [INFO] repository metadata for: 'artifact
org.apache.lucene:lucene-test-framework' could not be found on repositor
y: ${m2.repository.id}, so will be created
[artifact:deploy] [INFO] Uploading repository metadata for: 'artifact
org.apache.lucene:lucene-test-framework'
[artifact:deploy] [INFO] Retrieving previous metadata from ${m2.repository.id}
[artifact:deploy] [INFO] repository metadata for: 'snapshot
org.apache.lucene:lucene-test-framework:5.0-SNAPSHOT' could not be found
on repository: ${m2.repository.id}, so will be created
[artifact:deploy] [INFO] Uploading repository metadata for: 'snapshot
org.apache.lucene:lucene-test-framework:5.0-SNAPSHOT'
[artifact:deploy] [INFO] Uploading project information for
lucene-test-framework 5.0-20120904.150305-1
[artifact:deploy] [INFO] Retrieving previous build number from
${m2.repository.id}
[artifact:deploy] Uploading:
org/apache/lucene/lucene-test-framework/5.0-SNAPSHOT/lucene-test-framework-5.0-20120904.150305-1-source
s.jar to repository ${m2.repository.id} at file://C:\Users\Uwe
Schindler\Projects\lucene\trunk-lusolr2\lucene\dist\maven
[artifact:deploy] Transferring 5818K from ${m2.repository.id}
[artifact:deploy] Uploaded 5818K
[artifact:deploy] [INFO] Retrieving previous build number from
${m2.repository.id}
[artifact:deploy] Uploading:
org/apache/lucene/lucene-test-framework/5.0-SNAPSHOT/lucene-test-framework-5.0-20120904.150305-1-javado
c.jar to repository ${m2.repository.id} at file://C:\Users\Uwe
Schindler\Projects\lucene\trunk-lusolr2\lucene\dist\maven
[artifact:deploy] Transferring 695K from ${m2.repository.id}
[artifact:deploy] Uploaded 695K
{noformat}
See first few lines. After nuking ~/.m2 it downloads all dependency JAR files
from maven central, but it also (!) downloads snapshot Lucene JARS, although it
built them before. Can we supress this. Its not a problem for the license
checker (because it excludes all those JARS), but i makes me nervous...
add validate-maven task to check maven dependencies
---
Key: LUCENE-4354
URL: https://issues.apache.org/jira/browse/LUCENE-4354
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Attachments: LUCENE-4354-dep-fix.patch,
LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch,
LUCENE-4354.patch
We had a situation where the maven artifacts depended on the wrong version of
tika: we should test that the maven dependencies are correct.
An easy way
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447741#comment-13447741 ] Robert Muir commented on LUCENE-4354: - I have no idea: thats a maven issue (its not really an issue with this license checking). add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4354: Attachment: LUCENE-4354.patch latest patch: semi-working for solr. there is currently a failure. Some stuff depends on commons-compress-1.3.jar and others on commons-compress-1.4.1.jar. We need to clear this up. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4340) Move all codecs but Lucene40 to a module
[ https://issues.apache.org/jira/browse/LUCENE-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-4340: - Attachment: LUCENE-4340.patch Updated patch : - the codecs module needs a specific output folder because its META-INF/services/org.apache.lucene.codecs.Codec and PostingsFormat files will conflict with core otherwise, - tested import in Idea, - added svn:ignore on lucene/codecs/*.iml. Move all codecs but Lucene40 to a module Key: LUCENE-4340 URL: https://issues.apache.org/jira/browse/LUCENE-4340 Project: Lucene - Core Issue Type: Task Components: core/codecs, general/build Reporter: Adrien Grand Fix For: 5.0, 4.0 Attachments: LUCENE-4340.patch, LUCENE-4340.patch, LUCENE-4340.sh We should move all concrete postings formats and codecs but Lucene40 to a module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4356) settle on one version of commons-compress
Robert Muir created LUCENE-4356: --- Summary: settle on one version of commons-compress Key: LUCENE-4356 URL: https://issues.apache.org/jira/browse/LUCENE-4356 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir lucene/benchmark depends on 1.3 solr/contrib/extraction depends on 1.4.1 maven/ says 1.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-4340) Move all codecs but Lucene40 to a module
[ https://issues.apache.org/jira/browse/LUCENE-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447748#comment-13447748 ] Adrien Grand edited comment on LUCENE-4340 at 9/5/12 2:22 AM: -- Updated patch : - the codecs module needs a specific Eclipse output folder because its META-INF/services/org.apache.lucene.codecs.Codec and PostingsFormat files will conflict with core otherwise, - tested import in Idea, - added svn:ignore on lucene/codecs/*.iml. was (Author: jpountz): Updated patch : - the codecs module needs a specific output folder because its META-INF/services/org.apache.lucene.codecs.Codec and PostingsFormat files will conflict with core otherwise, - tested import in Idea, - added svn:ignore on lucene/codecs/*.iml. Move all codecs but Lucene40 to a module Key: LUCENE-4340 URL: https://issues.apache.org/jira/browse/LUCENE-4340 Project: Lucene - Core Issue Type: Task Components: core/codecs, general/build Reporter: Adrien Grand Fix For: 5.0, 4.0 Attachments: LUCENE-4340.patch, LUCENE-4340.patch, LUCENE-4340.sh We should move all concrete postings formats and codecs but Lucene40 to a module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4356) settle on one version of commons-compress
[ https://issues.apache.org/jira/browse/LUCENE-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4356: Attachment: LUCENE-4356.patch patch fixing maven/ and lucene/benchmark to use 1.4.1 settle on one version of commons-compress - Key: LUCENE-4356 URL: https://issues.apache.org/jira/browse/LUCENE-4356 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-4356.patch lucene/benchmark depends on 1.3 solr/contrib/extraction depends on 1.4.1 maven/ says 1.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4357) icu tools/ use forbidden apis
Robert Muir created LUCENE-4357:
---
Summary: icu tools/ use forbidden apis
Key: LUCENE-4357
URL: https://issues.apache.org/jira/browse/LUCENE-4357
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
I guess by default we dont validate stuff in modules' tools/
but if you compile the ICU tools/ and then run validate:
{noformat}
-check-forbidden-jdk-apis:
[forbidden-apis] Reading API signatures:
/home/rmuir/workspace/lucene-trunk/lucene/tools/forbiddenApis/executors.txt
[forbidden-apis] Reading API signatures:
/home/rmuir/workspace/lucene-trunk/lucene/tools/forbiddenApis/jdk-deprecated.txt
[forbidden-apis] Reading API signatures:
/home/rmuir/workspace/lucene-trunk/lucene/tools/forbiddenApis/jdk.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning for API signatures and dependencies...
[forbidden-apis] Forbidden method invocation:
java.lang.String#format(java.lang.String,java.lang.Object[])
[forbidden-apis] in org.apache.lucene.analysis.icu.GenerateUTR30DataFiles
(GenerateUTR30DataFiles.java:255)
[forbidden-apis] Forbidden method invocation:
java.lang.String#format(java.lang.String,java.lang.Object[])
[forbidden-apis] in org.apache.lucene.analysis.icu.GenerateUTR30DataFiles
(GenerateUTR30DataFiles.java:256)
[forbidden-apis] Forbidden method invocation:
java.lang.String#format(java.lang.String,java.lang.Object[])
[forbidden-apis] in org.apache.lucene.analysis.icu.GenerateUTR30DataFiles
(GenerateUTR30DataFiles.java:261)
[forbidden-apis] Forbidden method invocation:
java.lang.String#format(java.lang.String,java.lang.Object[])
[forbidden-apis] in org.apache.lucene.analysis.icu.GenerateUTR30DataFiles
(GenerateUTR30DataFiles.java:263)
[forbidden-apis] Scanned 5235 (and 423 related) class file(s) for forbidden API
invocations (in 1.35s), 4 error(s).
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447752#comment-13447752 ] Robert Muir commented on LUCENE-4354: - I opened LUCENE-4356 to fix the commons-compress (there are 3 versions being used, which is crazy) add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447756#comment-13447756 ] Robert Muir commented on LUCENE-4354: - I also tripped LUCENE-4357. I think because i depend on compile-tools (not common.compile-tools, and icu redefines that). So the ICU tools got compiled too (which normally dont), and then forbidden APIs tripped. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3611) We do not show ZooKeeper data in the UI for a node that has children.
[ https://issues.apache.org/jira/browse/SOLR-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447758#comment-13447758 ] Mark Miller commented on SOLR-3611: --- I'll commit a fix for this in a moment - looks like it simply does not show the data pane if children 0 and if we simply remove that check, things are fine. We do not show ZooKeeper data in the UI for a node that has children. - Key: SOLR-3611 URL: https://issues.apache.org/jira/browse/SOLR-3611 Project: Solr Issue Type: Bug Components: SolrCloud, web gui Reporter: Mark Miller Priority: Minor Fix For: 4.0 There is sometimes useful data at these nodes. For example, /collections/collection1 will have children nodes, but it also has data as well - some json that links the collection to the config name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3611) We do not show ZooKeeper data in the UI for a node that has children.
[ https://issues.apache.org/jira/browse/SOLR-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3611: -- Fix Version/s: 5.0 We do not show ZooKeeper data in the UI for a node that has children. - Key: SOLR-3611 URL: https://issues.apache.org/jira/browse/SOLR-3611 Project: Solr Issue Type: Bug Components: SolrCloud, web gui Reporter: Mark Miller Priority: Minor Fix For: 4.0, 5.0 There is sometimes useful data at these nodes. For example, /collections/collection1 will have children nodes, but it also has data as well - some json that links the collection to the config name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3611) We do not show ZooKeeper data in the UI for a node that has children.
[ https://issues.apache.org/jira/browse/SOLR-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3611. --- Resolution: Fixed Assignee: Mark Miller We do not show ZooKeeper data in the UI for a node that has children. - Key: SOLR-3611 URL: https://issues.apache.org/jira/browse/SOLR-3611 Project: Solr Issue Type: Bug Components: SolrCloud, web gui Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.0, 5.0 There is sometimes useful data at these nodes. For example, /collections/collection1 will have children nodes, but it also has data as well - some json that links the collection to the config name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3035) XML and JSON response writers don't handle short or binary field types
[ https://issues.apache.org/jira/browse/SOLR-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447765#comment-13447765 ] Michael Ryan commented on SOLR-3035: Shouldn't this be using writeShort and writeByte for short and byte, instead of writeInt? Looking at 3.6 code... in ByteField, it calls XMLWriter.writeByte(String, String), which writes it out in a byte tag. However, there are also two methods - writeByte(String, byte) and writeShort(String, short) - which are using writeInt(), which seems like another bug. On trunk, all of this code is gone, so I guess it is using writeInt for all of them? XML and JSON response writers don't handle short or binary field types -- Key: SOLR-3035 URL: https://issues.apache.org/jira/browse/SOLR-3035 Project: Solr Issue Type: Bug Components: Response Writers Affects Versions: 3.1, 3.5, 4.0-ALPHA Reporter: Ken Krugler Priority: Blocker Fix For: 4.0-ALPHA Attachments: distributed-search.zip, ResponseWriterTest.java, SOLR-3035.patch The XML and JSON response writers return data from short schema fields as java.lang.Short:value. In addition, binary fields (for sharded requests) are returned as [B:[B@hex address of array, which makes them totally unusable. This appears to be due to their writeVal() methods not having cases to handle val instanceof Short and val instance of byte[] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447766#comment-13447766 ] Steven Rowe commented on LUCENE-4354: - bq. After nuking ~/.m2 it downloads all dependency JAR files from maven central, but it also downloads snapshot Lucene JARS, although it built them before. Can we supress this. Its not a problem for the license checker (because it excludes all those JARS), but i makes me nervous... This happens because the Apache snapshot repo is listed in the poms, but it shouldn't be - we should never download Lucene/Solr snapshots as part of the build. I'll open an issue. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4356) settle on one version of commons-compress
[ https://issues.apache.org/jira/browse/LUCENE-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-4356. - Resolution: Fixed Fix Version/s: 4.0 5.0 settle on one version of commons-compress - Key: LUCENE-4356 URL: https://issues.apache.org/jira/browse/LUCENE-4356 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Fix For: 5.0, 4.0 Attachments: LUCENE-4356.patch lucene/benchmark depends on 1.3 solr/contrib/extraction depends on 1.4.1 maven/ says 1.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4351) Upgrade Spatial4j to 0.3
[ https://issues.apache.org/jira/browse/LUCENE-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-4351: - Attachment: LUCENE-4351_Spatial4j_0_3.patch Here's the patch; there were many changes needed. Many were trivial, like GeohashUtils and ParseUtils moving to the .io. package, or SimpleSpatialContext being just SpatialContext now. The biggest change was circle.getRadius() and DistanceCalculator.distance() being degrees based. Chris and I thought it best that Lucene spatial retain distance unit neutrality, and hence the distance ValueSource out of the SpatialStrategy is in degrees as well. Also, I modified the complex TestRecursivePrefixTreeStrategy.geohashRecursiveRandom() test to use circular data clusters instead of rectangular, since at the poles those rectangles don't look too rectangular ;-) May not have been strictly necessary as part of the patch but while debugging an unknown failure I wanted to make this improvement. Upgrade Spatial4j to 0.3 Key: LUCENE-4351 URL: https://issues.apache.org/jira/browse/LUCENE-4351 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 Attachments: LUCENE-4351_Spatial4j_0_3.patch This version of Spatial4j has various API level improvements. It features dateline wrap for polygons. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4358) Maven build should never download internal dependencies' artifacts from Apache snapshot repository
Steven Rowe created LUCENE-4358: --- Summary: Maven build should never download internal dependencies' artifacts from Apache snapshot repository Key: LUCENE-4358 URL: https://issues.apache.org/jira/browse/LUCENE-4358 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: 5.0, 4.0 Reporter: Steven Rowe Assignee: Steven Rowe Priority: Minor The Apache snapshot repo should be removed from the POMs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447770#comment-13447770 ] Steven Rowe commented on LUCENE-4354: - bq. the Apache snapshot repo is listed in the poms, but it shouldn't be - we should never download Lucene/Solr snapshots as part of the build. I'll open an issue. LUCENE-4358 add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4357) icu tools/ use forbidden apis
[
https://issues.apache.org/jira/browse/LUCENE-4357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-4357:
Attachment: LUCENE-4357.patch
Patch: also fixing validate to validate modules' tools directories.
icu tools/ use forbidden apis
-
Key: LUCENE-4357
URL: https://issues.apache.org/jira/browse/LUCENE-4357
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Attachments: LUCENE-4357.patch
I guess by default we dont validate stuff in modules' tools/
but if you compile the ICU tools/ and then run validate:
{noformat}
-check-forbidden-jdk-apis:
[forbidden-apis] Reading API signatures:
/home/rmuir/workspace/lucene-trunk/lucene/tools/forbiddenApis/executors.txt
[forbidden-apis] Reading API signatures:
/home/rmuir/workspace/lucene-trunk/lucene/tools/forbiddenApis/jdk-deprecated.txt
[forbidden-apis] Reading API signatures:
/home/rmuir/workspace/lucene-trunk/lucene/tools/forbiddenApis/jdk.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning for API signatures and dependencies...
[forbidden-apis] Forbidden method invocation:
java.lang.String#format(java.lang.String,java.lang.Object[])
[forbidden-apis] in org.apache.lucene.analysis.icu.GenerateUTR30DataFiles
(GenerateUTR30DataFiles.java:255)
[forbidden-apis] Forbidden method invocation:
java.lang.String#format(java.lang.String,java.lang.Object[])
[forbidden-apis] in org.apache.lucene.analysis.icu.GenerateUTR30DataFiles
(GenerateUTR30DataFiles.java:256)
[forbidden-apis] Forbidden method invocation:
java.lang.String#format(java.lang.String,java.lang.Object[])
[forbidden-apis] in org.apache.lucene.analysis.icu.GenerateUTR30DataFiles
(GenerateUTR30DataFiles.java:261)
[forbidden-apis] Forbidden method invocation:
java.lang.String#format(java.lang.String,java.lang.Object[])
[forbidden-apis] in org.apache.lucene.analysis.icu.GenerateUTR30DataFiles
(GenerateUTR30DataFiles.java:263)
[forbidden-apis] Scanned 5235 (and 423 related) class file(s) for forbidden
API invocations (in 1.35s), 4 error(s).
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4358) Maven build should never download internal dependencies' artifacts from Apache snapshot repository
[ https://issues.apache.org/jira/browse/LUCENE-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447774#comment-13447774 ] Uwe Schindler commented on LUCENE-4358: --- Ah thanks, so this fixes my issue. I was playing around with other crazy opts passed to the mvn:dependency task in ANT... Maven build should never download internal dependencies' artifacts from Apache snapshot repository -- Key: LUCENE-4358 URL: https://issues.apache.org/jira/browse/LUCENE-4358 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: 5.0, 4.0 Reporter: Steven Rowe Assignee: Steven Rowe Priority: Minor The Apache snapshot repo should be removed from the POMs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447776#comment-13447776 ] Robert Muir commented on LUCENE-4354: - I will update the patch shortly merging in the changes to LUCENE-4356. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4358) Maven build should never download internal dependencies' artifacts from Apache snapshot repository
[ https://issues.apache.org/jira/browse/LUCENE-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-4358: Attachment: LUCENE-4358.patch Patch removing Apache snapshot repo from the grandparent POM Maven build should never download internal dependencies' artifacts from Apache snapshot repository -- Key: LUCENE-4358 URL: https://issues.apache.org/jira/browse/LUCENE-4358 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: 5.0, 4.0 Reporter: Steven Rowe Assignee: Steven Rowe Priority: Minor Attachments: LUCENE-4358.patch The Apache snapshot repo should be removed from the POMs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4358) Maven build should never download internal dependencies' artifacts from Apache snapshot repository
[ https://issues.apache.org/jira/browse/LUCENE-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe resolved LUCENE-4358. - Resolution: Fixed Fix Version/s: 4.0 5.0 Lucene Fields: New,Patch Available (was: New) committed: - trunk: r1380725 - branch_4x: r1380729 Maven build should never download internal dependencies' artifacts from Apache snapshot repository -- Key: LUCENE-4358 URL: https://issues.apache.org/jira/browse/LUCENE-4358 Project: Lucene - Core Issue Type: Bug Components: general/build Affects Versions: 5.0, 4.0 Reporter: Steven Rowe Assignee: Steven Rowe Priority: Minor Fix For: 5.0, 4.0 Attachments: LUCENE-4358.patch The Apache snapshot repo should be removed from the POMs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4354) add validate-maven task to check maven dependencies
[
https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-4354:
Attachment: LUCENE-4354.patch
Updated patch to trunk. lucene/ and solr/ both pass now.
So the only funky thing is the two servlet-api jars, which i disabled with a
nocommit:
{noformat}
excludes
rsel:or
rsel:name name=**/lucene-*.jar handledirsep=true/
rsel:name name=**/solr-*.jar handledirsep=true/
!-- nocommit --
rsel:name name=**/*servlet*.jar handledirsep=true/
/rsel:or
/excludes
{noformat}
I feel like this servlet-api crap is a bigger issue though and we shouldnt let
it block this one.
add validate-maven task to check maven dependencies
---
Key: LUCENE-4354
URL: https://issues.apache.org/jira/browse/LUCENE-4354
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Attachments: LUCENE-4354-dep-fix.patch,
LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch,
LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch
We had a situation where the maven artifacts depended on the wrong version of
tika: we should test that the maven dependencies are correct.
An easy way to do this is to force it to download all of its dependencies,
and then run our existing license checks over that.
This currently fails: maven is bringing in some extra 3rd party libraries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
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/ibm-j9-jdk7) - Build # 871 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/871/
Java: 32bit/ibm-j9-jdk7
-Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/lucene/util/fst/FST;}
All tests passed
Build Log:
[...truncated 19044 lines...]
-jenkins-javadocs-lint:
[...truncated 24 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:252: The following
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:110: The
following files are missing svn:eol-style (or binary svn:mime-type):
* lucene/licenses/commons-compress-1.4.1.jar.sha1
Total time: 28 minutes 20 seconds
Build step 'Invoke Ant' marked build as failure
Recording test results
Description set: Java: 32bit/ibm-j9-jdk7
-Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/lucene/util/fst/FST;}
Email was triggered for: Failure
Sending email for trigger: Failure
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build # 871 - Failure!
I caused this.
On Tue, Sep 4, 2012 at 12:21 PM, Policeman Jenkins Server
jenk...@sd-datasolutions.de wrote:
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/871/
Java: 32bit/ibm-j9-jdk7
-Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/lucene/util/fst/FST;}
All tests passed
Build Log:
[...truncated 19044 lines...]
-jenkins-javadocs-lint:
[...truncated 24 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:252: The
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:110: The
following files are missing svn:eol-style (or binary svn:mime-type):
* lucene/licenses/commons-compress-1.4.1.jar.sha1
Total time: 28 minutes 20 seconds
Build step 'Invoke Ant' marked build as failure
Recording test results
Description set: Java: 32bit/ibm-j9-jdk7
-Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/lucene/util/fst/FST;}
Email was triggered for: Failure
Sending email for trigger: Failure
--
lucidworks.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-4358) Maven build should never download internal dependencies' artifacts from Apache snapshot repository
[
https://issues.apache.org/jira/browse/LUCENE-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler reopened LUCENE-4358:
---
I updated SVN, cleaned all maven poms from WC, and I still see this:
{noformat}
dist-maven-common:
[artifact:dependencies] [INFO] snapshot
org.apache.lucene:lucene-test-framework:5.0-SNAPSHOT: checking for updates from
apache.snaps
hots
[artifact:dependencies] Downloading:
org/apache/lucene/lucene-test-framework/5.0-SNAPSHOT/lucene-test-framework-5.0-20120903.170359-
49.pom from repository apache.snapshots at
http://repository.apache.org/snapshots
[artifact:dependencies] [INFO] snapshot
org.apache.lucene:lucene-core:5.0-SNAPSHOT: checking for updates from
apache.snapshots
[artifact:dependencies] [INFO] snapshot
org.apache.lucene:lucene-core:5.0-SNAPSHOT: checking for updates from
sonatype.releases
[artifact:dependencies] Downloading:
org/apache/lucene/lucene-core/5.0-SNAPSHOT/lucene-core-5.0-20120903.170333-49.pom
from reposito
ry apache.snapshots at http://repository.apache.org/snapshots
{noformat}
Maven build should never download internal dependencies' artifacts from
Apache snapshot repository
--
Key: LUCENE-4358
URL: https://issues.apache.org/jira/browse/LUCENE-4358
Project: Lucene - Core
Issue Type: Bug
Components: general/build
Affects Versions: 5.0, 4.0
Reporter: Steven Rowe
Assignee: Steven Rowe
Priority: Minor
Fix For: 5.0, 4.0
Attachments: LUCENE-4358.patch
The Apache snapshot repo should be removed from the POMs
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4359) Allow DocValues to be unstored
Adrien Grand created LUCENE-4359:
Summary: Allow DocValues to be unstored
Key: LUCENE-4359
URL: https://issues.apache.org/jira/browse/LUCENE-4359
Project: Lucene - Core
Issue Type: Sub-task
Affects Versions: 5.0
Reporter: Adrien Grand
Lucene trunk currently forces DocValues to be stored:
- FieldType.setDocValueType sets stored to true,
- DocFieldProcessor.processDocument handles DocValues in a {{for
(StorableField field: docState.doc.storableFields())}} loop, meaning that
DocValues won't be consumed if they are not stored.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-trunk-Java6 - Build # 15178 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java6/15178/ All tests passed Build Log: [...truncated 18345 lines...] -jenkins-javadocs-lint: javadocs-lint: [...truncated 1563 lines...] javadocs-lint: [exec] [exec] Crawl/parse... [exec] [exec] build/docs/core/org/apache/lucene/store/package-use.html [exec] WARNING: anchor ../../../../org/apache/lucene/store/subclasses appears more than once [exec] [exec] Verify... [...truncated 566 lines...] javadocs-lint: [exec] [exec] Crawl/parse... [exec] [exec] Verify... [...truncated 24 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/build.xml:252: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/extra-targets.xml:110: The following files are missing svn:eol-style (or binary svn:mime-type): * lucene/licenses/commons-compress-1.4.1.jar.sha1 Total time: 39 minutes 7 seconds Build step 'Invoke Ant' marked build as failure Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4359) Allow DocValues to be unstored
[
https://issues.apache.org/jira/browse/LUCENE-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447796#comment-13447796
]
Robert Muir commented on LUCENE-4359:
-
Nice catch: I think this is related to LUCENE-4349, in that we should treat
DocValues differently (neither stored nor indexed, its just its own thing)
Allow DocValues to be unstored
--
Key: LUCENE-4359
URL: https://issues.apache.org/jira/browse/LUCENE-4359
Project: Lucene - Core
Issue Type: Sub-task
Affects Versions: 5.0
Reporter: Adrien Grand
Lucene trunk currently forces DocValues to be stored:
- FieldType.setDocValueType sets stored to true,
- DocFieldProcessor.processDocument handles DocValues in a {{for
(StorableField field: docState.doc.storableFields())}} loop, meaning that
DocValues won't be consumed if they are not stored.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.7.0_07) - Build # 610 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/610/ Java: 32bit/jdk1.7.0_07 -server -XX:+UseG1GC All tests passed Build Log: [...truncated 19179 lines...] -jenkins-javadocs-lint: [...truncated 24 lines...] BUILD FAILED C:\Jenkins\workspace\Lucene-Solr-4.x-Windows\build.xml:252: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-4.x-Windows\extra-targets.xml:110: The following files are missing svn:eol-style (or binary svn:mime-type): * lucene/licenses/commons-compress-1.4.1.jar.sha1 Total time: 45 minutes 14 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.7.0_07 -server -XX:+UseG1GC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
