[jira] [Commented] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200811#comment-17200811
]
Colvin Cowie commented on SOLR-14503:
-
Hi [~munendrasn], thanks. Sorry I've not got any time at the moment. Thanks
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-14503.patch, SOLR-14503.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14768) Error 500 on PDF extraction: java.lang.NoClassDefFoundError: org/eclipse/jetty/server/MultiParts
[
https://issues.apache.org/jira/browse/SOLR-14768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192193#comment-17192193
]
Colvin Cowie commented on SOLR-14768:
-
[~dsmiley] thanks, I've built a new solr-core locally with the change from your
PR and it resolves the problems as expected.
> Error 500 on PDF extraction: java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiParts
>
>
> Key: SOLR-14768
> URL: https://issues.apache.org/jira/browse/SOLR-14768
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Solr Cell (Tika extraction)
>Affects Versions: 8.6, 8.6.1
>Reporter: Markus Kalkbrenner
>Assignee: David Smiley
>Priority: Major
> Attachments: Solr v8.6.x fails with multipart MIME in commands.eml,
> Solr v8.6.x fails with multipart MIME in commands.eml, Solr v8.6.x fails with
> multipart MIME in commands.eml
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> See [https://www.mail-archive.com/solr-user@lucene.apache.org/msg152182.html]
> The integration tests of the solarium PHP library and the integration tests
> of the Search API Solr Drupal module both fail on PDF extraction if executed
> on Solr 8.6.
> They still work on Solr 8.5.1 an earlier versions.
> {quote}2020-08-20 12:30:35.279 INFO (qtp855700733-19) [ x:5f3e6ce2810ef]
> o.a.s.u.p.LogUpdateProcessorFactory [5f3e6ce2810ef] webapp=/solr
> path=/update/extract
> params=\{json.nl=flat=0=false=testpdf.pdf=extract-test=true=false=attr_=json}{add=[extract-test
> (1675547519474466816)],commit=} 0 957
> solr8_1 | 2020-08-20 12:30:35.280 WARN (qtp855700733-19) [ ]
> o.e.j.s.HttpChannel /solr/5f3e6ce2810ef/update/extract =>
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/MultiParts
> solr8_1 | at
> org.apache.solr.servlet.SolrRequestParsers.cleanupMultipartFiles(SolrRequestParsers.java:624)
> solr8_1 | java.lang.NoClassDefFoundError: org/eclipse/jetty/server/MultiParts
> solr8_1 | at
> org.apache.solr.servlet.SolrRequestParsers.cleanupMultipartFiles(SolrRequestParsers.java:624)
> ~[?:?]
> solr8_1 | at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:443)
> ~[?:?]
> solr8_1 | at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> ~[?:?]
> solr8_1 | at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> ~[jetty-servlet-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> ~[jetty-servlet-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> ~[jetty-security-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> ~[jetty-servlet-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
>
[jira] [Created] (SOLR-14835) Solr 8.6.x log starts with "XmlConfiguration Ignored arg" warning from Jetty
Colvin Cowie created SOLR-14835:
---
Summary: Solr 8.6.x log starts with "XmlConfiguration Ignored arg"
warning from Jetty
Key: SOLR-14835
URL: https://issues.apache.org/jira/browse/SOLR-14835
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.6.2
Reporter: Colvin Cowie
After moving to 8.6.2 the first lines of the solr.log are
{noformat}
2020-09-06 18:19:09.164 INFO (main) [ ] o.e.j.u.log Logging initialized
@1197ms to org.eclipse.jetty.util.log.Slf4jLog
2020-09-06 18:19:09.226 WARN (main) [ ] o.e.j.u.l.o.e.j.x.XmlConfiguration
Ignored arg:
solr.jetty
{noformat}
This config is declared here:
https://github.com/apache/lucene-solr/blob/5154b6008f54c9d096f5efe9ae347492c23dd780/solr/server/etc/jetty.xml#L33
and has been there for a long time, so I assume it's the bump in Jetty version
that's causing it now.
I'm seeing this in 8.6.2, but I've not gone back to check other versions
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14768) Error 500 on PDF extraction: java.lang.NoClassDefFoundError: org/eclipse/jetty/server/MultiParts
[
https://issues.apache.org/jira/browse/SOLR-14768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191345#comment-17191345
]
Colvin Cowie commented on SOLR-14768:
-
Just to add this to the mix, while having look at this while running 8.6.2 from
Eclipse with the Eclipse Jetty plugin, I hit a ClassCastException. I don't know
what request prompted this to happen, but it looks like there's a couple of
issues
[here|https://github.com/apache/lucene-solr/commit/41b4bec51b6b2b083c5fb2170057e69693b2ff77#diff-c682d1eb01de9a7ab98f75ead0af9dd3R624],
not just the java.lang.NoClassDefFoundError, [~dsmiley]
{noformat}
2020-09-06 17:23:18.044:WARN:oejs.HttpChannel:qtp94345706-152:
/solr/main_index/update
java.lang.ClassCastException:
org.eclipse.jetty.server.MultiParts$MultiPartsUtilParser cannot be cast to
org.eclipse.jetty.server.MultiParts
at
org.apache.solr.servlet.SolrRequestParsers.cleanupMultipartFiles(SolrRequestParsers.java:624)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:443)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:500)
at
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
at
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
at java.lang.Thread.run(Thread.java:748){noformat}
> Error 500 on PDF extraction: java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiParts
>
>
> Key: SOLR-14768
> URL: https://issues.apache.org/jira/browse/SOLR-14768
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Solr Cell (Tika extraction)
>Affects Versions: 8.6, 8.6.1
>Reporter: Markus Kalkbrenner
>Priority: Major
> Attachments: Solr v8.6.x fails with multipart MIME in commands.eml,
> Solr v8.6.x fails with multipart MIME in commands.eml
>
>
> See [https://www.mail-archive.com/solr-user@lucene.apache.org/msg152182.html]
> The integration tests of the solarium PHP library and the
[jira] [Commented] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189267#comment-17189267 ] Colvin Cowie commented on SOLR-14422: - No problem [~epugh], cheers > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.6, 8.5.1, 8.5.2, 8.6.2 >Reporter: Colvin Cowie >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189087#comment-17189087 ] Colvin Cowie commented on SOLR-14422: - This didn't make it into the 8.6 release, it's only been pushed to master [~broustant] [~epugh] > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.5.1, 8.5.2 >Reporter: Colvin Cowie >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.6 > > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180585#comment-17180585
]
Colvin Cowie commented on SOLR-14503:
-
Anyone? :)
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch, SOLR-14503.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14504) ZkController LiveNodesListener has NullPointerException in startup race
[
https://issues.apache.org/jira/browse/SOLR-14504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176291#comment-17176291
]
Colvin Cowie commented on SOLR-14504:
-
[~ab] this did make it into 8.6 right? But it's not been closed/
> ZkController LiveNodesListener has NullPointerException in startup race
> ---
>
> Key: SOLR-14504
> URL: https://issues.apache.org/jira/browse/SOLR-14504
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3,
> 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14504.patch
>
>
> If a NODELOST event happens before the cloudManager is initialized then a
> NullPointerException will occur on this line
> [https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
> {code:java}
> byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
> cloudManager.getTimeSource().getEpochTimeNs())); {code}
> Rather than accessing cloudManager directly, getSolrCloudManager() should be
> called.
>
> This happens very rarely, but if it happens it will stop Solr starting,
> result in "CoreContainer is either not initialized or shutting down". Snippet
> from 8.3.1
> {noformat}
> 2020-05-19 03:44:40.241 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.245 INFO (zkConnectionManagerCallback-11-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.245 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.359 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.361 INFO (zkConnectionManagerCallback-13-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.361 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.417 INFO (main) [ ] o.a.s.c.c.ZkStateReader Updated
> live nodes from ZooKeeper... (0) -> (1)
> 2020-05-19
> 03:44:56.606 INFO (zkCallback-12-thread-2) [ ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) ->
> (0)
> 2020-05-19 03:44:56.614 ERROR (main) [ ]
> o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
> property and the logs
> 2020-05-19 03:44:56.639 ERROR (main) [ ] o.a.s.c.SolrCore
> null:java.lang.NullPointerException
> at
> org.apache.solr.cloud.ZkController.lambda$registerLiveNodesListener$10(ZkController.java:1020)
> at
> org.apache.solr.common.cloud.ZkStateReader.registerLiveNodesListener(ZkStateReader.java:880)
> at
> org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)
> at org.apache.solr.cloud.ZkController.init(ZkController.java:917)
> at org.apache.solr.cloud.ZkController.(ZkController.java:473)
> at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:115)
> at
> org.apache.solr.core.CoreContainer.load(CoreContainer.java:631){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148919#comment-17148919 ] Colvin Cowie commented on SOLR-14422: - Looks fine to me [~epugh] (y) > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.5.1, 8.5.2 >Reporter: Colvin Cowie >Priority: Minor > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147641#comment-17147641 ] Colvin Cowie commented on SOLR-14422: - Oh, forgot about this. [~epugh] [~krisden] do you think we can get this into 8.6? > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.5.1, 8.5.2 >Reporter: Colvin Cowie >Priority: Minor > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie updated SOLR-14422: Affects Version/s: 8.5.2 > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.5.1, 8.5.2 >Reporter: Colvin Cowie >Priority: Minor > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14504) ZkController LiveNodesListener has NullPointerException in startup race
[
https://issues.apache.org/jira/browse/SOLR-14504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14504:
Security: (was: Public)
> ZkController LiveNodesListener has NullPointerException in startup race
> ---
>
> Key: SOLR-14504
> URL: https://issues.apache.org/jira/browse/SOLR-14504
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3,
> 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14504.patch
>
>
> If a NODELOST event happens before the cloudManager is initialized then a
> NullPointerException will occur on this line
> [https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
> {code:java}
> byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
> cloudManager.getTimeSource().getEpochTimeNs())); {code}
> Rather than accessing cloudManager directly, getSolrCloudManager() should be
> called.
>
> This happens very rarely, but if it happens it will stop Solr starting,
> result in "CoreContainer is either not initialized or shutting down". Snippet
> from 8.3.1
> {noformat}
> 2020-05-19 03:44:40.241 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.245 INFO (zkConnectionManagerCallback-11-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.245 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.359 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.361 INFO (zkConnectionManagerCallback-13-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.361 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.417 INFO (main) [ ] o.a.s.c.c.ZkStateReader Updated
> live nodes from ZooKeeper... (0) -> (1)
> 2020-05-19
> 03:44:56.606 INFO (zkCallback-12-thread-2) [ ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) ->
> (0)
> 2020-05-19 03:44:56.614 ERROR (main) [ ]
> o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
> property and the logs
> 2020-05-19 03:44:56.639 ERROR (main) [ ] o.a.s.c.SolrCore
> null:java.lang.NullPointerException
> at
> org.apache.solr.cloud.ZkController.lambda$registerLiveNodesListener$10(ZkController.java:1020)
> at
> org.apache.solr.common.cloud.ZkStateReader.registerLiveNodesListener(ZkStateReader.java:880)
> at
> org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)
> at org.apache.solr.cloud.ZkController.init(ZkController.java:917)
> at org.apache.solr.cloud.ZkController.(ZkController.java:473)
> at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:115)
> at
> org.apache.solr.core.CoreContainer.load(CoreContainer.java:631){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14503:
Security: (was: Public)
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch, SOLR-14503.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14416) Nodes view doesn't work correctly when Solr is hosted on Windows
[
https://issues.apache.org/jira/browse/SOLR-14416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14416:
Security: (was: Public)
> Nodes view doesn't work correctly when Solr is hosted on Windows
>
>
> Key: SOLR-14416
> URL: https://issues.apache.org/jira/browse/SOLR-14416
> Project: Solr
> Issue Type: Bug
> Components: Admin UI
>Affects Versions: 7.7.2, 8.1, 8.2, 8.1.1, 8.3, 8.4, 8.3.1, 8.4.1
>Reporter: Colvin Cowie
>Priority: Minor
> Fix For: 8.5
>
> Attachments: screenshot-1.png
>
>
> I sent a message about this on the mailing list a long time ago and got no
> replies.
> Originally I saw it on 8.1.1, it's a problem in 8.3.1 and I don't expect it's
> fixed in 8.5, but I will check.
> On Solr 8.1.1 / 7.7.2 with Oracle 1.8.0_191 25.191-b12 with Solr running on
> Windows 10
> In the Nodes view of the Admin
> UI,http://localhost:8983/solr/#/~cloud?view=nodes there is a refresh button.
> However when you click it, the only thing that gets visibly refreshed is the
> 'bar chart' (not sure what to call it - it's shown when you choose show
> details) of the index shard size on disk. The other stats do not update.
> Also, when there is more than one node, only some of the node information is
> shown
> !screenshot-1.png!
> Firefox dev console shows:
> {noformat}
> _Error: s.system.uptime is undefined
> nodesSubController/$scope.reload/<@http://localhost:8983/solr/js/angular/controllers/cloud.js:384:11
> v/http://localhost:8983/solr/libs/angular-resource.min.js:33:133
> processQueue@http://localhost:8983/solr/libs/angular.js:13193:27
> scheduleProcessQueue/<@http://localhost:8983/solr/libs/angular.js:13209:27
> $eval@http://localhost:8983/solr/libs/angular.js:14406:16
> $digest@http://localhost:8983/solr/libs/angular.js:14222:15
> $apply@http://localhost:8983/solr/libs/angular.js:14511:13
> done@http://localhost:8983/solr/libs/angular.js:9669:36
> completeRequest@http://localhost:8983/solr/libs/angular.js:9859:7
> requestLoaded@http://localhost:8983/solr/libs/angular.js:9800:9_
> {noformat}
> The system response has upTimeMs in it for the JVM/JMX properties, but no
> system/uptime
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":63},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":49},
> "mode":"solrcloud",
> "zkHost":"localhost:9983",
> "solr_home":"...",
> "lucene":{
> "solr-spec-version":"8.1.1",
> "solr-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:20:01",
> "lucene-spec-version":"8.1.1",
> "lucene-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:15:24"},
> "jvm":{
> "version":"1.8.0_211 25.211-b12",
> "name":"Oracle Corporation Java HotSpot(TM) 64-Bit Server VM",
> "spec":{
> "vendor":"Oracle Corporation",
> "name":"Java Platform API Specification",
> "version":"1.8"},
> "jre":{
> "vendor":"Oracle Corporation",
> "version":"1.8.0_211"},
> "vm":{
> "vendor":"Oracle Corporation",
> "name":"Java HotSpot(TM) 64-Bit Server VM",
> "version":"25.211-b12"},
> "processors":8,
> "memory":{
> "free":"1.4 GB",
> "total":"2 GB",
> "max":"2 GB",
> "used":"566.7 MB (%27.7)",
> "raw":{
> "free":1553268432,
> "total":2147483648,
> "max":2147483648,
> "used":594215216,
> "used%":27.670302242040634}},
> "jmx":{
> "bootclasspath":"...",
> "classpath":"start.jar",
> "commandLineArgs":[...],
> "startTime":"2019-06-20T11:41:58.955Z",
> "upTimeMS":516602}},
> "system":{
> "name":"Windows 10",
> "arch":"amd64",
> "availableProcessors":8,
> "systemLoadAverage":-1.0,
> "version":"10.0",
> "committedVirtualMemorySize":2709114880,
> "freePhysicalMemorySize":16710127616,
> "freeSwapSpaceSize":16422531072,
> "processCpuLoad":0.13941671744473663,
> "processCpuTime":194609375000,
> "systemCpuLoad":0.25816002967796037,
> "totalPhysicalMemorySize":34261250048,
> "totalSwapSpaceSize":39361523712},
> "node":"localhost:8983_solr"}}
> {noformat}
> The SystemInfoHandler does this:
> {code}
> // Try some command line things:
> try {
> if (!Constants.WINDOWS) {
> info.add( "uname", execute( "uname -a" ) );
> info.add( "uptime", execute( "uptime" ) );
> }
> } catch( Exception ex ) {
> log.warn("Unable to execute command line tools to get operating system
> properties.", ex);
> }
> {code}
> Which appears to be the problem
[jira] [Updated] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie updated SOLR-14422: Security: (was: Public) > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.5.1 >Reporter: Colvin Cowie >Priority: Minor > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Security: (was: Public)
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a patch
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Security: (was: Public)
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 8.6
>
> Attachments: FuzzyHammer.java, SOLR-14428-WeakReferences.patch,
> image-2020-04-23-09-18-06-070.png, image-2020-04-24-20-09-31-179.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
> ~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14504) ZkController LiveNodesListener has NullPointerException in startup race
[
https://issues.apache.org/jira/browse/SOLR-14504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113064#comment-17113064
]
Colvin Cowie edited comment on SOLR-14504 at 5/21/20, 11:01 AM:
Without making big changes to ZkController's actual implementation, I don't
really see a way to write a useful (automated) regression test for this.
[~ab] what are you thoughts on just fixing it without a test? Or can you see a
good way to test it?
was (Author: cjcowie):
Without making big changes to ZkController's actual implementation, I don't
really see a way to write a useful (automated) regression test for this.
[~ab] what are you thoughts on just fixing it withtout a test? Or can you see a
good way to test it?
> ZkController LiveNodesListener has NullPointerException in startup race
> ---
>
> Key: SOLR-14504
> URL: https://issues.apache.org/jira/browse/SOLR-14504
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3,
> 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14504.patch
>
>
> If a NODELOST event happens before the cloudManager is initialized then a
> NullPointerException will occur on this line
> [https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
> {code:java}
> byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
> cloudManager.getTimeSource().getEpochTimeNs())); {code}
> Rather than accessing cloudManager directly, getSolrCloudManager() should be
> called.
>
> This happens very rarely, but if it happens it will stop Solr starting,
> result in "CoreContainer is either not initialized or shutting down". Snippet
> from 8.3.1
> {noformat}
> 2020-05-19 03:44:40.241 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.245 INFO (zkConnectionManagerCallback-11-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.245 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.359 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.361 INFO (zkConnectionManagerCallback-13-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.361 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.417 INFO (main) [ ] o.a.s.c.c.ZkStateReader Updated
> live nodes from ZooKeeper... (0) -> (1)
> 2020-05-19
> 03:44:56.606 INFO (zkCallback-12-thread-2) [ ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) ->
> (0)
> 2020-05-19 03:44:56.614 ERROR (main) [ ]
> o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
> property and the logs
> 2020-05-19 03:44:56.639 ERROR (main) [ ] o.a.s.c.SolrCore
> null:java.lang.NullPointerException
> at
> org.apache.solr.cloud.ZkController.lambda$registerLiveNodesListener$10(ZkController.java:1020)
> at
> org.apache.solr.common.cloud.ZkStateReader.registerLiveNodesListener(ZkStateReader.java:880)
> at
> org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)
> at org.apache.solr.cloud.ZkController.init(ZkController.java:917)
> at org.apache.solr.cloud.ZkController.(ZkController.java:473)
> at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:115)
> at
> org.apache.solr.core.CoreContainer.load(CoreContainer.java:631){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113066#comment-17113066
]
Colvin Cowie commented on SOLR-14503:
-
Hi [~caomanhdat] can you take a look at this? Thanks
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch, SOLR-14503.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14504) ZkController LiveNodesListener has NullPointerException in startup race
[
https://issues.apache.org/jira/browse/SOLR-14504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113064#comment-17113064
]
Colvin Cowie commented on SOLR-14504:
-
Without making big changes to ZkController's actual implementation, I don't
really see a way to write a useful (automated) regression test for this.
[~ab] what are you thoughts on just fixing it withtout a test? Or can you see a
good way to test it?
> ZkController LiveNodesListener has NullPointerException in startup race
> ---
>
> Key: SOLR-14504
> URL: https://issues.apache.org/jira/browse/SOLR-14504
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3,
> 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14504.patch
>
>
> If a NODELOST event happens before the cloudManager is initialized then a
> NullPointerException will occur on this line
> [https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
> {code:java}
> byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
> cloudManager.getTimeSource().getEpochTimeNs())); {code}
> Rather than accessing cloudManager directly, getSolrCloudManager() should be
> called.
>
> This happens very rarely, but if it happens it will stop Solr starting,
> result in "CoreContainer is either not initialized or shutting down". Snippet
> from 8.3.1
> {noformat}
> 2020-05-19 03:44:40.241 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.245 INFO (zkConnectionManagerCallback-11-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.245 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.359 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.361 INFO (zkConnectionManagerCallback-13-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.361 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.417 INFO (main) [ ] o.a.s.c.c.ZkStateReader Updated
> live nodes from ZooKeeper... (0) -> (1)
> 2020-05-19
> 03:44:56.606 INFO (zkCallback-12-thread-2) [ ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) ->
> (0)
> 2020-05-19 03:44:56.614 ERROR (main) [ ]
> o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
> property and the logs
> 2020-05-19 03:44:56.639 ERROR (main) [ ] o.a.s.c.SolrCore
> null:java.lang.NullPointerException
> at
> org.apache.solr.cloud.ZkController.lambda$registerLiveNodesListener$10(ZkController.java:1020)
> at
> org.apache.solr.common.cloud.ZkStateReader.registerLiveNodesListener(ZkStateReader.java:880)
> at
> org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)
> at org.apache.solr.cloud.ZkController.init(ZkController.java:917)
> at org.apache.solr.cloud.ZkController.(ZkController.java:473)
> at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:115)
> at
> org.apache.solr.core.CoreContainer.load(CoreContainer.java:631){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14504) ZkController LiveNodesListener has NullPointerException in startup race
[
https://issues.apache.org/jira/browse/SOLR-14504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14504:
Status: Patch Available (was: Open)
> ZkController LiveNodesListener has NullPointerException in startup race
> ---
>
> Key: SOLR-14504
> URL: https://issues.apache.org/jira/browse/SOLR-14504
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3,
> 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14504.patch
>
>
> If a NODELOST event happens before the cloudManager is initialized then a
> NullPointerException will occur on this line
> [https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
> {code:java}
> byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
> cloudManager.getTimeSource().getEpochTimeNs())); {code}
> Rather than accessing cloudManager directly, getSolrCloudManager() should be
> called.
>
> This happens very rarely, but if it happens it will stop Solr starting,
> result in "CoreContainer is either not initialized or shutting down". Snippet
> from 8.3.1
> {noformat}
> 2020-05-19 03:44:40.241 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.245 INFO (zkConnectionManagerCallback-11-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.245 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.359 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.361 INFO (zkConnectionManagerCallback-13-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.361 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.417 INFO (main) [ ] o.a.s.c.c.ZkStateReader Updated
> live nodes from ZooKeeper... (0) -> (1)
> 2020-05-19
> 03:44:56.606 INFO (zkCallback-12-thread-2) [ ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) ->
> (0)
> 2020-05-19 03:44:56.614 ERROR (main) [ ]
> o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
> property and the logs
> 2020-05-19 03:44:56.639 ERROR (main) [ ] o.a.s.c.SolrCore
> null:java.lang.NullPointerException
> at
> org.apache.solr.cloud.ZkController.lambda$registerLiveNodesListener$10(ZkController.java:1020)
> at
> org.apache.solr.common.cloud.ZkStateReader.registerLiveNodesListener(ZkStateReader.java:880)
> at
> org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)
> at org.apache.solr.cloud.ZkController.init(ZkController.java:917)
> at org.apache.solr.cloud.ZkController.(ZkController.java:473)
> at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:115)
> at
> org.apache.solr.core.CoreContainer.load(CoreContainer.java:631){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14504) ZkController LiveNodesListener has NullPointerException in startup race
[
https://issues.apache.org/jira/browse/SOLR-14504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14504:
Attachment: SOLR-14504.patch
> ZkController LiveNodesListener has NullPointerException in startup race
> ---
>
> Key: SOLR-14504
> URL: https://issues.apache.org/jira/browse/SOLR-14504
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3,
> 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14504.patch
>
>
> If a NODELOST event happens before the cloudManager is initialized then a
> NullPointerException will occur on this line
> [https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
> {code:java}
> byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
> cloudManager.getTimeSource().getEpochTimeNs())); {code}
> Rather than accessing cloudManager directly, getSolrCloudManager() should be
> called.
>
> This happens very rarely, but if it happens it will stop Solr starting,
> result in "CoreContainer is either not initialized or shutting down". Snippet
> from 8.3.1
> {noformat}
> 2020-05-19 03:44:40.241 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.245 INFO (zkConnectionManagerCallback-11-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.245 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.359 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.361 INFO (zkConnectionManagerCallback-13-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.361 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.417 INFO (main) [ ] o.a.s.c.c.ZkStateReader Updated
> live nodes from ZooKeeper... (0) -> (1)
> 2020-05-19
> 03:44:56.606 INFO (zkCallback-12-thread-2) [ ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) ->
> (0)
> 2020-05-19 03:44:56.614 ERROR (main) [ ]
> o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
> property and the logs
> 2020-05-19 03:44:56.639 ERROR (main) [ ] o.a.s.c.SolrCore
> null:java.lang.NullPointerException
> at
> org.apache.solr.cloud.ZkController.lambda$registerLiveNodesListener$10(ZkController.java:1020)
> at
> org.apache.solr.common.cloud.ZkStateReader.registerLiveNodesListener(ZkStateReader.java:880)
> at
> org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)
> at org.apache.solr.cloud.ZkController.init(ZkController.java:917)
> at org.apache.solr.cloud.ZkController.(ZkController.java:473)
> at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:115)
> at
> org.apache.solr.core.CoreContainer.load(CoreContainer.java:631){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14504) ZkController LiveNodesListener has NullPointerException in startup race
[
https://issues.apache.org/jira/browse/SOLR-14504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113034#comment-17113034
]
Colvin Cowie edited comment on SOLR-14504 at 5/21/20, 10:16 AM:
So with breakpoints on in a debugger it's easy to reproduce this, but I'm not
seeing a _nice_ way to write a test for it, at least not in the
ZkControllerTest. There's a lot of stuff happening in the constructor of the
ZkController (both registerLiveNodesListener and getSolrCloudManager are
called, so the race only exists between those calls) and
registerLiveNodesListener is private.
I've gotten part way to testing it by constructing the ZkController on another
thread, but then the NullPointerException can just be lost in a callback
thread's stack... The NullPointerException causing the Core container load to
fail can only happen when a node lost event occurs in the initial {{at
org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)}}
In fact it seems as though the NPE on startup can only happen if a node is lost
between the first call to getLiveNodes() and the second call to getLiveNodes()
in org.apache.solr.common.cloud.ZkStateReader#registerLiveNodesListener
{code:java}
if (listener.onChange(new TreeSet<>(getClusterState().getLiveNodes()), new
TreeSet<>(getClusterState().getLiveNodes( {{code}
since otherwise the LiveNodesListener will just exit before it gets to the
point it uses the cloud manager at.
So the window for it to happen seems to be very small
was (Author: cjcowie):
So with breakpoints on in a debugger it's easy to reproduce this, but I'm not
seeing a _nice_ way to write a test for it, at least not in the
ZkControllerTest. There's a lot of stuff happening in the constructor of the
ZkController (both registerLiveNodesListener and getSolrCloudManager are
called, so the race only exists between those calls) and
registerLiveNodesListener is private.
I've gotten part way to testing it by constructing the ZkController on another
thread, but then the NullPointerException is just lost in a callback thread's
stack... The NullPointerException causing the Core container load to fail can
only happen when a node lost event occurs in the initial {{at
org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)}}
In fact it seems as though the NPE on startup can only happen if a node is lost
between the first call to getLiveNodes() and the second call to getLiveNodes()
in org.apache.solr.common.cloud.ZkStateReader#registerLiveNodesListener
{code:java}
if (listener.onChange(new TreeSet<>(getClusterState().getLiveNodes()), new
TreeSet<>(getClusterState().getLiveNodes( {{code}
since otherwise the LiveNodesListener will just exit before it gets to the
point it uses the cloud manager at
> ZkController LiveNodesListener has NullPointerException in startup race
> ---
>
> Key: SOLR-14504
> URL: https://issues.apache.org/jira/browse/SOLR-14504
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3,
> 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
>
> If a NODELOST event happens before the cloudManager is initialized then a
> NullPointerException will occur on this line
> [https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
> {code:java}
> byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
> cloudManager.getTimeSource().getEpochTimeNs())); {code}
> Rather than accessing cloudManager directly, getSolrCloudManager() should be
> called.
>
> This happens very rarely, but if it happens it will stop Solr starting,
> result in "CoreContainer is either not initialized or shutting down". Snippet
> from 8.3.1
> {noformat}
> 2020-05-19 03:44:40.241 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.245 INFO (zkConnectionManagerCallback-11-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.245 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.359 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.361 INFO (zkConnectionManagerCallback-13-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.361 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.417 INFO (main) [ ] o.a.s.c.c.ZkStateReader Updated
> live nodes
[jira] [Comment Edited] (SOLR-14504) ZkController LiveNodesListener has NullPointerException in startup race
[
https://issues.apache.org/jira/browse/SOLR-14504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113034#comment-17113034
]
Colvin Cowie edited comment on SOLR-14504 at 5/21/20, 10:15 AM:
So with breakpoints on in a debugger it's easy to reproduce this, but I'm not
seeing a _nice_ way to write a test for it, at least not in the
ZkControllerTest. There's a lot of stuff happening in the constructor of the
ZkController (both registerLiveNodesListener and getSolrCloudManager are
called, so the race only exists between those calls) and
registerLiveNodesListener is private.
I've gotten part way to testing it by constructing the ZkController on another
thread, but then the NullPointerException is just lost in a callback thread's
stack... The NullPointerException causing the Core container load to fail can
only happen when a node lost event occurs in the initial {{at
org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)}}
In fact it seems as though the NPE on startup can only happen if a node is lost
between the first call to getLiveNodes() and the second call to getLiveNodes()
in org.apache.solr.common.cloud.ZkStateReader#registerLiveNodesListener
{code:java}
if (listener.onChange(new TreeSet<>(getClusterState().getLiveNodes()), new
TreeSet<>(getClusterState().getLiveNodes( {{code}
since otherwise the LiveNodesListener will just exit before it gets to the
point it uses the cloud manager at
was (Author: cjcowie):
So with breakpoints on in a debugger it's easy to reproduce this, but I'm not
seeing a _nice_ way to write a test for it, at least not in the
ZkControllerTest. There's a lot of stuff happening in the constructor of the
ZkController (both registerLiveNodesListener and getSolrCloudManager are
called, so the race only exists between those calls) and
registerLiveNodesListener is private.
I've gotten part way to testing it by constructing the ZkController on another
thread, but then the NullPointerException is just lost in a callback thread's
stack... The NullPointerException causing the Core container load to fail can
only happen when a node lost event occurs in the initial {{at
org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)}}
> ZkController LiveNodesListener has NullPointerException in startup race
> ---
>
> Key: SOLR-14504
> URL: https://issues.apache.org/jira/browse/SOLR-14504
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3,
> 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
>
> If a NODELOST event happens before the cloudManager is initialized then a
> NullPointerException will occur on this line
> [https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
> {code:java}
> byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
> cloudManager.getTimeSource().getEpochTimeNs())); {code}
> Rather than accessing cloudManager directly, getSolrCloudManager() should be
> called.
>
> This happens very rarely, but if it happens it will stop Solr starting,
> result in "CoreContainer is either not initialized or shutting down". Snippet
> from 8.3.1
> {noformat}
> 2020-05-19 03:44:40.241 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.245 INFO (zkConnectionManagerCallback-11-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.245 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.359 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.361 INFO (zkConnectionManagerCallback-13-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.361 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.417 INFO (main) [ ] o.a.s.c.c.ZkStateReader Updated
> live nodes from ZooKeeper... (0) -> (1)
> 2020-05-19
> 03:44:56.606 INFO (zkCallback-12-thread-2) [ ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) ->
> (0)
> 2020-05-19 03:44:56.614 ERROR (main) [ ]
> o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
> property and the logs
> 2020-05-19 03:44:56.639 ERROR (main) [ ] o.a.s.c.SolrCore
> null:java.lang.NullPointerException
> at
> org.apache.solr.cloud.ZkController.lambda$registerLiveNodesListener$10(ZkController.java:1020)
> at
>
[jira] [Commented] (SOLR-14504) ZkController LiveNodesListener has NullPointerException in startup race
[
https://issues.apache.org/jira/browse/SOLR-14504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113034#comment-17113034
]
Colvin Cowie commented on SOLR-14504:
-
So with breakpoints on in a debugger it's easy to reproduce this, but I'm not
seeing a _nice_ way to write a test for it, at least not in the
ZkControllerTest. There's a lot of stuff happening in the constructor of the
ZkController (both registerLiveNodesListener and getSolrCloudManager are
called, so the race only exists between those calls) and
registerLiveNodesListener is private.
I've gotten part way to testing it by constructing the ZkController on another
thread, but then the NullPointerException is just lost in a callback thread's
stack... The NullPointerException causing the Core container load to fail can
only happen when a node lost event occurs in the initial {{at
org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)}}
> ZkController LiveNodesListener has NullPointerException in startup race
> ---
>
> Key: SOLR-14504
> URL: https://issues.apache.org/jira/browse/SOLR-14504
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3,
> 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
>
> If a NODELOST event happens before the cloudManager is initialized then a
> NullPointerException will occur on this line
> [https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
> {code:java}
> byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
> cloudManager.getTimeSource().getEpochTimeNs())); {code}
> Rather than accessing cloudManager directly, getSolrCloudManager() should be
> called.
>
> This happens very rarely, but if it happens it will stop Solr starting,
> result in "CoreContainer is either not initialized or shutting down". Snippet
> from 8.3.1
> {noformat}
> 2020-05-19 03:44:40.241 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.245 INFO (zkConnectionManagerCallback-11-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.245 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.359 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.361 INFO (zkConnectionManagerCallback-13-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.361 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.417 INFO (main) [ ] o.a.s.c.c.ZkStateReader Updated
> live nodes from ZooKeeper... (0) -> (1)
> 2020-05-19
> 03:44:56.606 INFO (zkCallback-12-thread-2) [ ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) ->
> (0)
> 2020-05-19 03:44:56.614 ERROR (main) [ ]
> o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
> property and the logs
> 2020-05-19 03:44:56.639 ERROR (main) [ ] o.a.s.c.SolrCore
> null:java.lang.NullPointerException
> at
> org.apache.solr.cloud.ZkController.lambda$registerLiveNodesListener$10(ZkController.java:1020)
> at
> org.apache.solr.common.cloud.ZkStateReader.registerLiveNodesListener(ZkStateReader.java:880)
> at
> org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)
> at org.apache.solr.cloud.ZkController.init(ZkController.java:917)
> at org.apache.solr.cloud.ZkController.(ZkController.java:473)
> at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:115)
> at
> org.apache.solr.core.CoreContainer.load(CoreContainer.java:631){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14505) Intermittent NPE in ZkController.registerLiveNodesListener()
[
https://issues.apache.org/jira/browse/SOLR-14505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113005#comment-17113005
]
Colvin Cowie commented on SOLR-14505:
-
Oh dear, another race condition: I created
https://issues.apache.org/jira/browse/SOLR-14504 a little while ago :)
> Intermittent NPE in ZkController.registerLiveNodesListener()
>
>
> Key: SOLR-14505
> URL: https://issues.apache.org/jira/browse/SOLR-14505
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.3.1
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Minor
>
> Reported by [~cjcowie] in SOLR-13072 & mailing lists:
> "Running on Solr 8.3.1
> {code:java}
> 2020-05-19 03:44:40.220 INFO (main) [ ] o.a.s.c.ZkContainer Zookeeper
> client=X:9983/_cluster
> 2020-05-19 03:44:40.238 INFO (main) [ ] o.a.s.c.c.SolrZkClient Using
> ZkCredentialsProvider:
> xxx.zookeeper.auth.internal.EncodedZkCredentialsProvider
> 2020-05-19 03:44:40.241 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.245 INFO (zkConnectionManagerCallback-11-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.245 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.359 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.361 INFO (zkConnectionManagerCallback-13-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.361 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.417 INFO (main) [ ] o.a.s.c.c.ZkStateReader Updated
> live nodes from ZooKeeper... (0) -> (1)
> 2020-05-19 03:44:56.606 INFO (zkCallback-12-thread-2) [ ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) -> (0)
> 2020-05-19 03:44:56.614 ERROR (main) [ ] o.a.s.s.SolrDispatchFilter Could
> not start Solr. Check solr/home property and the logs
> 2020-05-19 03:44:56.639 ERROR (main) [ ] o.a.s.c.SolrCore
> null:java.lang.NullPointerException
> at
> org.apache.solr.cloud.ZkController.lambda$registerLiveNodesListener$10(ZkController.java:1020)
> at
> org.apache.solr.common.cloud.ZkStateReader.registerLiveNodesListener(ZkStateReader.java:880)
> at
> org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)
> at org.apache.solr.cloud.ZkController.init(ZkController.java:917)
> at org.apache.solr.cloud.ZkController.(ZkController.java:473)
> at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:115)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:631)at
> xxx.solr.servlet.RobustSolrDispatchFilter.createCoreContainer(RobustSolrDispatchFilter.java:71)
> {code}
> I couldn't find any bug reports in JIRA for the NPE.
>
> Here's the full log
> [https://drive.google.com/open?id=1hQrF25blNgKLXijOMYJ30wn-Lfy6uKVm]
>
> The NPE is coming from
> [https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
>
> _byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
> cloudManager.getTimeSource().getEpochTimeNs()));_
> so I don't know whether it's the cloudManager or the time source that's null.
> That bit of the ZkController was added by
> https://issues.apache.org/jira/browse/SOLR-13072 and I see it is only hit if
>
> _zkStateReader.getAutoScalingConfig().hasTriggerForEvents(TriggerEventType.NODELOST);_
>
> We have never (knowingly) configured autoscaling and we don't use it, but I
> see the autoscaling files are present in ZK. Is the autoscaling.json etc
> created by default when it is absent in ZooKeeper?
>
> The interesting bit of the log above, aside from the NPE, is this:
> _2020-05-19 03:44:40.417 INFO (main) [ ] o.a.s.c.c.ZkStateReader Updated
> live nodes from ZooKeeper... (0) -> (1)_
> _2020-05-19 03:44:56.606 INFO (zkCallback-12-thread-2) [ ]
> o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) -> (0)_
> Which suggests to me that there's either a race condition or the problem is
> caused by some zookeeper outage during startup. Since there's a 16 second gap
> between those messages.
>
> It's possible that the problem is in some way caused by our own code in
> xxx.solr.servlet.RobustSolrDispatchFilter which wraps the
> SolrDispatchFIlter, and creates a SolrZkClient in a try/with resources (so
> should be autoclosed), but that all happens before createCoreContainer is
> called."
--
This message was sent by Atlassian Jira
[jira] [Updated] (SOLR-14504) ZkController LiveNodesListener has NullPointerException in startup race
[
https://issues.apache.org/jira/browse/SOLR-14504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14504:
Description:
If a NODELOST event happens before the cloudManager is initialized then a
NullPointerException will occur on this line
[https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
{code:java}
byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
cloudManager.getTimeSource().getEpochTimeNs())); {code}
Rather than accessing cloudManager directly, getSolrCloudManager() should be
called.
This happens very rarely, but if it happens it will stop Solr starting, result
in "CoreContainer is either not initialized or shutting down". Snippet from
8.3.1
{noformat}
2020-05-19 03:44:40.241 INFO (main) [ ] o.a.s.c.c.ConnectionManager Waiting
for client to connect to ZooKeeper
2020-05-19 03:44:40.245 INFO (zkConnectionManagerCallback-11-thread-1) [ ]
o.a.s.c.c.ConnectionManager zkClient has connected
2020-05-19 03:44:40.245 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
is connected to ZooKeeper
2020-05-19 03:44:40.359 INFO (main) [ ] o.a.s.c.c.ConnectionManager Waiting
for client to connect to ZooKeeper
2020-05-19 03:44:40.361 INFO (zkConnectionManagerCallback-13-thread-1) [ ]
o.a.s.c.c.ConnectionManager zkClient has connected
2020-05-19 03:44:40.361 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
is connected to ZooKeeper
2020-05-19 03:44:40.417 INFO (main) [ ] o.a.s.c.c.ZkStateReader Updated live
nodes from ZooKeeper... (0) -> (1)
2020-05-19
03:44:56.606 INFO (zkCallback-12-thread-2) [ ]
o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (1) ->
(0)
2020-05-19 03:44:56.614 ERROR (main) [ ]
o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
property and the logs
2020-05-19 03:44:56.639 ERROR (main) [ ] o.a.s.c.SolrCore
null:java.lang.NullPointerException
at
org.apache.solr.cloud.ZkController.lambda$registerLiveNodesListener$10(ZkController.java:1020)
at
org.apache.solr.common.cloud.ZkStateReader.registerLiveNodesListener(ZkStateReader.java:880)
at
org.apache.solr.cloud.ZkController.registerLiveNodesListener(ZkController.java:1035)
at org.apache.solr.cloud.ZkController.init(ZkController.java:917)
at org.apache.solr.cloud.ZkController.(ZkController.java:473)
at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:115)
at
org.apache.solr.core.CoreContainer.load(CoreContainer.java:631){noformat}
was:
If a NODELOST event happens before the cloudManager is initialized then a
NullPointerException will occur on this line
[https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
{code:java}
byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
cloudManager.getTimeSource().getEpochTimeNs())); {code}
Rather than accessing cloudManager directly, getSolrCloudManager() should be
called
> ZkController LiveNodesListener has NullPointerException in startup race
> ---
>
> Key: SOLR-14504
> URL: https://issues.apache.org/jira/browse/SOLR-14504
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3,
> 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
>
> If a NODELOST event happens before the cloudManager is initialized then a
> NullPointerException will occur on this line
> [https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
> {code:java}
> byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
> cloudManager.getTimeSource().getEpochTimeNs())); {code}
> Rather than accessing cloudManager directly, getSolrCloudManager() should be
> called.
>
> This happens very rarely, but if it happens it will stop Solr starting,
> result in "CoreContainer is either not initialized or shutting down". Snippet
> from 8.3.1
> {noformat}
> 2020-05-19 03:44:40.241 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.245 INFO (zkConnectionManagerCallback-11-thread-1) [ ]
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2020-05-19 03:44:40.245 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client
> is connected to ZooKeeper
> 2020-05-19 03:44:40.359 INFO (main) [ ] o.a.s.c.c.ConnectionManager
> Waiting for client to connect to ZooKeeper
> 2020-05-19 03:44:40.361 INFO
[jira] [Created] (SOLR-14504) ZkController LiveNodesListener has NullPointerException in startup race
Colvin Cowie created SOLR-14504:
---
Summary: ZkController LiveNodesListener has NullPointerException
in startup race
Key: SOLR-14504
URL: https://issues.apache.org/jira/browse/SOLR-14504
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.5.1, 8.4.1, 8.5, 8.3.1, 8.4, 8.3, 8.1.1, 7.7.3, 8.2,
8.1, 8.0, 7.7.2, 7.7.1, 7.7
Reporter: Colvin Cowie
If a NODELOST event happens before the cloudManager is initialized then a
NullPointerException will occur on this line
[https://github.com/apache/lucene-solr/blob/c18666ad05afc02979c150aacd4810cff02e43f3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1020]
{code:java}
byte[] json = Utils.toJSON(Collections.singletonMap("timestamp",
cloudManager.getTimeSource().getEpochTimeNs())); {code}
Rather than accessing cloudManager directly, getSolrCloudManager() should be
called
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112489#comment-17112489
]
Colvin Cowie commented on SOLR-14503:
-
Updated the patch with some changes to {{ZkFailoverTest}} which fail without
the constructor change and pass with it.
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch, SOLR-14503.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112472#comment-17112472
]
Colvin Cowie edited comment on SOLR-14503 at 5/20/20, 5:57 PM:
---
I see {{ZkFailoverTest}} was added for SOLR-5129, but because it does
{{}}{{Thread.sleep({color:#ff}5000{color});}} with {{waitForZk}} set to 60
it doesn't stop the zk server for long enough for it to exceed either the
configured timeout or the unconfigured DEFAULT_CLIENT_CONNECT_TIMEOUT of 30
seconds.
-I've tried modifying the test to cover both a successful start and the
configured timeout being exceeded, but I can't quite get it to work with both
cases at the same time since I seem to end up with the server dead when the
second test starts, and I'm not familiar enough with way these tests are
written to know what the right way to write these tests is.-
-If I simply duplicate the existing test method so that there's two test cases
doing the same thing, it also fails. So it's not specific to the case that I'm
adding.-
Edit: I see, it's because {{ZkFailoverTest}} is a SolrCloudTestCase and the
zookeeper is left shutdown at the end of the test, but no new instance is
created at the start of the next test
was (Author: cjcowie):
I see {{ZkFailoverTest}} was added for SOLR-5129, but because it does
{{}}{{Thread.sleep({color:#ff}5000{color});}} with {{waitForZk}} set to 60
it doesn't stop the zk server for long enough for it to exceed either the
configured timeout or the unconfigured DEFAULT_CLIENT_CONNECT_TIMEOUT of 30
seconds.
I've tried modifying the test to cover both a successful start and the
configured timeout being exceeded, but I can't quite get it to work with both
cases at the same time since I seem to end up with the server dead when the
second test starts, and I'm not familiar enough with way these tests are
written to know what the right way to write these tests is.
If I simply duplicate the existing test method so that there's two test cases
doing the same thing, it also fails. So it's not specific to the case that I'm
adding. [^flawed-test.patch]
Edit: I see, it's because {{ZkFailoverTest}} is a SolrCloudTestCase and the
zookeeper is left shutdown at the end of the test, but no new instance is
created at the start of the next test
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch, SOLR-14503.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14503:
Attachment: (was: flawed-test.patch)
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch, SOLR-14503.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14503:
Attachment: SOLR-14503.patch
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch, SOLR-14503.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112472#comment-17112472
]
Colvin Cowie edited comment on SOLR-14503 at 5/20/20, 5:42 PM:
---
I see {{ZkFailoverTest}} was added for SOLR-5129, but because it does
{{}}{{Thread.sleep({color:#ff}5000{color});}} with {{waitForZk}} set to 60
it doesn't stop the zk server for long enough for it to exceed either the
configured timeout or the unconfigured DEFAULT_CLIENT_CONNECT_TIMEOUT of 30
seconds.
I've tried modifying the test to cover both a successful start and the
configured timeout being exceeded, but I can't quite get it to work with both
cases at the same time since I seem to end up with the server dead when the
second test starts, and I'm not familiar enough with way these tests are
written to know what the right way to write these tests is.
If I simply duplicate the existing test method so that there's two test cases
doing the same thing, it also fails. So it's not specific to the case that I'm
adding. [^flawed-test.patch]
Edit: I see, it's because {{ZkFailoverTest}} is a SolrCloudTestCase and the
zookeeper is left shutdown at the end of the test, but no new instance is
created at the start of the next test
was (Author: cjcowie):
I see {{ZkFailoverTest}} was added for SOLR-5129, but because it does
{{}}{{Thread.sleep({color:#ff}5000{color});}} with {{waitForZk}} set to 60
it doesn't stop the zk server for long enough for it to exceed either the
configured timeout or the unconfigured DEFAULT_CLIENT_CONNECT_TIMEOUT of 30
seconds.
I've tried modifying the test to cover both a successful start and the
configured timeout being exceeded, but I can't quite get it to work with both
cases at the same time since I seem to end up with the server dead when the
second test starts, and I'm not familiar enough with way these tests are
written to know what the right way to write these tests is.
If I simply duplicate the existing test method so that there's two test cases
doing the same thing, it also fails. So it's not specific to the case that I'm
adding. [^flawed-test.patch]
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch, flawed-test.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112472#comment-17112472
]
Colvin Cowie commented on SOLR-14503:
-
I see {{ZkFailoverTest}} was added for SOLR-5129, but because it does
{{}}{{Thread.sleep({color:#ff}5000{color});}} with {{waitForZk}} set to 60
it doesn't stop the zk server for long enough for it to exceed either the
configured timeout or the unconfigured DEFAULT_CLIENT_CONNECT_TIMEOUT of 30
seconds.
I've tried modifying the test to cover both a successful start and the
configured timeout being exceeded, but I can't quite get it to work with both
cases at the same time since I seem to end up with the server dead when the
second test starts, and I'm not familiar enough with way these tests are
written to know what the right way to write these tests is.
If I simply duplicate the existing test method so that there's two test cases
doing the same thing, it also fails. So it's not specific to the case that I'm
adding. [^flawed-test.patch]
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch, flawed-test.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14503:
Attachment: (was: SOLR-14503-flawed-test.patch)
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch, flawed-test.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14503:
Attachment: flawed-test.patch
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch, flawed-test.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14503:
Attachment: SOLR-14503-flawed-test.patch
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503-flawed-test.patch, SOLR-14503.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14503:
Description:
When starting Solr in cloud mode, if zookeeper is not available within 30
seconds, then core container intialization fails and the node will not recover
when zookeeper is available.
I believe SOLR-5129 should have addressed this issue, however it doesn't quite
do so for two reasons:
#
[https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}} rather
than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
is used even when you specify a different waitForZk value
# bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
environment property
[https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
appears in the solr.in.cmd as an example.
I will attach a patch that fixes the above.
was:
When starting Solr in cloud mode, if zookeeper is not available within 30
seconds, then core container intialization fails and the node will not recover
when zookeeper is available.
I believe SOLR-5129 should have addressed this issue, however it doesn't quite
do so for two reasons:
#
[https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}} rather
than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
is used
# bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
environment property
[https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
appears in the solr.in.cmd as an example.
I will attach a patch that fixes the above.
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14503:
Status: Patch Available (was: Open)
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14503:
Attachment: SOLR-14503.patch
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14503:
Affects Version/s: 7.0.1
7.1
7.2
7.2.1
7.3
7.3.1
7.4
7.5
7.6
7.7
7.7.1
7.7.2
8.0
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.0.1, 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7,
> 7.7.1, 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14503:
Affects Version/s: (was: 7.0.1)
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
Colvin Cowie created SOLR-14503:
---
Summary: Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK)
property
Key: SOLR-14503
URL: https://issues.apache.org/jira/browse/SOLR-14503
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.5.1, 8.4.1, 8.5, 8.3.1, 8.4, 8.3, 8.1.1, 7.7.3, 8.2, 8.1
Reporter: Colvin Cowie
When starting Solr in cloud mode, if zookeeper is not available within 30
seconds, then core container intialization fails and the node will not recover
when zookeeper is available.
I believe SOLR-5129 should have addressed this issue, however it doesn't quite
do so for two reasons:
#
[https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}} rather
than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
is used
# bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
environment property
[https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
appears in the solr.in.cmd as an example.
I will attach a patch that fixes the above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13072) Management of markers for nodeLost / nodeAdded events is broken
[
https://issues.apache.org/jira/browse/SOLR-13072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112254#comment-17112254
]
Colvin Cowie commented on SOLR-13072:
-
Hi [~ab] I've seen intermittent NullPointerExceptions in
org.apache.solr.cloud.ZkController.registerLiveNodesListener() which was added
by this issue. I sent an email to the dev mailing list, if you could have a
chance to look at it. Thanks in advance
> Management of markers for nodeLost / nodeAdded events is broken
> ---
>
> Key: SOLR-13072
> URL: https://issues.apache.org/jira/browse/SOLR-13072
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.5, 7.6, 8.0
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 7.7, 8.0, master (9.0)
>
>
> In order to prevent {{nodeLost}} events from being lost when it's the
> Overseer leader that is the node that was lost a mechanism was added to
> record markers for these events by any other live node, in
> {{ZkController.registerLiveNodesListener()}}. As similar mechanism also
> exists for {{nodeAdded}} events.
> On Overseer leader restart if the autoscaling configuration didn't contain
> any triggers that consume {{nodeLost}} events then these markers are removed.
> If there are 1 or more trigger configs that consume {{nodeLost}} events then
> these triggers would read the markers, remove them and generate appropriate
> events.
> However, as the {{NodeMarkersRegistrationTest}} shows this mechanism is
> broken and susceptible to race conditions.
> It's not unusual to have more than 1 {{nodeLost}} trigger because in addition
> to any user-defined triggers there's always one that is automatically defined
> if missing: {{.auto_add_replicas}}. However, if there's more than 1
> {{nodeLost}} trigger then the process of consuming and removing the markers
> becomes non-deterministic - each trigger may pick up (and delete) all, none,
> or some of the markers.
> So as it is now this mechanism is broken if more than 1 {{nodeLost}} or more
> than 1 {{nodeAdded}} trigger is defined.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094309#comment-17094309
]
Colvin Cowie commented on SOLR-14428:
-
{quote}The QueryResultKey could cache by the original string input instead of
the Query object, thus it wouldn't be affected. This would short-circuit query
parsing and be a performance benefit as well?
{quote}
On this point specifically, I think the downside to that would be that any
variations of query strings which can be rewritten to Query objects that are
equal() wouldn't get hits that they currently do, e.g. 'A or B' and 'B or A'
could create equal() Queries. And if the behaviour of the query parser is
modified by params - rather than local params - then the cached results may be
wrong if they're only keyed by the query string, right?
Or do you mean only use the String in the case of excessivly large Query
objects? In which case the first point is a reasonable compromise. I'm not sure
about the second though.
{quote}BTW This issue should probably be a Lucene JIRA issue but let's see
where we go with this thread further.
{quote}
I don't think I can change it now myself. But maybe there should be separate
issue for doing some nice and generic to deal with caching (large) Query
objects which I imagine might be a broader effort, and this/another for
resolving the immediate issue with FuzzyQuery?
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: FuzzyHammer.java, SOLR-14428-WeakReferences.patch,
> image-2020-04-23-09-18-06-070.png, image-2020-04-24-20-09-31-179.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
> ~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Attachment: SOLR-14428-WeakReferences.patch
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: FuzzyHammer.java, SOLR-14428-WeakReferences.patch,
> image-2020-04-23-09-18-06-070.png, image-2020-04-24-20-09-31-179.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
> ~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093772#comment-17093772
]
Colvin Cowie commented on SOLR-14428:
-
That's fair.
I think that having a distinction between the (Query) key used for cache
lookups and the Query object used for actual querying is definitely a _good
thing_. But I don't know enough about the internals of it all, so happy to hear
what other people think.
The one thing I have tried doing just now is using a {{SoftReference}} and a
{{WeakReference}} on the {{automata}} so that it can be GCed and rebuilt if
it's gone. With SoftReferences the OOMEs stop, but the heap usage stays higher,
and with WeakReferences the heap usage looks pretty much the same as in 8.3.1.
I'm not sure though whether it provides any real improvement on how things were
before the changes made in LUCENE-9068, when the automata was just built on
demand. Plus I have never actually used SoftReference or WeakReference before,
so can't claim to truely know the ins and outs of them.
[^SOLR-14428-WeakReferences.patch]
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: FuzzyHammer.java, SOLR-14428-WeakReferences.patch,
> image-2020-04-23-09-18-06-070.png, image-2020-04-24-20-09-31-179.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
> ~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091882#comment-17091882
]
Colvin Cowie edited comment on SOLR-14428 at 4/24/20, 8:52 PM:
---
I did the same thing with {{filters}} and that's ok...
Now I'm thinking, since some Queries must hold references to other queries when
they are constructed, toCacheKey will need to be implemented on those in order
to retrieve the cache key variants of the Queries they are constructed with.
e.g. the clause sets in BooleanQuery
{noformat}
private final Map> clauseSets; // used for
equals/hashcode{noformat}
And any third-party Query implementations that hold on to references to other
Queries would need updating too.
Just seems like there might be quite a lot of fallout from this. Though it
might still be best in the long run.
Also the {{filterCache}} doesn't use QueryResultKey, it's just keyed by the
query SolrCache, so need to update the puts to it too.
Calling toCacheKey on all the puts to the {{filterCache}} in SolrIndexSearcher
has got the memory usage sorted out again with me firing the Fuzzy Queries as fq
was (Author: cjcowie):
I did the same thing with {{filters}} and that's ok...
Now I'm thinking, since some Queries must hold references to other queries when
they are constructed, toCacheKey will need to be implemented on those in order
to retrieve the cache key variants of the Queries they are constructed with.
e.g. the clause sets in BooleanQuery
{noformat}
private final Map> clauseSets; // used for
equals/hashcode{noformat}
And any third-party Query implementations that hold on to references to other
Queries would need updating too.
Just seems like there might be quite a lot of fallout from this.
Also the {{filterCache}} doesn't use QueryResultKey, it's just keyed by the
query SolrCache, so need to update the puts to it too.
Calling toCacheKey on all the puts to the {{filterCache}} in SolrIndexSearcher
has got the memory usage sorted out again with me firing the Fuzzy Queries as fq
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> image-2020-04-24-20-09-31-179.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
> ~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091882#comment-17091882
]
Colvin Cowie edited comment on SOLR-14428 at 4/24/20, 8:45 PM:
---
I did the same thing with {{filters}} and that's ok...
Now I'm thinking, since some Queries must hold references to other queries when
they are constructed, toCacheKey will need to be implemented on those in order
to retrieve the cache key variants of the Queries they are constructed with.
e.g. the clause sets in BooleanQuery
{noformat}
private final Map> clauseSets; // used for
equals/hashcode{noformat}
And any third-party Query implementations that hold on to references to other
Queries would need updating too.
Just seems like there might be quite a lot of fallout from this.
Also the {{filterCache}} doesn't use QueryResultKey, it's just keyed by the
query SolrCache, so need to update the puts to it too.
Calling toCacheKey on all the puts to the {{filterCache}} in SolrIndexSearcher
has got the memory usage sorted out again with me firing the Fuzzy Queries as fq
was (Author: cjcowie):
I did the same thing with {{filters}} and that's ok...
Now I'm thinking, since some Queries must hold references to other queries when
they are constructed, toCacheKey will need to be implemented on those in order
to retrieve the cache key variants of the Queries they are constructed with.
e.g. the clause sets in BooleanQuery
{noformat}
private final Map> clauseSets; // used for
equals/hashcode{noformat}
And any third-party Query implementations that hold on to references to other
Queries would need updating too.
Just seems like there might be quite a lot of fallout from this.
Also the {{filterCache}} doesn't use QueryResultKey, it's just keyed by the
query SolrCache, so need to update the puts to it too.
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> image-2020-04-24-20-09-31-179.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
> ~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091882#comment-17091882
]
Colvin Cowie commented on SOLR-14428:
-
I did the same thing with {{filters}} and that's ok...
Now I'm thinking, since some Queries must hold references to other queries when
they are constructed, toCacheKey will need to be implemented on those in order
to retrieve the cache key variants of the Queries they are constructed with.
e.g. the clause sets in BooleanQuery
{noformat}
private final Map> clauseSets; // used for
equals/hashcode{noformat}
And any third-party Query implementations that hold on to references to other
Queries would need updating too.
Just seems like there might be quite a lot of fallout from this.
Also the {{filterCache}} doesn't use QueryResultKey, it's just keyed by the
query SolrCache, so need to update the puts to it too.
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> image-2020-04-24-20-09-31-179.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
> ~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091869#comment-17091869
]
Colvin Cowie commented on SOLR-14428:
-
Oh yes, you're absolutely right
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> image-2020-04-24-20-09-31-179.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
> ~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091843#comment-17091843
]
Colvin Cowie edited comment on SOLR-14428 at 4/24/20, 7:47 PM:
---
-Ah, I assume the statistics plugin uses RamUsageQueryVisitor, which triggers
the building of the automata-
It's because QueryResultKey gets the ramBytesUsed from the original query still
{code:java}
ramBytesUsed =
BASE_RAM_BYTES_USED +
ramSfields +
RamUsageEstimator.sizeOfObject(query,
RamUsageEstimator.QUERY_DEFAULT_RAM_BYTES_USED) +
RamUsageEstimator.sizeOfObject(filters,
RamUsageEstimator.QUERY_DEFAULT_RAM_BYTES_USED);
{code}
was (Author: cjcowie):
Ah, I assume the statistics plugin uses RamUsageQueryVisitor, which triggers
the building of the automata
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> image-2020-04-24-20-09-31-179.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
> ~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091843#comment-17091843
]
Colvin Cowie edited comment on SOLR-14428 at 4/24/20, 7:43 PM:
---
Ah, I assume the statistics plugin uses RamUsageQueryVisitor, which triggers
the building of the automata
was (Author: cjcowie):
Ah, the statistics plugin uses RamUsageQueryVisitor, which triggers the
building of the automata
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> image-2020-04-24-20-09-31-179.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
> ~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091843#comment-17091843
]
Colvin Cowie commented on SOLR-14428:
-
Ah, the statistics plugin uses RamUsageQueryVisitor, which triggers the
building of the automata
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> image-2020-04-24-20-09-31-179.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
> ~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091838#comment-17091838
]
Colvin Cowie commented on SOLR-14428:
-
Thanks, I patched it in. The heap usage looks a lot closer to how it was before
on my stress test.
!image-2020-04-24-20-09-31-179.png!
I'm surprised to see the cache statistics are still reporting high ramBytesUsed
though, e.g. a search for "field_s:e41848af85d24ac197c71db6888e17bc~2" still
results in a ramBytesUsed of 648863
{code:java}
this.ramBytesUsed = BASE_RAM_BYTES + term.ramBytesUsed();
{code}
in the new constructor looks like it should do the right thing
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> image-2020-04-24-20-09-31-179.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
> ~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Attachment: image-2020-04-24-20-09-31-179.png
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> image-2020-04-24-20-09-31-179.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
> ~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17090609#comment-17090609
]
Colvin Cowie commented on SOLR-14428:
-
Thanks, we'll just stick on 8.3.1 for the time being.
Though I will look at moving to CaffeineCache in general since I see the other
caches are being removed anyway.
Cheers
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
> ~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Description:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-2.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
Query Result Cache on 8.5.1:
!screenshot-3.png!
~316mb in the cache
QRC on 8.3.1
!screenshot-4.png!
<1mb
With an empty cache, running this query
_field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
allocation
{noformat}
8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
{noformat}
~1 gives 98253 and ~0 gives 6339 on 8.5.1. 8.3.1 is constant at 1520
was:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-2.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
Query Result Cache on 8.5.1:
!screenshot-3.png!
~316mb in the cache
QRC on 8.3.1
!screenshot-4.png!
<1mb
With an empty cache, running this query
_field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
allocation
{noformat}
8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
{noformat}
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
[jira] [Commented] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17090482#comment-17090482
]
Colvin Cowie commented on SOLR-14428:
-
Hi [~romseygeek], what are your thoughts on this? Thanks
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Description:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-2.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
Query Result Cache on 8.5.1:
!screenshot-3.png!
~316mb in the cache
QRC on 8.3.1
!screenshot-4.png!
<1mb
With an empty cache, running this query
_field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
allocation
{noformat}
8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
{noformat}
was:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-2.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
Query Result Cache on 8.5.1:
!screenshot-3.png!
~316mb in the cache
QRC on 8.3.1
!screenshot-4.png!
<1mb
With an empty cache, running this query
_field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
allocation
{noformat}
8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed:1520
8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
{noformat}
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
>
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Description:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-2.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
Query Result Cache on 8.5.1:
!screenshot-3.png!
~316mb in the cache
QRC on 8.3.1
!screenshot-4.png!
<1mb
With an empty cache, running this query
_field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
allocation
{noformat}
8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed:1520
8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
{noformat}
was:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-2.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
Query Result Cache on 8.5.1:
!screenshot-3.png!
~316mb in the cache
QRC on 8.3.1
!screenshot-4.png!
<1mb
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
> _field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
> allocation
> {noformat}
> 8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed:1520
> 8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
> {noformat}
--
This message was sent by Atlassian Jira
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Description:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-2.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
Query Result Cache on 8.5.1:
!screenshot-3.png!
~316mb in the cache
QRC on 8.3.1
!screenshot-4.png!
<1mb
With an empty cache, running this query
_field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
allocation
{noformat}
8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
{noformat}
was:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-2.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
Query Result Cache on 8.5.1:
!screenshot-3.png!
~316mb in the cache
QRC on 8.3.1
!screenshot-4.png!
<1mb
With an empty cache, running this query
_field_s:e41848af85d24ac197c71db6888e17bc~2_ results in the following memory
allocation
{noformat}
8.3.1: CACHE.searcher.queryResultCache.ramBytesUsed: 1520
8.5.1: CACHE.searcher.queryResultCache.ramBytesUsed:648855
{noformat}
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
> With an empty cache, running this query
>
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Description:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-2.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
Query Result Cache on 8.5.1:
!screenshot-3.png!
~316mb in the cache
QRC on 8.3.1
!screenshot-4.png!
<1mb
was:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-2.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
Query Result Cache on 8.5.1:
!screenshot-3.png!
~316mb in the cache
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
> QRC on 8.3.1
> !screenshot-4.png!
> <1mb
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Attachment: screenshot-4.png
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Attachment: screenshot-3.png
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-2.png, screenshot-3.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Description:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-2.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
Query Result Cache on 8.5.1:
!screenshot-3.png!
~316mb in the cache
was:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-2.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-2.png, screenshot-3.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
> Query Result Cache on 8.5.1:
> !screenshot-3.png!
> ~316mb in the cache
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Attachment: (was: screenshot-1.png)
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-2.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Description:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-1.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
was:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-1.png, screenshot-2.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-1.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Attachment: screenshot-1.png
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-1.png, screenshot-2.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Description:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-2.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
was:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
And with 4 shards on 8.4.1 and 8.5.0:
!screenshot-1.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-1.png, screenshot-2.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-2.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Attachment: screenshot-2.png
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png,
> screenshot-1.png, screenshot-2.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> And with 4 shards on 8.4.1 and 8.5.0:
> !screenshot-1.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Description:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
was:
{color:red}colored text{color}I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png
>
>
> I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
[
https://issues.apache.org/jira/browse/SOLR-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14428:
Description:
{color:red}colored text{color}I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
was:
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
> FuzzyQuery has severe memory usage in 8.5
> -
>
> Key: SOLR-14428
> URL: https://issues.apache.org/jira/browse/SOLR-14428
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Major
> Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png
>
>
> {color:red}colored text{color}I sent this to the mailing list
> I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors
> while running our normal tests. After profiling it was clear that the
> majority of the heap was allocated through FuzzyQuery.
> LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
> FuzzyQuery's constructor.
> I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
> from random UUID strings for 5 minutes
> {code}
> FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
> {code}
> When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
> the memory usage has increased drastically on 8.5.0 and 8.5.1.
> Comparison of heap usage while running the attached test against Solr 8.3.1
> and 8.5.1 with a single (empty) shard and 4GB heap:
> !image-2020-04-23-09-18-06-070.png!
> I'm guessing that the memory might be being leaked if the FuzzyQuery objects
> are referenced from the cache, while the FuzzyTermsEnum would not have been.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14428) FuzzyQuery has severe memory usage in 8.5
Colvin Cowie created SOLR-14428:
---
Summary: FuzzyQuery has severe memory usage in 8.5
Key: SOLR-14428
URL: https://issues.apache.org/jira/browse/SOLR-14428
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.5.1, 8.5
Reporter: Colvin Cowie
Attachments: FuzzyHammer.java, image-2020-04-23-09-18-06-070.png
I sent this to the mailing list
I'm moving from 8.3.1 to 8.5.1, and started getting Out Of Memory Errors while
running our normal tests. After profiling it was clear that the majority of the
heap was allocated through FuzzyQuery.
LUCENE-9068 moved construction of the automata from the FuzzyTermsEnum to the
FuzzyQuery's constructor.
I created a little test ( [^FuzzyHammer.java] ) that fires off fuzzy queries
from random UUID strings for 5 minutes
{code}
FIELD_NAME + ":" + UUID.randomUUID().toString().replace("-", "") + "~2"
{code}
When running against a vanilla Solr 8.31 and 8.4.1 there is no problem, while
the memory usage has increased drastically on 8.5.0 and 8.5.1.
Comparison of heap usage while running the attached test against Solr 8.3.1 and
8.5.1 with a single (empty) shard and 4GB heap:
!image-2020-04-23-09-18-06-070.png!
I'm guessing that the memory might be being leaked if the FuzzyQuery objects
are referenced from the cache, while the FuzzyTermsEnum would not have been.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088749#comment-17088749 ] Colvin Cowie edited comment on SOLR-14422 at 4/21/20, 2:37 PM: --- np. It looks like it would work on the `` but I don't _think_ you can go more granular than that (without adding another div) was (Author: cjcowie): np. It looks like it would work on the `` but I don't _think_ you can go more granular than that > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.5, 8.5.1 >Reporter: Colvin Cowie >Priority: Minor > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie updated SOLR-14422: Status: Patch Available (was: Open) > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.5, 8.5.1 >Reporter: Colvin Cowie >Priority: Minor > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088719#comment-17088719 ] Colvin Cowie commented on SOLR-14422: - Hi [~rcmuir] [~krisden] can you check this? Thanks. > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.5, 8.5.1 >Reporter: Colvin Cowie >Priority: Minor > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colvin Cowie updated SOLR-14422: Attachment: SOLR-14422.patch > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 8.5, 8.5.1 >Reporter: Colvin Cowie >Priority: Minor > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
Colvin Cowie created SOLR-14422: --- Summary: Solr 8.5 Admin UI shows Angular placeholders on first load / refresh Key: SOLR-14422 URL: https://issues.apache.org/jira/browse/SOLR-14422 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: Admin UI Affects Versions: 8.5.1, 8.5 Reporter: Colvin Cowie Attachments: image-2020-04-21-14-51-18-923.png When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ shows a placeholder for the "SolrCore Initialization Failures" error message, with a lot of redness. It looks like there is a real problem. Obviously the message then disappears, and it can be ignored. However, if I was a first time user, it would not give me confidence that everything is okay. In a way, an error message that appears briefly then disappears before I can finish reading it is worse than one which just stays there. Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! I suspect that SOLR-14132 will have caused this >From a (very) brief googling it seems like using the ng-cloak attribute is the >right way to fix this, and it certainly seems to work for me. >https://docs.angularjs.org/api/ng/directive/ngCloak I will attach a patch with it, but if someone who actually knows Angular etc has a better approach then please go for it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088544#comment-17088544
]
Colvin Cowie commented on SOLR-14421:
-
It seems ok with the quotes stripped from all of them. Does make me slightly
uneasy, but that's the CMD way.
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a patch
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Status: Patch Available (was: Open)
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a patch
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Status: Open (was: Patch Available)
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a patch
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Attachment: SOLR-14421.patch
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a patch
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Attachment: (was: SOLR-14421.patch)
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a patch
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088500#comment-17088500
]
Colvin Cowie commented on SOLR-14421:
-
There were others as well, so I'm just going to check that the updated examples
actually work.
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a patch
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088492#comment-17088492
]
Colvin Cowie commented on SOLR-14421:
-
Missed another one on the shardsWhitelist
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.6
>
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a patch
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Description:
These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
surrounded with quotes
[https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
{noformat}
REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
REM Specifies the path to a common library directory that will be shared across
all cores.
REM Any JAR files in this directory will be added to the search path for Solr
plugins.
REM If the specified path is not absolute, it will be relative to `%SOLR_HOME%`.
REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
{noformat}
Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
external command, operable program or batch file_."
After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
unexpected at this time."_
I'll attach a patch
was:
These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
surrounded with quotes
https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199
{noformat}
REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
REM Specifies the path to a common library directory that will be shared across
all cores.
REM Any JAR files in this directory will be added to the search path for Solr
plugins.
REM If the specified path is not absolute, it will be relative to `%SOLR_HOME%`.
REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
{noformat}
I'll attach a patch
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Trivial
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199]
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> Without set you will get "_'SOLR_OPTS' is not recognized as an internal or
> external command, operable program or batch file_."
> After adding _set,_ with the quotes you get _"-Dsolr.environment=prod was
> unexpected at this time."_
> I'll attach a patch
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Status: Patch Available (was: Open)
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Trivial
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> I'll attach a patch
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Attachment: SOLR-14421.patch
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Trivial
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> I'll attach a patch
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Attachment: SOLR-14421.patch
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Trivial
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> I'll attach a patch
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
[
https://issues.apache.org/jira/browse/SOLR-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14421:
Attachment: (was: SOLR-14421.patch)
> New examples in solr.in.cmd in Solr 8.5 don't work as provided
> --
>
> Key: SOLR-14421
> URL: https://issues.apache.org/jira/browse/SOLR-14421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.5, 8.5.1
>Reporter: Colvin Cowie
>Priority: Trivial
> Attachments: SOLR-14421.patch
>
>
>
> These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
> surrounded with quotes
> https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199
> {noformat}
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
> REM Specifies the path to a common library directory that will be shared
> across all cores.
> REM Any JAR files in this directory will be added to the search path for Solr
> plugins.
> REM If the specified path is not absolute, it will be relative to
> `%SOLR_HOME%`.
> REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
> {noformat}
> I'll attach a patch
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14421) New examples in solr.in.cmd in Solr 8.5 don't work as provided
Colvin Cowie created SOLR-14421:
---
Summary: New examples in solr.in.cmd in Solr 8.5 don't work as
provided
Key: SOLR-14421
URL: https://issues.apache.org/jira/browse/SOLR-14421
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.5.1, 8.5
Reporter: Colvin Cowie
These SOLR_OPTS examples need to be prefixed with _set_ and don't work when
surrounded with quotes
https://github.com/apache/lucene-solr/blob/master/solr/bin/solr.in.cmd#L194-L199
{noformat}
REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.environment=prod"
REM Specifies the path to a common library directory that will be shared across
all cores.
REM Any JAR files in this directory will be added to the search path for Solr
plugins.
REM If the specified path is not absolute, it will be relative to `%SOLR_HOME%`.
REM SOLR_OPTS="%SOLR_OPTS% -Dsolr.sharedLib=/path/to/lib"
{noformat}
I'll attach a patch
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14416) Nodes view doesn't work correctly when Solr is hosted on Windows
[
https://issues.apache.org/jira/browse/SOLR-14416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14416:
Affects Version/s: 8.4
8.4.1
> Nodes view doesn't work correctly when Solr is hosted on Windows
>
>
> Key: SOLR-14416
> URL: https://issues.apache.org/jira/browse/SOLR-14416
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 7.7.2, 8.1, 8.2, 8.1.1, 8.3, 8.4, 8.3.1, 8.4.1
>Reporter: Colvin Cowie
>Priority: Minor
> Fix For: 8.5
>
> Attachments: screenshot-1.png
>
>
> I sent a message about this on the mailing list a long time ago and got no
> replies.
> Originally I saw it on 8.1.1, it's a problem in 8.3.1 and I don't expect it's
> fixed in 8.5, but I will check.
> On Solr 8.1.1 / 7.7.2 with Oracle 1.8.0_191 25.191-b12 with Solr running on
> Windows 10
> In the Nodes view of the Admin
> UI,http://localhost:8983/solr/#/~cloud?view=nodes there is a refresh button.
> However when you click it, the only thing that gets visibly refreshed is the
> 'bar chart' (not sure what to call it - it's shown when you choose show
> details) of the index shard size on disk. The other stats do not update.
> Also, when there is more than one node, only some of the node information is
> shown
> !screenshot-1.png!
> Firefox dev console shows:
> {noformat}
> _Error: s.system.uptime is undefined
> nodesSubController/$scope.reload/<@http://localhost:8983/solr/js/angular/controllers/cloud.js:384:11
> v/http://localhost:8983/solr/libs/angular-resource.min.js:33:133
> processQueue@http://localhost:8983/solr/libs/angular.js:13193:27
> scheduleProcessQueue/<@http://localhost:8983/solr/libs/angular.js:13209:27
> $eval@http://localhost:8983/solr/libs/angular.js:14406:16
> $digest@http://localhost:8983/solr/libs/angular.js:14222:15
> $apply@http://localhost:8983/solr/libs/angular.js:14511:13
> done@http://localhost:8983/solr/libs/angular.js:9669:36
> completeRequest@http://localhost:8983/solr/libs/angular.js:9859:7
> requestLoaded@http://localhost:8983/solr/libs/angular.js:9800:9_
> {noformat}
> The system response has upTimeMs in it for the JVM/JMX properties, but no
> system/uptime
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":63},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":49},
> "mode":"solrcloud",
> "zkHost":"localhost:9983",
> "solr_home":"...",
> "lucene":{
> "solr-spec-version":"8.1.1",
> "solr-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:20:01",
> "lucene-spec-version":"8.1.1",
> "lucene-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:15:24"},
> "jvm":{
> "version":"1.8.0_211 25.211-b12",
> "name":"Oracle Corporation Java HotSpot(TM) 64-Bit Server VM",
> "spec":{
> "vendor":"Oracle Corporation",
> "name":"Java Platform API Specification",
> "version":"1.8"},
> "jre":{
> "vendor":"Oracle Corporation",
> "version":"1.8.0_211"},
> "vm":{
> "vendor":"Oracle Corporation",
> "name":"Java HotSpot(TM) 64-Bit Server VM",
> "version":"25.211-b12"},
> "processors":8,
> "memory":{
> "free":"1.4 GB",
> "total":"2 GB",
> "max":"2 GB",
> "used":"566.7 MB (%27.7)",
> "raw":{
> "free":1553268432,
> "total":2147483648,
> "max":2147483648,
> "used":594215216,
> "used%":27.670302242040634}},
> "jmx":{
> "bootclasspath":"...",
> "classpath":"start.jar",
> "commandLineArgs":[...],
> "startTime":"2019-06-20T11:41:58.955Z",
> "upTimeMS":516602}},
> "system":{
> "name":"Windows 10",
> "arch":"amd64",
> "availableProcessors":8,
> "systemLoadAverage":-1.0,
> "version":"10.0",
> "committedVirtualMemorySize":2709114880,
> "freePhysicalMemorySize":16710127616,
> "freeSwapSpaceSize":16422531072,
> "processCpuLoad":0.13941671744473663,
> "processCpuTime":194609375000,
> "systemCpuLoad":0.25816002967796037,
> "totalPhysicalMemorySize":34261250048,
> "totalSwapSpaceSize":39361523712},
> "node":"localhost:8983_solr"}}
> {noformat}
> The SystemInfoHandler does this:
> {code}
> // Try some command line things:
> try {
> if (!Constants.WINDOWS) {
> info.add( "uname", execute( "uname -a" ) );
> info.add( "uptime", execute( "uptime" ) );
> }
> } catch( Exception ex ) {
> log.warn("Unable to execute command line tools
[jira] [Comment Edited] (SOLR-14416) Nodes view doesn't work correctly when Solr is hosted on Windows
[
https://issues.apache.org/jira/browse/SOLR-14416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17087916#comment-17087916
]
Colvin Cowie edited comment on SOLR-14416 at 4/20/20, 4:44 PM:
---
Ah, it's already been fixed by SOLR-13983 in 8.5 :)
I didn't find it because I searched for the js error in JIRA, rather than the
SystemInfoHandler class
was (Author: cjcowie):
Ah, it's already been fixed in 8.5 :)
I didn't find because I searched for the js error in JIRA, rather than the
SystemInfoHandler class
> Nodes view doesn't work correctly when Solr is hosted on Windows
>
>
> Key: SOLR-14416
> URL: https://issues.apache.org/jira/browse/SOLR-14416
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 7.7.2, 8.1, 8.2, 8.1.1, 8.3, 8.4, 8.3.1, 8.4.1
>Reporter: Colvin Cowie
>Priority: Minor
> Fix For: 8.5
>
> Attachments: screenshot-1.png
>
>
> I sent a message about this on the mailing list a long time ago and got no
> replies.
> Originally I saw it on 8.1.1, it's a problem in 8.3.1 and I don't expect it's
> fixed in 8.5, but I will check.
> On Solr 8.1.1 / 7.7.2 with Oracle 1.8.0_191 25.191-b12 with Solr running on
> Windows 10
> In the Nodes view of the Admin
> UI,http://localhost:8983/solr/#/~cloud?view=nodes there is a refresh button.
> However when you click it, the only thing that gets visibly refreshed is the
> 'bar chart' (not sure what to call it - it's shown when you choose show
> details) of the index shard size on disk. The other stats do not update.
> Also, when there is more than one node, only some of the node information is
> shown
> !screenshot-1.png!
> Firefox dev console shows:
> {noformat}
> _Error: s.system.uptime is undefined
> nodesSubController/$scope.reload/<@http://localhost:8983/solr/js/angular/controllers/cloud.js:384:11
> v/http://localhost:8983/solr/libs/angular-resource.min.js:33:133
> processQueue@http://localhost:8983/solr/libs/angular.js:13193:27
> scheduleProcessQueue/<@http://localhost:8983/solr/libs/angular.js:13209:27
> $eval@http://localhost:8983/solr/libs/angular.js:14406:16
> $digest@http://localhost:8983/solr/libs/angular.js:14222:15
> $apply@http://localhost:8983/solr/libs/angular.js:14511:13
> done@http://localhost:8983/solr/libs/angular.js:9669:36
> completeRequest@http://localhost:8983/solr/libs/angular.js:9859:7
> requestLoaded@http://localhost:8983/solr/libs/angular.js:9800:9_
> {noformat}
> The system response has upTimeMs in it for the JVM/JMX properties, but no
> system/uptime
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":63},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":49},
> "mode":"solrcloud",
> "zkHost":"localhost:9983",
> "solr_home":"...",
> "lucene":{
> "solr-spec-version":"8.1.1",
> "solr-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:20:01",
> "lucene-spec-version":"8.1.1",
> "lucene-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:15:24"},
> "jvm":{
> "version":"1.8.0_211 25.211-b12",
> "name":"Oracle Corporation Java HotSpot(TM) 64-Bit Server VM",
> "spec":{
> "vendor":"Oracle Corporation",
> "name":"Java Platform API Specification",
> "version":"1.8"},
> "jre":{
> "vendor":"Oracle Corporation",
> "version":"1.8.0_211"},
> "vm":{
> "vendor":"Oracle Corporation",
> "name":"Java HotSpot(TM) 64-Bit Server VM",
> "version":"25.211-b12"},
> "processors":8,
> "memory":{
> "free":"1.4 GB",
> "total":"2 GB",
> "max":"2 GB",
> "used":"566.7 MB (%27.7)",
> "raw":{
> "free":1553268432,
> "total":2147483648,
> "max":2147483648,
> "used":594215216,
> "used%":27.670302242040634}},
> "jmx":{
> "bootclasspath":"...",
> "classpath":"start.jar",
> "commandLineArgs":[...],
> "startTime":"2019-06-20T11:41:58.955Z",
> "upTimeMS":516602}},
> "system":{
> "name":"Windows 10",
> "arch":"amd64",
> "availableProcessors":8,
> "systemLoadAverage":-1.0,
> "version":"10.0",
> "committedVirtualMemorySize":2709114880,
> "freePhysicalMemorySize":16710127616,
> "freeSwapSpaceSize":16422531072,
> "processCpuLoad":0.13941671744473663,
> "processCpuTime":194609375000,
> "systemCpuLoad":0.25816002967796037,
> "totalPhysicalMemorySize":34261250048,
> "totalSwapSpaceSize":39361523712},
>
[jira] [Resolved] (SOLR-14416) Nodes view doesn't work correctly when Solr is hosted on Windows
[
https://issues.apache.org/jira/browse/SOLR-14416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie resolved SOLR-14416.
-
Fix Version/s: 8.5
Resolution: Duplicate
Ah, it's already been fixed in 8.5 :)
I didn't find because I searched for the js error in JIRA, rather than the
SystemInfoHandler class
> Nodes view doesn't work correctly when Solr is hosted on Windows
>
>
> Key: SOLR-14416
> URL: https://issues.apache.org/jira/browse/SOLR-14416
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 7.7.2, 8.1, 8.2, 8.1.1, 8.3, 8.3.1
>Reporter: Colvin Cowie
>Priority: Minor
> Fix For: 8.5
>
> Attachments: screenshot-1.png
>
>
> I sent a message about this on the mailing list a long time ago and got no
> replies.
> Originally I saw it on 8.1.1, it's a problem in 8.3.1 and I don't expect it's
> fixed in 8.5, but I will check.
> On Solr 8.1.1 / 7.7.2 with Oracle 1.8.0_191 25.191-b12 with Solr running on
> Windows 10
> In the Nodes view of the Admin
> UI,http://localhost:8983/solr/#/~cloud?view=nodes there is a refresh button.
> However when you click it, the only thing that gets visibly refreshed is the
> 'bar chart' (not sure what to call it - it's shown when you choose show
> details) of the index shard size on disk. The other stats do not update.
> Also, when there is more than one node, only some of the node information is
> shown
> !screenshot-1.png!
> Firefox dev console shows:
> {noformat}
> _Error: s.system.uptime is undefined
> nodesSubController/$scope.reload/<@http://localhost:8983/solr/js/angular/controllers/cloud.js:384:11
> v/http://localhost:8983/solr/libs/angular-resource.min.js:33:133
> processQueue@http://localhost:8983/solr/libs/angular.js:13193:27
> scheduleProcessQueue/<@http://localhost:8983/solr/libs/angular.js:13209:27
> $eval@http://localhost:8983/solr/libs/angular.js:14406:16
> $digest@http://localhost:8983/solr/libs/angular.js:14222:15
> $apply@http://localhost:8983/solr/libs/angular.js:14511:13
> done@http://localhost:8983/solr/libs/angular.js:9669:36
> completeRequest@http://localhost:8983/solr/libs/angular.js:9859:7
> requestLoaded@http://localhost:8983/solr/libs/angular.js:9800:9_
> {noformat}
> The system response has upTimeMs in it for the JVM/JMX properties, but no
> system/uptime
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":63},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":49},
> "mode":"solrcloud",
> "zkHost":"localhost:9983",
> "solr_home":"...",
> "lucene":{
> "solr-spec-version":"8.1.1",
> "solr-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:20:01",
> "lucene-spec-version":"8.1.1",
> "lucene-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:15:24"},
> "jvm":{
> "version":"1.8.0_211 25.211-b12",
> "name":"Oracle Corporation Java HotSpot(TM) 64-Bit Server VM",
> "spec":{
> "vendor":"Oracle Corporation",
> "name":"Java Platform API Specification",
> "version":"1.8"},
> "jre":{
> "vendor":"Oracle Corporation",
> "version":"1.8.0_211"},
> "vm":{
> "vendor":"Oracle Corporation",
> "name":"Java HotSpot(TM) 64-Bit Server VM",
> "version":"25.211-b12"},
> "processors":8,
> "memory":{
> "free":"1.4 GB",
> "total":"2 GB",
> "max":"2 GB",
> "used":"566.7 MB (%27.7)",
> "raw":{
> "free":1553268432,
> "total":2147483648,
> "max":2147483648,
> "used":594215216,
> "used%":27.670302242040634}},
> "jmx":{
> "bootclasspath":"...",
> "classpath":"start.jar",
> "commandLineArgs":[...],
> "startTime":"2019-06-20T11:41:58.955Z",
> "upTimeMS":516602}},
> "system":{
> "name":"Windows 10",
> "arch":"amd64",
> "availableProcessors":8,
> "systemLoadAverage":-1.0,
> "version":"10.0",
> "committedVirtualMemorySize":2709114880,
> "freePhysicalMemorySize":16710127616,
> "freeSwapSpaceSize":16422531072,
> "processCpuLoad":0.13941671744473663,
> "processCpuTime":194609375000,
> "systemCpuLoad":0.25816002967796037,
> "totalPhysicalMemorySize":34261250048,
> "totalSwapSpaceSize":39361523712},
> "node":"localhost:8983_solr"}}
> {noformat}
> The SystemInfoHandler does this:
> {code}
> // Try some command line things:
> try {
> if (!Constants.WINDOWS) {
> info.add( "uname", execute( "uname -a" ) );
> info.add(
[jira] [Commented] (SOLR-14416) Nodes view doesn't work correctly when Solr is hosted on Windows
[
https://issues.apache.org/jira/browse/SOLR-14416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17087624#comment-17087624
]
Colvin Cowie commented on SOLR-14416:
-
I can do a patch for the SystemInfoHandler when I get a free minute.
> Nodes view doesn't work correctly when Solr is hosted on Windows
>
>
> Key: SOLR-14416
> URL: https://issues.apache.org/jira/browse/SOLR-14416
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 7.7.2, 8.1, 8.2, 8.1.1, 8.3, 8.3.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> I sent a message about this on the mailing list a long time ago and got no
> replies.
> Originally I saw it on 8.1.1, it's a problem in 8.3.1 and I don't expect it's
> fixed in 8.5, but I will check.
> On Solr 8.1.1 / 7.7.2 with Oracle 1.8.0_191 25.191-b12 with Solr running on
> Windows 10
> In the Nodes view of the Admin
> UI,http://localhost:8983/solr/#/~cloud?view=nodes there is a refresh button.
> However when you click it, the only thing that gets visibly refreshed is the
> 'bar chart' (not sure what to call it - it's shown when you choose show
> details) of the index shard size on disk. The other stats do not update.
> Also, when there is more than one node, only some of the node information is
> shown
> !screenshot-1.png!
> Firefox dev console shows:
> {noformat}
> _Error: s.system.uptime is undefined
> nodesSubController/$scope.reload/<@http://localhost:8983/solr/js/angular/controllers/cloud.js:384:11
> v/http://localhost:8983/solr/libs/angular-resource.min.js:33:133
> processQueue@http://localhost:8983/solr/libs/angular.js:13193:27
> scheduleProcessQueue/<@http://localhost:8983/solr/libs/angular.js:13209:27
> $eval@http://localhost:8983/solr/libs/angular.js:14406:16
> $digest@http://localhost:8983/solr/libs/angular.js:14222:15
> $apply@http://localhost:8983/solr/libs/angular.js:14511:13
> done@http://localhost:8983/solr/libs/angular.js:9669:36
> completeRequest@http://localhost:8983/solr/libs/angular.js:9859:7
> requestLoaded@http://localhost:8983/solr/libs/angular.js:9800:9_
> {noformat}
> The system response has upTimeMs in it for the JVM/JMX properties, but no
> system/uptime
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":63},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":49},
> "mode":"solrcloud",
> "zkHost":"localhost:9983",
> "solr_home":"...",
> "lucene":{
> "solr-spec-version":"8.1.1",
> "solr-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:20:01",
> "lucene-spec-version":"8.1.1",
> "lucene-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:15:24"},
> "jvm":{
> "version":"1.8.0_211 25.211-b12",
> "name":"Oracle Corporation Java HotSpot(TM) 64-Bit Server VM",
> "spec":{
> "vendor":"Oracle Corporation",
> "name":"Java Platform API Specification",
> "version":"1.8"},
> "jre":{
> "vendor":"Oracle Corporation",
> "version":"1.8.0_211"},
> "vm":{
> "vendor":"Oracle Corporation",
> "name":"Java HotSpot(TM) 64-Bit Server VM",
> "version":"25.211-b12"},
> "processors":8,
> "memory":{
> "free":"1.4 GB",
> "total":"2 GB",
> "max":"2 GB",
> "used":"566.7 MB (%27.7)",
> "raw":{
> "free":1553268432,
> "total":2147483648,
> "max":2147483648,
> "used":594215216,
> "used%":27.670302242040634}},
> "jmx":{
> "bootclasspath":"...",
> "classpath":"start.jar",
> "commandLineArgs":[...],
> "startTime":"2019-06-20T11:41:58.955Z",
> "upTimeMS":516602}},
> "system":{
> "name":"Windows 10",
> "arch":"amd64",
> "availableProcessors":8,
> "systemLoadAverage":-1.0,
> "version":"10.0",
> "committedVirtualMemorySize":2709114880,
> "freePhysicalMemorySize":16710127616,
> "freeSwapSpaceSize":16422531072,
> "processCpuLoad":0.13941671744473663,
> "processCpuTime":194609375000,
> "systemCpuLoad":0.25816002967796037,
> "totalPhysicalMemorySize":34261250048,
> "totalSwapSpaceSize":39361523712},
> "node":"localhost:8983_solr"}}
> {noformat}
> The SystemInfoHandler does this:
> {code}
> // Try some command line things:
> try {
> if (!Constants.WINDOWS) {
> info.add( "uname", execute( "uname -a" ) );
> info.add( "uptime", execute( "uptime" ) );
> }
> } catch( Exception ex ) {
> log.warn("Unable to execute
[jira] [Updated] (SOLR-14416) Nodes view doesn't work correctly when Solr is hosted on Windows
[
https://issues.apache.org/jira/browse/SOLR-14416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14416:
Attachment: screenshot-1.png
> Nodes view doesn't work correctly when Solr is hosted on Windows
>
>
> Key: SOLR-14416
> URL: https://issues.apache.org/jira/browse/SOLR-14416
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 7.7.2, 8.1, 8.2, 8.1.1, 8.3, 8.3.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> I sent a message about this on the mailing list a long time ago and got no
> replies.
> Originally I saw it on 8.1.1, it's a problem in 8.3.1 and I don't expect it's
> fixed in 8.5, but I will check.
> On Solr 8.1.1 / 7.7.2 with Oracle 1.8.0_191 25.191-b12 with Solr running on
> Windows 10
> In the Nodes view of the Admin
> UI,http://localhost:8983/solr/#/~cloud?view=nodes there is a refresh button.
> However when you click it, the only thing that gets visibly refreshed is the
> 'bar chart' (not sure what to call it - it's shown when you choose show
> details) of the index shard size on disk. The other stats do not update.
> Also, when there is more than one node, only some of the node information is
> shown
> !image-2020-04-20-10-37-22-308.png!
> Firefox dev console shows:
> {noformat}
> _Error: s.system.uptime is undefined
> nodesSubController/$scope.reload/<@http://localhost:8983/solr/js/angular/controllers/cloud.js:384:11
> v/http://localhost:8983/solr/libs/angular-resource.min.js:33:133
> processQueue@http://localhost:8983/solr/libs/angular.js:13193:27
> scheduleProcessQueue/<@http://localhost:8983/solr/libs/angular.js:13209:27
> $eval@http://localhost:8983/solr/libs/angular.js:14406:16
> $digest@http://localhost:8983/solr/libs/angular.js:14222:15
> $apply@http://localhost:8983/solr/libs/angular.js:14511:13
> done@http://localhost:8983/solr/libs/angular.js:9669:36
> completeRequest@http://localhost:8983/solr/libs/angular.js:9859:7
> requestLoaded@http://localhost:8983/solr/libs/angular.js:9800:9_
> {noformat}
> The system response has upTimeMs in it for the JVM/JMX properties, but no
> system/uptime
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":63},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":49},
> "mode":"solrcloud",
> "zkHost":"localhost:9983",
> "solr_home":"...",
> "lucene":{
> "solr-spec-version":"8.1.1",
> "solr-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:20:01",
> "lucene-spec-version":"8.1.1",
> "lucene-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:15:24"},
> "jvm":{
> "version":"1.8.0_211 25.211-b12",
> "name":"Oracle Corporation Java HotSpot(TM) 64-Bit Server VM",
> "spec":{
> "vendor":"Oracle Corporation",
> "name":"Java Platform API Specification",
> "version":"1.8"},
> "jre":{
> "vendor":"Oracle Corporation",
> "version":"1.8.0_211"},
> "vm":{
> "vendor":"Oracle Corporation",
> "name":"Java HotSpot(TM) 64-Bit Server VM",
> "version":"25.211-b12"},
> "processors":8,
> "memory":{
> "free":"1.4 GB",
> "total":"2 GB",
> "max":"2 GB",
> "used":"566.7 MB (%27.7)",
> "raw":{
> "free":1553268432,
> "total":2147483648,
> "max":2147483648,
> "used":594215216,
> "used%":27.670302242040634}},
> "jmx":{
> "bootclasspath":"...",
> "classpath":"start.jar",
> "commandLineArgs":[...],
> "startTime":"2019-06-20T11:41:58.955Z",
> "upTimeMS":516602}},
> "system":{
> "name":"Windows 10",
> "arch":"amd64",
> "availableProcessors":8,
> "systemLoadAverage":-1.0,
> "version":"10.0",
> "committedVirtualMemorySize":2709114880,
> "freePhysicalMemorySize":16710127616,
> "freeSwapSpaceSize":16422531072,
> "processCpuLoad":0.13941671744473663,
> "processCpuTime":194609375000,
> "systemCpuLoad":0.25816002967796037,
> "totalPhysicalMemorySize":34261250048,
> "totalSwapSpaceSize":39361523712},
> "node":"localhost:8983_solr"}}
> {noformat}
> The SystemInfoHandler does this:
> {code}
> // Try some command line things:
> try {
> if (!Constants.WINDOWS) {
> info.add( "uname", execute( "uname -a" ) );
> info.add( "uptime", execute( "uptime" ) );
> }
> } catch( Exception ex ) {
> log.warn("Unable to execute command line tools to get operating system
> properties.", ex);
[jira] [Updated] (SOLR-14416) Nodes view doesn't work correctly when Solr is hosted on Windows
[
https://issues.apache.org/jira/browse/SOLR-14416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14416:
Description:
I sent a message about this on the mailing list a long time ago and got no
replies.
Originally I saw it on 8.1.1, it's a problem in 8.3.1 and I don't expect it's
fixed in 8.5, but I will check.
On Solr 8.1.1 / 7.7.2 with Oracle 1.8.0_191 25.191-b12 with Solr running on
Windows 10
In the Nodes view of the Admin
UI,http://localhost:8983/solr/#/~cloud?view=nodes there is a refresh button.
However when you click it, the only thing that gets visibly refreshed is the
'bar chart' (not sure what to call it - it's shown when you choose show
details) of the index shard size on disk. The other stats do not update.
Also, when there is more than one node, only some of the node information is
shown
!screenshot-1.png!
Firefox dev console shows:
{noformat}
_Error: s.system.uptime is undefined
nodesSubController/$scope.reload/<@http://localhost:8983/solr/js/angular/controllers/cloud.js:384:11
v/http://localhost:8983/solr/libs/angular-resource.min.js:33:133
processQueue@http://localhost:8983/solr/libs/angular.js:13193:27
scheduleProcessQueue/<@http://localhost:8983/solr/libs/angular.js:13209:27
$eval@http://localhost:8983/solr/libs/angular.js:14406:16
$digest@http://localhost:8983/solr/libs/angular.js:14222:15
$apply@http://localhost:8983/solr/libs/angular.js:14511:13
done@http://localhost:8983/solr/libs/angular.js:9669:36
completeRequest@http://localhost:8983/solr/libs/angular.js:9859:7
requestLoaded@http://localhost:8983/solr/libs/angular.js:9800:9_
{noformat}
The system response has upTimeMs in it for the JVM/JMX properties, but no
system/uptime
{noformat}
{
"responseHeader":{
"status":0,
"QTime":63},
"localhost:8983_solr":{
"responseHeader":{
"status":0,
"QTime":49},
"mode":"solrcloud",
"zkHost":"localhost:9983",
"solr_home":"...",
"lucene":{
"solr-spec-version":"8.1.1",
"solr-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab
- 2019-05-22 15:20:01",
"lucene-spec-version":"8.1.1",
"lucene-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
ab - 2019-05-22 15:15:24"},
"jvm":{
"version":"1.8.0_211 25.211-b12",
"name":"Oracle Corporation Java HotSpot(TM) 64-Bit Server VM",
"spec":{
"vendor":"Oracle Corporation",
"name":"Java Platform API Specification",
"version":"1.8"},
"jre":{
"vendor":"Oracle Corporation",
"version":"1.8.0_211"},
"vm":{
"vendor":"Oracle Corporation",
"name":"Java HotSpot(TM) 64-Bit Server VM",
"version":"25.211-b12"},
"processors":8,
"memory":{
"free":"1.4 GB",
"total":"2 GB",
"max":"2 GB",
"used":"566.7 MB (%27.7)",
"raw":{
"free":1553268432,
"total":2147483648,
"max":2147483648,
"used":594215216,
"used%":27.670302242040634}},
"jmx":{
"bootclasspath":"...",
"classpath":"start.jar",
"commandLineArgs":[...],
"startTime":"2019-06-20T11:41:58.955Z",
"upTimeMS":516602}},
"system":{
"name":"Windows 10",
"arch":"amd64",
"availableProcessors":8,
"systemLoadAverage":-1.0,
"version":"10.0",
"committedVirtualMemorySize":2709114880,
"freePhysicalMemorySize":16710127616,
"freeSwapSpaceSize":16422531072,
"processCpuLoad":0.13941671744473663,
"processCpuTime":194609375000,
"systemCpuLoad":0.25816002967796037,
"totalPhysicalMemorySize":34261250048,
"totalSwapSpaceSize":39361523712},
"node":"localhost:8983_solr"}}
{noformat}
The SystemInfoHandler does this:
{code}
// Try some command line things:
try {
if (!Constants.WINDOWS) {
info.add( "uname", execute( "uname -a" ) );
info.add( "uptime", execute( "uptime" ) );
}
} catch( Exception ex ) {
log.warn("Unable to execute command line tools to get operating system
properties.", ex);
}
{code}
Which appears to be the problem since it won't return uname and uptime on
windows, but the UI expects them
If I run uptime from my Ubuntu shell in WSL the output is like "16:41:40 up 7
min, 0 users, load average: 0.52, 0.58, 0.59". If I make the System handler
return that then there are no further dev console errors...
However, even with that "fixed", refresh doesn't actually seem to refresh
anything other than the graph.
In contrast, refreshing the System (e.g. memory) section on the main dashboard
does correctly update.
The missing "uptime" from the response looks like the problem, but isn't
actually stopping refresh from doing anything when I return an uptime. So, is
the Nodes view supposed to be refreshing everything, or are my expectations
wrong?
was:
I sent a
[jira] [Updated] (SOLR-14416) Nodes view doesn't work correctly when Solr is hosted on Windows
[
https://issues.apache.org/jira/browse/SOLR-14416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14416:
Attachment: (was: image-2020-04-20-10-37-22-308.png)
> Nodes view doesn't work correctly when Solr is hosted on Windows
>
>
> Key: SOLR-14416
> URL: https://issues.apache.org/jira/browse/SOLR-14416
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 7.7.2, 8.1, 8.2, 8.1.1, 8.3, 8.3.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> I sent a message about this on the mailing list a long time ago and got no
> replies.
> Originally I saw it on 8.1.1, it's a problem in 8.3.1 and I don't expect it's
> fixed in 8.5, but I will check.
> On Solr 8.1.1 / 7.7.2 with Oracle 1.8.0_191 25.191-b12 with Solr running on
> Windows 10
> In the Nodes view of the Admin
> UI,http://localhost:8983/solr/#/~cloud?view=nodes there is a refresh button.
> However when you click it, the only thing that gets visibly refreshed is the
> 'bar chart' (not sure what to call it - it's shown when you choose show
> details) of the index shard size on disk. The other stats do not update.
> Also, when there is more than one node, only some of the node information is
> shown
> !image-2020-04-20-10-37-22-308.png!
> Firefox dev console shows:
> {noformat}
> _Error: s.system.uptime is undefined
> nodesSubController/$scope.reload/<@http://localhost:8983/solr/js/angular/controllers/cloud.js:384:11
> v/http://localhost:8983/solr/libs/angular-resource.min.js:33:133
> processQueue@http://localhost:8983/solr/libs/angular.js:13193:27
> scheduleProcessQueue/<@http://localhost:8983/solr/libs/angular.js:13209:27
> $eval@http://localhost:8983/solr/libs/angular.js:14406:16
> $digest@http://localhost:8983/solr/libs/angular.js:14222:15
> $apply@http://localhost:8983/solr/libs/angular.js:14511:13
> done@http://localhost:8983/solr/libs/angular.js:9669:36
> completeRequest@http://localhost:8983/solr/libs/angular.js:9859:7
> requestLoaded@http://localhost:8983/solr/libs/angular.js:9800:9_
> {noformat}
> The system response has upTimeMs in it for the JVM/JMX properties, but no
> system/uptime
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":63},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":49},
> "mode":"solrcloud",
> "zkHost":"localhost:9983",
> "solr_home":"...",
> "lucene":{
> "solr-spec-version":"8.1.1",
> "solr-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:20:01",
> "lucene-spec-version":"8.1.1",
> "lucene-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:15:24"},
> "jvm":{
> "version":"1.8.0_211 25.211-b12",
> "name":"Oracle Corporation Java HotSpot(TM) 64-Bit Server VM",
> "spec":{
> "vendor":"Oracle Corporation",
> "name":"Java Platform API Specification",
> "version":"1.8"},
> "jre":{
> "vendor":"Oracle Corporation",
> "version":"1.8.0_211"},
> "vm":{
> "vendor":"Oracle Corporation",
> "name":"Java HotSpot(TM) 64-Bit Server VM",
> "version":"25.211-b12"},
> "processors":8,
> "memory":{
> "free":"1.4 GB",
> "total":"2 GB",
> "max":"2 GB",
> "used":"566.7 MB (%27.7)",
> "raw":{
> "free":1553268432,
> "total":2147483648,
> "max":2147483648,
> "used":594215216,
> "used%":27.670302242040634}},
> "jmx":{
> "bootclasspath":"...",
> "classpath":"start.jar",
> "commandLineArgs":[...],
> "startTime":"2019-06-20T11:41:58.955Z",
> "upTimeMS":516602}},
> "system":{
> "name":"Windows 10",
> "arch":"amd64",
> "availableProcessors":8,
> "systemLoadAverage":-1.0,
> "version":"10.0",
> "committedVirtualMemorySize":2709114880,
> "freePhysicalMemorySize":16710127616,
> "freeSwapSpaceSize":16422531072,
> "processCpuLoad":0.13941671744473663,
> "processCpuTime":194609375000,
> "systemCpuLoad":0.25816002967796037,
> "totalPhysicalMemorySize":34261250048,
> "totalSwapSpaceSize":39361523712},
> "node":"localhost:8983_solr"}}
> {noformat}
> The SystemInfoHandler does this:
> {code}
> // Try some command line things:
> try {
> if (!Constants.WINDOWS) {
> info.add( "uname", execute( "uname -a" ) );
> info.add( "uptime", execute( "uptime" ) );
> }
> } catch( Exception ex ) {
> log.warn("Unable to execute command line tools to get operating
[jira] [Updated] (SOLR-14416) Nodes view doesn't work correctly when Solr is hosted on Windows
[
https://issues.apache.org/jira/browse/SOLR-14416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colvin Cowie updated SOLR-14416:
Affects Version/s: 7.7.2
8.1
8.2
8.1.1
8.3
8.3.1
> Nodes view doesn't work correctly when Solr is hosted on Windows
>
>
> Key: SOLR-14416
> URL: https://issues.apache.org/jira/browse/SOLR-14416
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 7.7.2, 8.1, 8.2, 8.1.1, 8.3, 8.3.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: image-2020-04-20-10-37-22-308.png
>
>
> I sent a message about this on the mailing list a long time ago and got no
> replies.
> Originally I saw it on 8.1.1, it's a problem in 8.3.1 and I don't expect it's
> fixed in 8.5, but I will check.
> On Solr 8.1.1 / 7.7.2 with Oracle 1.8.0_191 25.191-b12 with Solr running on
> Windows 10
> In the Nodes view of the Admin
> UI,http://localhost:8983/solr/#/~cloud?view=nodes there is a refresh button.
> However when you click it, the only thing that gets visibly refreshed is the
> 'bar chart' (not sure what to call it - it's shown when you choose show
> details) of the index shard size on disk. The other stats do not update.
> Also, when there is more than one node, only some of the node information is
> shown
> !image-2020-04-20-10-37-22-308.png!
> Firefox dev console shows:
> {noformat}
> _Error: s.system.uptime is undefined
> nodesSubController/$scope.reload/<@http://localhost:8983/solr/js/angular/controllers/cloud.js:384:11
> v/http://localhost:8983/solr/libs/angular-resource.min.js:33:133
> processQueue@http://localhost:8983/solr/libs/angular.js:13193:27
> scheduleProcessQueue/<@http://localhost:8983/solr/libs/angular.js:13209:27
> $eval@http://localhost:8983/solr/libs/angular.js:14406:16
> $digest@http://localhost:8983/solr/libs/angular.js:14222:15
> $apply@http://localhost:8983/solr/libs/angular.js:14511:13
> done@http://localhost:8983/solr/libs/angular.js:9669:36
> completeRequest@http://localhost:8983/solr/libs/angular.js:9859:7
> requestLoaded@http://localhost:8983/solr/libs/angular.js:9800:9_
> {noformat}
> The system response has upTimeMs in it for the JVM/JMX properties, but no
> system/uptime
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":63},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":49},
> "mode":"solrcloud",
> "zkHost":"localhost:9983",
> "solr_home":"...",
> "lucene":{
> "solr-spec-version":"8.1.1",
> "solr-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:20:01",
> "lucene-spec-version":"8.1.1",
> "lucene-impl-version":"8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef -
> ab - 2019-05-22 15:15:24"},
> "jvm":{
> "version":"1.8.0_211 25.211-b12",
> "name":"Oracle Corporation Java HotSpot(TM) 64-Bit Server VM",
> "spec":{
> "vendor":"Oracle Corporation",
> "name":"Java Platform API Specification",
> "version":"1.8"},
> "jre":{
> "vendor":"Oracle Corporation",
> "version":"1.8.0_211"},
> "vm":{
> "vendor":"Oracle Corporation",
> "name":"Java HotSpot(TM) 64-Bit Server VM",
> "version":"25.211-b12"},
> "processors":8,
> "memory":{
> "free":"1.4 GB",
> "total":"2 GB",
> "max":"2 GB",
> "used":"566.7 MB (%27.7)",
> "raw":{
> "free":1553268432,
> "total":2147483648,
> "max":2147483648,
> "used":594215216,
> "used%":27.670302242040634}},
> "jmx":{
> "bootclasspath":"...",
> "classpath":"start.jar",
> "commandLineArgs":[...],
> "startTime":"2019-06-20T11:41:58.955Z",
> "upTimeMS":516602}},
> "system":{
> "name":"Windows 10",
> "arch":"amd64",
> "availableProcessors":8,
> "systemLoadAverage":-1.0,
> "version":"10.0",
> "committedVirtualMemorySize":2709114880,
> "freePhysicalMemorySize":16710127616,
> "freeSwapSpaceSize":16422531072,
> "processCpuLoad":0.13941671744473663,
> "processCpuTime":194609375000,
> "systemCpuLoad":0.25816002967796037,
> "totalPhysicalMemorySize":34261250048,
> "totalSwapSpaceSize":39361523712},
> "node":"localhost:8983_solr"}}
> {noformat}
> The SystemInfoHandler does this:
> {code}
> // Try some command line things:
> try {
> if (!Constants.WINDOWS) {
> info.add( "uname", execute( "uname -a" ) );
> info.add( "uptime", execute(
