[
https://issues.apache.org/jira/browse/SOLR-15644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419448#comment-17419448
]
Mark Robert Miller edited comment on SOLR-15644 at 9/23/21, 8:19 PM:
---------------------------------------------------------------------
Yes, the that’s the issue. The thread is in a terminated state and not
reporting isAlive false. You wouldn’t notice the issue. Tests that have that
much going on are either slow and bumbling and it’s irrelevant, or they are
reasonable but people don’t care about making test runs of integration tests of
that scale very fast, and so no one is going to care or even notice if the test
tear downs are taking some amount longer than they should for no reason.
I probably usually just end up dealing with it in a thread filter anyway.
It just goes back to the point. I’m either talking to people that couldn’t
address issues or recognize the issues or people that could address them but
never would for various reasons. If I’m going to talk about a noticeable
unnecessary delay when tests are fast, who really cares that doesn’t care that
the tests are minutes. If I’m going to talk about all the ways Solr will
misbehave and that the test tools are not geared towards that, someone that is
never going to fight Solr in that battle is gong about as productive as talking
to a wall.
The point is, the control and options the test framework give you are geared
towards being able to use the framework on a project that is not ready for it.
So you have exceptions, you have your 10 second thread linger. That’s what the
framework should be geared towards. You putting in that linger to put in the
test framework is how things should go. Step next is to then fix the software
over time and remove those broad exceptions. Otherwise you are 10 years later
and all that has happened is more exceptions and bad behavior has joined the
fray.
So what you need to do is remove those broad controls to actually be able to
take advantage of the framework as intended. Except if you try and do that, you
will find you have to take more fine grained approaches to deal with what’s
left.
If you have a problem with one of those fine grained approaches - with code
that id actually doing something and going in, please speak up. But in this
context you will just find me annoyed being asked to pre explain a broad array
issues to someone that that could address all of Solrs issues given the time
and inclination, but for all kinds of I’m sure valid reasons will not.
If someone was going to be doing the same work with the same goals, I’d find
the whole useless back and forth much less useless. But as is, there is a lot
more value in looking at whatever code to address an issue goes in than being
defensive about the test framework not being gods gift to problems that are not
even in its wheel house.
was (Author: markrmiller):
Yes, the that’s the issue. The thread is in a terminated state and not
reporting isAlive false. You wouldn’t notice the issue. Tests that have that
much going on are either and slow and bumbling and it’s irrelevant, or they are
reasonable but people don’t care about making test runs of integration tests of
that scale very fast, and so no one is going to care or even notice if the test
test downs are taking some amount longer than they should for no reason.
I probably usually just end up dealing with it in a thread filter anyway.
It just goes back to the point. I’m either talking to people that couldn’t
address issues or recognize the issues or people that could address them but
never would for various reasons. If I’m going to talk about a noticeable
unnecessary delay when tests are fast, who really cares that doesn’t care that
the tests are minutes. If I’m going to talk about all the ways Solr will
misbehave and that the test tools are not geared towards that, someone that is
never going to fight Solr in that battle is gong about as productive as talking
to a wall.
The point is, the control and options the test framework give you are geared
towards being able to use the framework on a project that is not ready for it.
So you have exceptions, you have your 10 second thread linger. That’s what the
framework should be geared towards. You putting in that linger to put in the
test framework is how things should go. Step next is to then fix the software
over time and remove those broad exceptions. Otherwise you are 10 years later
and all that has happened is more exceptions and bad behavior has joined the
fray.
So what you need to do is remove those broad controls to actually be able to
take advantage of the framework as intended. Except if you try and do that, you
will find you have to take more fine grained approaches to deal with what’s
left.
If you have a problem with one of those fine grained approaches - with code
that id actually doing something and going in, please speak up. But in this
context you will just find me annoyed being asked to pre explain a broad array
issues to someone that that could address all of Solrs issues given the time
and inclination, but for all kinds of I’m sure valid reasons will not.
If someone was going to be doing the same work with the same goals, I’d find
the whole useless back and forth much less useless. But as is, there is a lot
more value in looking at whatever code to address an issue goes in than being
defensive about the test framework not being gods gift to problems that are not
even in its wheel house.
> Add the ability to interrupt and wait for threads for problematic tests.
> ------------------------------------------------------------------------
>
> Key: SOLR-15644
> URL: https://issues.apache.org/jira/browse/SOLR-15644
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
> Reporter: Mark Robert Miller
> Assignee: Mark Robert Miller
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The stuff in the test framework is slow and lacks control. For problematic
> tests, you don't want to linger first and you want fine control around
> interrupting - interrupting with a sledgehammer approach can actually make
> things take longer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
