You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Uwe Schindler (Jira)" <ji...@apache.org> on 2019/12/24 16:05:00 UTC

[jira] [Updated] (LUCENE-9110) Use StackWalker in tests instead of iterating through StackTraceElement arrays

     [ https://issues.apache.org/jira/browse/LUCENE-9110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Uwe Schindler updated LUCENE-9110:
----------------------------------
    Description: 
Followup of LUCENE-9109:
There are a lot of tests (especially around IndexWriter) that look into stack traces to inject failures or check that some methods were called in their call stack.

This issue will refactor all those tests by adding a few methods to LuceneTestCase that make it easy to verify if some method call/class is in stack trace. On master (Java 11) we can use StackWalker to do this checks, which has a speedup of sometimes >>2 times (depending on how deep you dive into call stack).

There are a few tests (only 3) that do more complex stack trace analysis. Those should be refactored at some point. For now I added a deprecated method to get the whole StackTrace in Java 11, which is still 2 times faster than using an Exception.

For branch 8.x i will apply the same patch, just the LuceneTestCase methods use the old "Java 8" way to inspect stack trace using the thread's stack trace (which is very expensive).

So this issue is mainly about refactoring the tests to use a common method pattern to check the existence of stack frames.

  was:
Followup of LUCENE-9109:
There are a lot of tests (especially around IndexWriter) that look into stack traces to inject failures or check that some methods were called in ther call stack.

This issue will refactor all those tests by adding a few methods to LuceneTestCase that make it easy to verify if some method call/class is in stack trace. On master (Java 11) we can use StackWalker to do this checks, which has a speedup of >2 times (depending on how you test it).

For branch 8.x i will apply the same patch, just the LuceneTestCase methods use the old "Java 8" way to inspect stack trace using the thread's stack trace (which is very expensive).

So this issue is mainly about refactoring the tests to use a common method pattern to check the existence of stack frames.


> Use StackWalker in tests instead of iterating through StackTraceElement arrays
> ------------------------------------------------------------------------------
>
>                 Key: LUCENE-9110
>                 URL: https://issues.apache.org/jira/browse/LUCENE-9110
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: general/test
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>            Priority: Major
>             Fix For: master (9.0), 8.5
>
>
> Followup of LUCENE-9109:
> There are a lot of tests (especially around IndexWriter) that look into stack traces to inject failures or check that some methods were called in their call stack.
> This issue will refactor all those tests by adding a few methods to LuceneTestCase that make it easy to verify if some method call/class is in stack trace. On master (Java 11) we can use StackWalker to do this checks, which has a speedup of sometimes >>2 times (depending on how deep you dive into call stack).
> There are a few tests (only 3) that do more complex stack trace analysis. Those should be refactored at some point. For now I added a deprecated method to get the whole StackTrace in Java 11, which is still 2 times faster than using an Exception.
> For branch 8.x i will apply the same patch, just the LuceneTestCase methods use the old "Java 8" way to inspect stack trace using the thread's stack trace (which is very expensive).
> So this issue is mainly about refactoring the tests to use a common method pattern to check the existence of stack frames.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org