[
https://issues.apache.org/jira/browse/SOLR-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376191#comment-16376191
]
Gus Heck commented on SOLR-11949:
---------------------------------
Did some research into the above stack trace, which seems to occur in the event
that cluster state is requested for an alias.
org.apache.solr.client.solrj.impl.HttpClusterStateProvider#getState seems to
actually parse the exception message (yuck!!) to detect this... But it gets
logged as an error on the server side which is somewhat confusing since an
ERROR is usually something actually wrong that needs fixing... but as such,
for the purposes of this ticket the above stack trace does not represent a
problem.
> Create Time Routed Alias stress-test
> ------------------------------------
>
> Key: SOLR-11949
> URL: https://issues.apache.org/jira/browse/SOLR-11949
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Reporter: David Smiley
> Priority: Major
>
> It would be nice to have a scalability test / stress test of sorts for Time
> Routed Aliases to help identify any problems that may exist. At least at the
> moment, I'm thinking of a test that would never get run automatically (by say
> Jenkins or "ant test"), but I could change my mind. We already have some TRA
> tests of course but except for one of them, the tests are more about
> functionality rather than proving out possible race conditions & other
> scalability bugs.
> Something that creates one TRA up front then beats on it for awhile, then
> shuts down
> * configurable # nodes, and TRA statistics. Maybe 10-sec interval
> collections, with deleting collections older than a minute.
> * May randomly update the interval part-way through
> * sends data in multiple threads.
> * sends data to nodes randomly via HttpSolrClient or
> ConcurrentUpdateSolrClient or CloudSolrClient randomly (test infra can do
> this already except CUSC), or
> * sends data in batches of configurable sizes.
> * at the end verifies that the collections only hold the documents they
> should (one of my TRA tests has code that can be used here)
> Using this test, it'd be interesting to see what happens when a core for the
> oldest collection is receiving documents while simultaneously it is getting
> deleted (for being old).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
