为什么在“时间限制测试”上运行某些代码。线程而不是主线程?

发布于 2025-01-30 07:49:51 字数 1423 浏览 1 评论 0原文

我有一些测试。我注意到我的日志消息有时表明代码在主线程上运行。其他日志消息表明代码在“时间限制测试”线程上运行。我的许多测试都指定了超时。

00000 Time-LIMT警告启动GTP2 :(型号-18(0,1)...

00001 Time-LIMT警告响应2:= A1

00002主警告名为线程!...

编辑1。由FailOntimeout()开始,请参见下文。 经过的时间都小于测试的超时值。

在所有情况下,

00000 Time-Limt严重不主! “时间限制测试” 1.491111 ms。 200毫秒。在controller.gtpbackend.startgtp()中 controller.gtpbackend.startgtp(gtpbackend.java:50) controller.abothtestcase.testbothgenmovetrue(abothtestcase.java:39) java.base/jdk.internal.reflect.nativemethodaccessorimpl.invoke0(本地 方法) java.base/jdk.internal.reflect.nativemethodaccessorimpl.invoke(nativemethodaccessorimpl.java:77) java.base/jdk.internal.reflect.delegatingmethodaccessorimpl.invoke(delegatingmethodaccessorimpl.java:43) java.base/java.lang.reflect.method.invoke(method.java:568) org.junit.runners.model.frameworkmethod $ 1.RunreflectiveCall(frameworkmethod.java:59) org.junit.internal.runners.model.reflectivecallable.run(ReflectiveCallable.java:12) org.junit.runners.model.frameworkmethod.invokeexplosively(frameworkmethod.java:56) org.junit.internal.runners.statement.invokemethod.evaluate(Invokemethod.java:17) org.junit.internal.runners.statement.failOntimeout $ callablestatement.call(fairontimeout.java:299) org.junit.internal.runners.statement.failOntimeout $ callablestatement.call(fairontimeout.java:293) java.base/java.util.concurrent.futuretask.run(futuretask.java:264)

I have some tests. I notice that sometime my log messages indicate that the code is running on the main thread. Other log messages indicate that the code is running on the "Time-limited test" thread. Many of my tests have a timeout specified.

00000 Time-limt WARNING start gtp2: (a model-18 (0,1) ...

00001 Time-limt WARNING response2: = A1

00002 main WARNING named threads! ...

Edit 1. The "Time-limited test" thread is started by FailOnTimeout() (please see below). The elapsed time in milliseconds is give as well as the timeout time (200 ms.). I have a few hundred tests that are similar but only a dozen or so timeout on me. In all cases the elapsed time is less than the timeout value for the test.

These tests start up one to five threads, run some test, and then try to shutdown gracefully by interrupting and joining.

00000 Time-limt SEVERE not main! 'Time-limited test' 1.491111 ms.
200 ms. in controller.GTPBackEnd.startGTP()
controller.GTPBackEnd.startGTP(GTPBackEnd.java:50)
controller.ABothTestCase.testBothGenmoveTrue(ABothTestCase.java:39)
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.base/java.lang.reflect.Method.invoke(Method.java:568)
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

阪姬 2025-02-06 07:49:51

这将是您正在测试的代码的工件。该消息是指“ Time-Limt”(SIC)线程。该拼写错误是一个很大的线索 1 该线程不属于Junit测试框架。

因此,我的猜测是您正在测试的应用程序代码创建线程并将其命名为“ Time-Limt”。该线程生成日志消息。一些测试(在“主”线程上运行)调用应用程序代码(在“主”线程上)...与“ time-limt”线程交互,该线程产生日志消息。

简而言之,这些消息不是直接证据表明该测试在不同的线程上运行。


1-如果您怀疑我的推论,请下载所使用的Junit版本的源代码,然后搜索String time -limt。我可能是错误的。

This will be an artifact of the code that you are testing. The message refers to a "time-limt" (sic) thread. That spelling error is a big clue1 that the thread doesn't belong to the JUnit test framework.

So, my guess is that the application code that you are testing creates a thread and names it "time-limt". That thread generates log messages. Some test (running on the "main" thread) calls the application code (on the "main" thread) ... which interacts with the "time-limt" thread ... which produces the log messages.

In short, those messages are not direct evidence that the test are running on different threada.


1 - If you doubt my inference, download the source code for the version of JUnit you are using, and search for the string time-limt. I could be wrong.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文