[
https://issues.apache.org/jira/browse/SOLR-11949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16368612#comment-16368612
]
Gus Heck commented on SOLR-11949:
---------------------------------
Decided not to make it a patch yet, given how much there is to do, but the gist
of it is that it sets up threads, each dedicated to sending documents that
should fall in a single partition. These threads start before any partitions
are valid (and thus adding fails), and then as time passes, the valid range of
partitions changes and the idea is that threads succeed and then start failing
again as they pass beyond the maximum time that the TRA supports. The actual
testing of stuff is quite light right now and there's much to be done there,
but I'm still trying to get it to work in both the miniSolrCloud case and while
talking to an external cluster (so I can also manually explore the results
after the fact with queries). At one point it looked like I had my threads
under control and had some clean success runs, but something I did has let them
leak again... or perhaps I got lucky.
> 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: [email protected]
For additional commands, e-mail: [email protected]
