[
https://issues.apache.org/jira/browse/PHOENIX-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14248873#comment-14248873
]
James Taylor edited comment on PHOENIX-1528 at 12/16/14 8:37 PM:
-----------------------------------------------------------------
Running on my Mac, I'm seeing an issue too, but as [~ndimiduk] mentioned as
well, it's not clear where the issue is:
{code}
ERROR] Failed to execute goal
org.apache.maven.plugins:maven-failsafe-plugin:2.18:integration-test
(HBaseManagedTimeTests) on project phoenix-core: Execution
HBaseManagedTimeTests of goal
org.apache.maven.plugins:maven-failsafe-plugin:2.18:integration-test failed.
NullPointerException -> [Help 1]
{code}
The two longest running tests are:
| MutableIndexIT | 572 sec |
| QueryIT | 749 sec |
This is too long IMO and these tests can be broken up pretty easily.
MutableIndexIT runs each test twice: once as a global index and once as a local
index. Instead, we can have an abstract base class, BaseMutableIndexIT that has
all the non test methods (with the boolean isLocal argument). Then we can two
test classes: LocalMutableIndexIT and GlobalMutableIndexIT which just call
through to those methods. Or another even easier way it to remove the isLocal
argument and make it a member variable on the base class with all the methods
annotated with an @Test annotation. Then the concrete subclasses would set the
member variable to true or false.
The time for QueryIT can also be cut in half. QueryIT is derived from
BaseQueryIT which is a parameterized test that runs 7x: once with no indexes,
3x with different global indexes, and 3x with different local indexes. We could
conditionally add those indexes by having a member variable indicating the type
of indexes we should add. Then we'd add two subclasses to QueryIT that sets the
variable to GLOBAL versus LOCAL.
I'll make these changes first so that the max test run is less than 600 seconds
and then we can make this change.
was (Author: jamestaylor):
Running on my Mac, I'm seeing an issue too, but as [~ndimiduk] mentioned as
well, it's not clear where the issue is:
{code}
ERROR] Failed to execute goal
org.apache.maven.plugins:maven-failsafe-plugin:2.18:integration-test
(HBaseManagedTimeTests) on project phoenix-core: Execution
HBaseManagedTimeTests of goal
org.apache.maven.plugins:maven-failsafe-plugin:2.18:integration-test failed.
NullPointerException -> [Help 1]
{code}
The two longest running tests are:
| MutableIndexIT | 572 sec |
| QueryIT | 749 |
This is too long IMO and these tests can be broken up pretty easily.
MutableIndexIT runs each test twice: once as a global index and once as a local
index. Instead, we can have an abstract base class, BaseMutableIndexIT that has
all the non test methods (with the boolean isLocal argument). Then we can two
test classes: LocalMutableIndexIT and GlobalMutableIndexIT which just call
through to those methods. Or another even easier way it to remove the isLocal
argument and make it a member variable on the base class with all the methods
annotated with an @Test annotation. Then the concrete subclasses would set the
member variable to true or false.
The time for QueryIT can also be cut in half. QueryIT is derived from
BaseQueryIT which is a parameterized test that runs 7x: once with no indexes,
3x with different global indexes, and 3x with different local indexes. We could
conditionally add those indexes by having a member variable indicating the type
of indexes we should add. Then we'd add two subclasses to QueryIT that sets the
variable to GLOBAL versus LOCAL.
I'll make these changes first so that the max test run is less than 600 seconds
and then we can make this change.
> Time out stuck tests
> --------------------
>
> Key: PHOENIX-1528
> URL: https://issues.apache.org/jira/browse/PHOENIX-1528
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
> Fix For: 5.0.0, 4.3
>
> Attachments: 1528.txt
>
>
> We should have surefire kill tests that get stuck so the remainder of the
> suite can make progress. I propose a global timeout of 600 seconds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
