[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+164) - Build # 19404 - Unstable!

2017-04-15 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19404/
Java: 32bit/jdk-9-ea+164 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.SolrCloudExampleTest

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, MDCAwareThreadPoolExecutor, TransactionLog, 
MockDirectoryWrapper, MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:360)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:720)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:947)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:854)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:958)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:893)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:88)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:370)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:388)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:178)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:747)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:728)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:509)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:344)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:295)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:202)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) 
 at java.base/java.lang.Thread.run(Thread.java:844)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.SolrCore.reload(SolrCore.java:647)  at 
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1154)  at 
org.apache.solr.core.SolrCore.lambda$getConfListener$18(SolrCore.java:2949)  at 
org.apache.solr.handler.SolrConfigHandler$Command.lambda$handleGET$0(SolrConfigHandler.java:225)
  at java.base/java.lang.Thread.run(Thread.java:844)

[jira] [Commented] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

2017-04-15 Thread Cao Manh Dat (JIRA) 

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

Cao Manh Dat commented on SOLR-10420:
-

[~dragonsinth] As Steve said, Overseer.external.. test failed frequently before 
SOLR-9191 got committed. So I doubt that "isDirty" in retro-code will fix the 
problem.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

2017-04-15 Thread Cao Manh Dat (JIRA) 

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

Cao Manh Dat commented on SOLR-10420:
-

[~dragonsinth] that's correct.

The last patch pass all the tests. 

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+164) - Build # 19402 - Unstable!

2017-04-15 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19402/
Java: 32bit/jdk-9-ea+164 -client -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats

Error Message:
Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1

Stack Trace:
java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
registry solr.core.collection1
at 
__randomizedtesting.SeedInfo.seed([DBEE2EECB3278B0A:14704BD53CD6E355]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:132)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 12916 lines...]
   [junit4] Suite:

[jira] [Updated] (SOLR-10495) Loading JDBC driver in custom SearchComponent

2017-04-15 Thread Christian Harke (JIRA) 

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

Christian Harke updated SOLR-10495:
---
Description: 
I'd like to access a postgres database from my custom SearchComponent but 
unfortunately, I get the following error:

{noformat}
java.sql.SQLException: No suitable driver found for postgres
at java.sql.DriverManager.getConnection(DriverManager.java:689)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at 
ch.guidelines.util.SimpleDataSource.getConnection(SimpleDataSource.java:50)
...
{noformat}

... when I try to connect to the database using:

{code:title=SimpleDataSource.java}
private String dbUrl = "jdbc:postgresql://db/mydb";

public Connection getConnection(String dbUser, String dbPasswd) throws 
SQLException {
this.dbUser = dbUser;
this.dbPasswd = dbPasswd;
this.conn = DriverManager.getConnection(dbUrl, dbUser, dbPasswd); // line 50
return conn;
}
{code}

I already use the DataImportHandler using the Postgres JDBC driver 
successfully. I tried putting the driver's jar in different locations:
- /opt/solr/dist (with added  entry in solrconfig.xml)
- /opt/solr/lib
- /opt/solr/server/lib
- /opt/solr/server/lib/ext
- /opt/solr/server/solr/lib (lib-folder in the solr.solr.home directory)

But nothing worked so far... How can I get the driver loaded in my custom 
SearchComponent?

I'd really appreciate your help.

  was:
I'd like to access a postgres database from my custom SearchComponent but 
unfortunately, I get the following error:

{noformat}
java.sql.SQLException: No suitable driver found for postgres
at java.sql.DriverManager.getConnection(DriverManager.java:689)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at 
ch.guidelines.util.SimpleDataSource.getConnection(SimpleDataSource.java:50)
...
{noformat}

... when I try to connect to the database using:

{code:title=SimpleDataSource.java}
public Connection getConnection(String dbUser, String dbPasswd) throws 
SQLException {
this.dbUser = dbUser;
this.dbPasswd = dbPasswd;
this.conn = DriverManager.getConnection(dbUrl, dbUser, dbPasswd); // line 50
return conn;
}
{code}

I already use the DataImportHandler using the Postgres JDBC driver 
successfully. I tried putting the driver's jar in different locations:
- /opt/solr/dist (with added  entry in solrconfig.xml)
- /opt/solr/lib
- /opt/solr/server/lib
- /opt/solr/server/lib/ext
- /opt/solr/server/solr/lib (lib-folder in the solr.solr.home directory)
But nothing worked so far... How can I get the driver loaded in my custom 
SearchComponent?

I'd really appreciate your help.


> Loading JDBC driver in custom SearchComponent
> -
>
> Key: SOLR-10495
> URL: https://issues.apache.org/jira/browse/SOLR-10495
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Affects Versions: 6.4.2
> Environment: Docker Container (https://store.docker.com/images/solr)
>Reporter: Christian Harke
>Priority: Minor
>  Labels: newbie
>
> I'd like to access a postgres database from my custom SearchComponent but 
> unfortunately, I get the following error:
> {noformat}
> java.sql.SQLException: No suitable driver found for postgres
> at java.sql.DriverManager.getConnection(DriverManager.java:689)
>   at java.sql.DriverManager.getConnection(DriverManager.java:247)
>   at 
> ch.guidelines.util.SimpleDataSource.getConnection(SimpleDataSource.java:50)
> ...
> {noformat}
> ... when I try to connect to the database using:
> {code:title=SimpleDataSource.java}
> private String dbUrl = "jdbc:postgresql://db/mydb";
> public Connection getConnection(String dbUser, String dbPasswd) throws 
> SQLException {
> this.dbUser = dbUser;
> this.dbPasswd = dbPasswd;
> this.conn = DriverManager.getConnection(dbUrl, dbUser, dbPasswd); // line 
> 50
> return conn;
> }
> {code}
> I already use the DataImportHandler using the Postgres JDBC driver 
> successfully. I tried putting the driver's jar in different locations:
> - /opt/solr/dist (with added  entry in solrconfig.xml)
> - /opt/solr/lib
> - /opt/solr/server/lib
> - /opt/solr/server/lib/ext
> - /opt/solr/server/solr/lib (lib-folder in the solr.solr.home directory)
> But nothing worked so far... How can I get the driver loaded in my custom 
> SearchComponent?
> I'd really appreciate your help.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

2017-04-15 Thread JIRA 

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

Jan Høydahl commented on SOLR-10494:


+1

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Trey Grainger
>Priority: Minor
> Fix For: master (7.0)
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (LUCENE-7786) TermInSetQuery should include a getter for field

2017-04-15 Thread Michael Braun (JIRA) 
Michael Braun created LUCENE-7786:
-

 Summary: TermInSetQuery should include a getter for field
 Key: LUCENE-7786
 URL: https://issues.apache.org/jira/browse/LUCENE-7786
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 6.5, master (7.0)
Reporter: Michael Braun
Priority: Trivial


Per LUCENE-7637, TermInSetQuery is restricted to a single field. However, there 
is no getter for the field. A public getter should be added to expose the field 
name.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10495) Loading JDBC driver in custom SearchComponent

2017-04-15 Thread Christian Harke (JIRA) 
Christian Harke created SOLR-10495:
--

 Summary: Loading JDBC driver in custom SearchComponent
 Key: SOLR-10495
 URL: https://issues.apache.org/jira/browse/SOLR-10495
 Project: Solr
  Issue Type: Wish
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SearchComponents - other
Affects Versions: 6.4.2
 Environment: Docker Container (https://store.docker.com/images/solr)
Reporter: Christian Harke
Priority: Minor


I'd like to access a postgres database from my custom SearchComponent but 
unfortunately, I get the following error:

{noformat}
java.sql.SQLException: No suitable driver found for postgres
at java.sql.DriverManager.getConnection(DriverManager.java:689)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at 
ch.guidelines.util.SimpleDataSource.getConnection(SimpleDataSource.java:50)
...
{noformat}

... when I try to connect to the database using:

{code:title=SimpleDataSource.java}
public Connection getConnection(String dbUser, String dbPasswd) throws 
SQLException {
this.dbUser = dbUser;
this.dbPasswd = dbPasswd;
this.conn = DriverManager.getConnection(dbUrl, dbUser, dbPasswd); // line 50
return conn;
}
{code}

I already use the DataImportHandler using the Postgres JDBC driver 
successfully. I tried putting the driver's jar in different locations:
- /opt/solr/dist (with added  entry in solrconfig.xml)
- /opt/solr/lib
- /opt/solr/server/lib
- /opt/solr/server/lib/ext
- /opt/solr/server/solr/lib (lib-folder in the solr.solr.home directory)
But nothing worked so far... How can I get the driver loaded in my custom 
SearchComponent?

I'd really appreciate your help.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_121) - Build # 19400 - Still Unstable!

2017-04-15 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19400/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats

Error Message:
Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1

Stack Trace:
java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
registry solr.core.collection1
at 
__randomizedtesting.SeedInfo.seed([AB6D55D0D3B1B81E:64F330E95C40D041]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:132)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11229 lines...]
   [junit4]

[jira] [Commented] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

2017-04-15 Thread Scott Blum (JIRA) 

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

Scott Blum commented on SOLR-10420:
---

Let me try to unpack what you said..

1) We want a synchronous offer() -> peek() on the same thread to return the 
item offered without delay.
2) This works on master, but the original patch to fix the leak breaks #1.

Is that correct?

Let me look at this on Monday with [~jhump].  I'm pretty sure there's a 
simplification to be made in DQ with how we're handling the watcher and dirty 
tracking.  There used to be an explicit "isDirty" bit that we traded out for 
watcher nullability, which in retrospect I'm not sure was the best choice.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10485) Add eval() Streaming Expression to execute Evaluators

2017-04-15 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein updated SOLR-10485:
--
Description: 
The eval() function can be used inside of the select function to execute 
Evaluators:

{code}
select(eval(), add(1, 1) as result)
{code}

The example above returns a single Tuple with the result of add(1, 1) in the 
*result* field. This allows Streaming Expressions to perform calculations 
directly without requiring an underlying stream.


  was:
The eval() function can be used inside of the select function to execute 
Evaluators:

{code}
select(eval(), add(1, 1) as result)
{code}

The example above returns a single Tuple with the result of add(1, 1) in the 
*result* field. This allows Streaming Expression to perform calculations 
directly without requiring an underlying stream.



> Add eval() Streaming Expression to execute Evaluators
> -
>
> Key: SOLR-10485
> URL: https://issues.apache.org/jira/browse/SOLR-10485
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10485.patch
>
>
> The eval() function can be used inside of the select function to execute 
> Evaluators:
> {code}
> select(eval(), add(1, 1) as result)
> {code}
> The example above returns a single Tuple with the result of add(1, 1) in the 
> *result* field. This allows Streaming Expressions to perform calculations 
> directly without requiring an underlying stream.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10485) Add eval() Streaming Expression to execute Evaluators

2017-04-15 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein updated SOLR-10485:
--
Description: 
The eval() function can be used inside of the select function to execute 
Evaluators:

{code}
select(eval(), add(1, 1) as result)
{code}

The example above returns a single Tuple with the result of add(1, 1) in the 
*result* field. This allows Streaming Expression to perform calculations 
directly without requiring an underlying stream.


  was:
The eval() function can be used inside of the select function to execute 
Evaluators:

{code}
select(eval(), add(1, 1) as result)
{code}

The example above returns a single Tuple with the result of add(1, 1) in the 
*result*. This allows Streaming Expression to perform calculations directly 
without requiring an underlying stream.



> Add eval() Streaming Expression to execute Evaluators
> -
>
> Key: SOLR-10485
> URL: https://issues.apache.org/jira/browse/SOLR-10485
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10485.patch
>
>
> The eval() function can be used inside of the select function to execute 
> Evaluators:
> {code}
> select(eval(), add(1, 1) as result)
> {code}
> The example above returns a single Tuple with the result of add(1, 1) in the 
> *result* field. This allows Streaming Expression to perform calculations 
> directly without requiring an underlying stream.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10485) Add eval() Streaming Expression to execute Evaluators

2017-04-15 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein updated SOLR-10485:
--
Description: 
The eval() function can be used inside of the select function to execute 
Evaluators:

{code}
select(eval(), add(1, 1) as result)
{code}

The example above returns a single Tuple with the result of add(1, 1) in the 
*result*. This allows Streaming Expression to perform calculations directly 
without requiring an underlying stream.


  was:
The eval() function can be used inside of the select function to execute 
Evaluators:

{code}
select(eval(), add(1, 1) as result)
{code}




> Add eval() Streaming Expression to execute Evaluators
> -
>
> Key: SOLR-10485
> URL: https://issues.apache.org/jira/browse/SOLR-10485
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10485.patch
>
>
> The eval() function can be used inside of the select function to execute 
> Evaluators:
> {code}
> select(eval(), add(1, 1) as result)
> {code}
> The example above returns a single Tuple with the result of add(1, 1) in the 
> *result*. This allows Streaming Expression to perform calculations directly 
> without requiring an underlying stream.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10485) Add eval() Streaming Expression to execute Evaluators

2017-04-15 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein edited comment on SOLR-10485 at 4/15/17 4:04 PM:


I mapped the CalculateStream to *eval* function so it has broader uses then 
just a calculator.


was (Author: joel.bernstein):
I mapped the CalculateStream to *eval* function so it has broader uses the just 
a calculator.

> Add eval() Streaming Expression to execute Evaluators
> -
>
> Key: SOLR-10485
> URL: https://issues.apache.org/jira/browse/SOLR-10485
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10485.patch
>
>
> The eval() function can be used inside of the select function to execute 
> Evaluators:
> {code}
> select(eval(), add(1, 1) as result)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10485) Add eval() Streaming Expression to execute Evaluators

2017-04-15 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein updated SOLR-10485:
--
Description: 
The eval() function can be used inside of the select function to execute 
Evaluators:

{code}
select(eval(), add(1, 1) as result)
{code}



  was:
The eval() function can be used inside of the select function to execute 
evaluators:

{code}
select(eval(), add(1, 1) as result)
{code}




> Add eval() Streaming Expression to execute Evaluators
> -
>
> Key: SOLR-10485
> URL: https://issues.apache.org/jira/browse/SOLR-10485
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10485.patch
>
>
> The eval() function can be used inside of the select function to execute 
> Evaluators:
> {code}
> select(eval(), add(1, 1) as result)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10485) Add eval() Streaming Expression to execute Evaluators

2017-04-15 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein updated SOLR-10485:
--
Description: 
The eval() function can be used inside of the select function to execute 
evaluators:

{code}
select(eval(), add(1, 1) as result)
{code}



  was:
The CalculateStream returns a single empty Tuple to support this syntax:

{code}
select(eval(), add(1, 1) as result)
{code}

This will simply add the calculation to the Tuple and return it, turning Solr 
into a scientific calculator.



> Add eval() Streaming Expression to execute Evaluators
> -
>
> Key: SOLR-10485
> URL: https://issues.apache.org/jira/browse/SOLR-10485
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10485.patch
>
>
> The eval() function can be used inside of the select function to execute 
> evaluators:
> {code}
> select(eval(), add(1, 1) as result)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10485) Add eval() Streaming Expression to execute Evaluators

2017-04-15 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein updated SOLR-10485:
--
Summary: Add eval() Streaming Expression to execute Evaluators  (was: Add 
eval() Streaming Expression to allow Solr to behave like a scientific 
calculator)

> Add eval() Streaming Expression to execute Evaluators
> -
>
> Key: SOLR-10485
> URL: https://issues.apache.org/jira/browse/SOLR-10485
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10485.patch
>
>
> The CalculateStream returns a single empty Tuple to support this syntax:
> {code}
> select(eval(), add(1, 1) as result)
> {code}
> This will simply add the calculation to the Tuple and return it, turning Solr 
> into a scientific calculator.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10485) Add eval() Streaming Expression to allow Solr to behave like a scientific calculator

2017-04-15 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein updated SOLR-10485:
--
Summary: Add eval() Streaming Expression to allow Solr to behave like a 
scientific calculator  (was: Add CalculateStream to allow Solr to behave like a 
scientific calculator)

> Add eval() Streaming Expression to allow Solr to behave like a scientific 
> calculator
> 
>
> Key: SOLR-10485
> URL: https://issues.apache.org/jira/browse/SOLR-10485
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10485.patch
>
>
> The CalculateStream returns a single empty Tuple to support this syntax:
> {code}
> select(eval(), add(1, 1) as result)
> {code}
> This will simply add the calculation to the Tuple and return it, turning Solr 
> into a scientific calculator.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10486) Add Length Conversion Evaluators

2017-04-15 Thread Joel Bernstein (JIRA) 

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

Joel Bernstein commented on SOLR-10486:
---

No worries, my use of the switch statement in the read() method was worse! 
Thanks for bringing up the lambda solution.

If you like the approach using the EvaluatorException then we can create a 
ticket to throw this exception in the constructors of all existing evaluators.

> Add Length Conversion Evaluators
> 
>
> Key: SOLR-10486
> URL: https://issues.apache.org/jira/browse/SOLR-10486
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10486.patch, SOLR-10486.patch
>
>
> Based on the work in SOLR-10485 I think it makes sense to add Conversion 
> evaluators. I think a good place to start is with the conversions listed here:
> https://www.learner.org/interactives/metric/conversion_chart.html#1
> This ticket will add length conversions and lay down the initial syntax.
> Sample syntax:
> {code}
> select(eval(), convert(inches, meters, 22) as meters)
> {code}
> This will return a single tuple with 22 inches converted to meters.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_121) - Build # 19399 - Still Unstable!

2017-04-15 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19399/
Java: 32bit/jdk1.8.0_121 -client -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats

Error Message:
Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1

Stack Trace:
java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
registry solr.core.collection1
at 
__randomizedtesting.SeedInfo.seed([A994FD72F27CC51A:660A984B7D8DAD45]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:132)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11757 lines...]
   [junit4] Suite:

[jira] [Commented] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

2017-04-15 Thread Cao Manh Dat (JIRA) 

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

Cao Manh Dat commented on SOLR-10420:
-

[~dragonsinth] Can you review the patch?

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_121) - Build # 3285 - Unstable!

2017-04-15 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3285/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
shard2 is not consistent.  Got 204 from 
https://127.0.0.1:33191/tm_/i/collection1 (previous client) and got 185 from 
https://127.0.0.1:40121/tm_/i/collection1

Stack Trace:
java.lang.AssertionError: shard2 is not consistent.  Got 204 from 
https://127.0.0.1:33191/tm_/i/collection1 (previous client) and got 185 from 
https://127.0.0.1:40121/tm_/i/collection1
at 
__randomizedtesting.SeedInfo.seed([3E012BEF8449A0DB:B65514352AB5CD23]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1280)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1259)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:162)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+164) - Build # 19398 - Still Unstable!

2017-04-15 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19398/
Java: 64bit/jdk-9-ea+164 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats

Error Message:
Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1

Stack Trace:
java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
registry solr.core.collection1
at 
__randomizedtesting.SeedInfo.seed([1F3B63AA5563A1DE:D0A50693DA92C981]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:132)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 11706 lines...]
   [junit4] Suite:

Re: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+164) - Build # 19397 - Still Unstable!

2017-04-15 Thread Uwe Schindler 
Too large console log file?

Uwe

Am 15. April 2017 10:50:48 MESZ schrieb Policeman Jenkins Server 
:
>Error processing tokens: Error while parsing action
>'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3'
>at input position (line 77, pos 4):
>)"}
>   ^
>
>java.lang.OutOfMemoryError: Java heap space

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+164) - Build # 19397 - Still Unstable!

2017-04-15 Thread Policeman Jenkins Server 
Error processing tokens: Error while parsing action 
'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input 
position (line 77, pos 4):
)"}
   ^

java.lang.OutOfMemoryError: Java heap space

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

[jira] [Updated] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

2017-04-15 Thread Cao Manh Dat (JIRA) 

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

Cao Manh Dat updated SOLR-10420:

Attachment: SOLR-10420.patch

I have a discussion with Noble. It seems that DQ are not used in any places 
except Overseer. So I will go with solution #1.

Will beast the test in Steve machine tonight ( thanks [~steve_rowe] a lot )

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

2017-04-15 Thread Cao Manh Dat (JIRA) 

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

Cao Manh Dat edited comment on SOLR-10420 at 4/15/17 7:37 AM:
--

I kinda find out the reason why the test failure. There are some notice here
- In current DQ version, for each time we peek() if in-memory queue is empty, 
we will actually look at the ZK to get new elements ( watcher are useless in 
this scenario )
- With the patch, for each time we peek()  if in-memory queue is empty, we will 
only look at the ZK nodes when watcher tell us that there are change in our 
queue. So If ZK already contain new items we may still return empty.

So this is the reason why the test failure
- overseer.queue <- set a replica down
- overseer run the command successfully
- overseer.queue <- set a replica active
- overseer delay this command ( overseer.workqueue <- set a replica active )
- touch /clusterstate.json to change its version
- overseer.queue <- some ZKWriteCommand, let's call this one ZK1
- overseer change the clusterstate to set replica active
- overseer meet badversion exception
- overseer fetch last element from overseer.workqueue. Here are where problem 
happen, overseer.workqueue.peek() return empty because the watcher is not fired.
- overseer process ZK1, it success -> overseer.workqueue is emptied.


was (Author: caomanhdat):
I kinda find out the reason why the test failure. There are some notice here
- In current DQ version, for each time we peek() if in-memory queue is empty, 
we will actually look at the ZK to get new elements ( watcher are useless in 
this scenario )
- With the patch, for each time we peek()  if in-memory queue is empty, we will 
only look at the ZK nodes when watcher tell us that there are change in our 
queue. So If ZK already contain new items we can return empty.

So this is the reason why the test failure
- overseer.queue <- set a replica down
- overseer run the command successfully
- overseer.queue <- set a replica active
- overseer delay this command ( overseer.workqueue <- set a replica active )
- touch /clusterstate.json to change its version
- overseer.queue <- some ZKWriteCommand, let's call this one ZK1
- overseer change the clusterstate to set replica active
- overseer meet badversion exception
- overseer fetch last element from overseer.workqueue. Here are where problem 
happen, overseer.workqueue.peek() return empty because the watcher is not fired.
- overseer process ZK1, it success -> overseer.workqueue is emptied.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

2017-04-15 Thread Cao Manh Dat (JIRA) 

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

Cao Manh Dat edited comment on SOLR-10420 at 4/15/17 7:36 AM:
--

I kinda find out the reason why the test failure. There are some notice here
- In current DQ version, for each time we peek() if in-memory queue is empty, 
we will actually look at the ZK to get new elements ( watcher are useless in 
this scenario )
- With the patch, for each time we peek()  if in-memory queue is empty, we will 
only look at the ZK nodes when watcher tell us that there are change in our 
queue. So If ZK already contain new items we can return empty.

So this is the reason why the test failure
- overseer.queue <- set a replica down
- overseer run the command successfully
- overseer.queue <- set a replica active
- overseer delay this command ( overseer.workqueue <- set a replica active )
- touch /clusterstate.json to change its version
- overseer.queue <- some ZKWriteCommand, let's call this one ZK1
- overseer change the clusterstate to set replica active
- overseer meet badversion exception
- overseer fetch last element from overseer.workqueue. Here are where problem 
happen, overseer.workqueue.peek() return empty because the watcher is not fired.
- overseer process ZK1, it success -> overseer.workqueue is emptied.


was (Author: caomanhdat):
I kinda find out the reason why the test failure. There are some notice here
- In current DQ version, for each time we peek() if in-memory queue is empty, 
we will actually look at the ZK to get new elements ( watcher are useless in 
this scenario )
- With the patch, for each time we peek()  if in-memory queue is empty, we will 
only look at the ZK nodes when watcher tell us that there are change in our 
queue.

So this is the reason why the test failure
- overseer.queue <- set a replica down
- overseer run the command successfully
- overseer.queue <- set a replica active
- overseer delay this command ( overseer.workqueue <- set a replica active )
- touch /clusterstate.json to change its version
- overseer.queue <- some ZKWriteCommand, let's call this one ZK1
- overseer change the clusterstate to set replica active
- overseer meet badversion exception
- overseer fetch last element from overseer.workqueue. Here are where problem 
happen, overseer.workqueue.peek() return empty because the watcher is not fired.
- overseer process ZK1, it success -> overseer.workqueue is emptied.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

2017-04-15 Thread Cao Manh Dat (JIRA) 

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

Cao Manh Dat commented on SOLR-10420:
-

I'm thinking about two different way to solve this problem :
1. DQ will set lastWatcher = null when we run {{DQ.offer(byte[] data)}} 
sucessfully. Because the overseer.workqueue is locally offered by overseer so 
that will fix the problem. But we changed {{DQ.peek()}} from true positive ( if 
ZK contain new item, we will return that ) to false positive ( if ZK contain 
new item, we may not return that ) so this may inflict other parts as well.
2. each time DQ.peek() is called we will look at the ZK nodes without using the 
watcher.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

2017-04-15 Thread Cao Manh Dat (JIRA) 

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

Cao Manh Dat commented on SOLR-10420:
-

I kinda find out the reason why the test failure. There are some notice here
- In current DQ version, for each time we peek() if in-memory queue is empty, 
we will actually look at the ZK to get new elements ( watcher are useless in 
this scenario )
- With the patch, for each time we peek()  if in-memory queue is empty, we will 
only look at the ZK nodes when watcher tell us that there are change in our 
queue.

So this is the reason why the test failure
- overseer.queue <- set a replica down
- overseer run the command successfully
- overseer.queue <- set a replica active
- overseer delay this command ( overseer.workqueue <- set a replica active )
- touch /clusterstate.json to change its version
- overseer.queue <- some ZKWriteCommand, let's call this one ZK1
- overseer change the clusterstate to set replica active
- overseer meet badversion exception
- overseer fetch last element from overseer.workqueue. Here are where problem 
happen, overseer.workqueue.peek() return empty because the watcher is not fired.
- overseer process ZK1, it success -> overseer.workqueue is emptied.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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