Questions about unexpected situations where the stop method stops a thread #115
Comments
|
Hi @MrLi2018 thank you for raising this issue! I assume this error should be raised when the script runs for longer than it is allowed to run or the memory limit is exhausted. Could this be the case here? Would it be possible to refactor the script to use less CPU or to increase the limits? Also if memory limits are used, these are often not very accurate due to JVM limitations, especially if threads are long running. Hope this helps! |
|
Thank you for answering. However, the RESTful interface of another service is invoked in my script. The execution time of the CPU cannot be controlled, @mxro |
|
If that is the case, could you then maybe simply not set the CPU limit? Otherwise it may also be an option to do the REST call before running the script and then just inject the results? |
|
I can't do this because I need to ensure the security of the script. The call parameters of the restful interface are passed in the script and are not fixed, so we can't call them externally. Moreover, our script is applied in Flink, which requires high performance but also ensures security
…------------------ 原始邮件 ------------------
发件人: "javadelight/delight-nashorn-sandbox" ***@***.***>;
发送时间: 2021年8月21日(星期六) 凌晨4:26
***@***.***>;
***@***.******@***.***>;
主题: Re: [javadelight/delight-nashorn-sandbox] Questions about unexpected situations where the stop method stops a thread (#115)
If that is the case, could you then maybe simply not set the CPU limit?
Otherwise it may also be an option to do the REST call before running the script and then just inject the results?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
|
Yes, I only set the CPU time of the thread and found that it was not very stable. Later, I set the on-site memory, but it did become unstable after running for a long time. What is the reason and how to avoid it
…------------------ 原始邮件 ------------------
发件人: "javadelight/delight-nashorn-sandbox" ***@***.***>;
发送时间: 2021年8月19日(星期四) 下午4:23
***@***.***>;
***@***.******@***.***>;
主题: Re: [javadelight/delight-nashorn-sandbox] Questions about unexpected situations where the stop method stops a thread (#115)
Hi @MrLi2018 thank you for raising this issue!
I assume this error should be raised when the script runs for longer than it is allowed to run or the memory limit is exhausted. Could this be the case here?
Would it be possible to refactor the script to use less CPU or to increase the limits?
Also if memory limits are used, these are often not very accurate due to JVM limitations, especially if threads are long running.
Hope this helps!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
|
Sorry can't think of much more what to do than increase CPU and memory limits. Otherwise you could maybe add a timeout to the REST call? So when that takes longer than a second or so, you could terminate the script then and know for sure what was the issue? Yeah maybe worth a try to explore how the same works in GraalVM, there is a sandbox for that too: https://github.com/javadelight/delight-graaljs-sandbox |
When executing scripts, we need to invoke other third-party remote services. However, an exception occurs, and our services are unavailable.
The following code is involved:
NashornSandboxImpl.LOG.error(this.getClass().getSimpleName() + ": Thread hard shutdown!");
this.threadToMonitor.stop();
The logs are as follows:
[ERROR] ThreadMonitorExt: Thread hard shutdown!
`java.lang.reflect.InvocationTargetException: null
at sun.reflect.GeneratedMethodAccessor130.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_272]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_272]
at com.huawei.ies.cache.redis.RedisProxy.invoke(RedisProxy.java:64)
at com.sun.proxy.$Proxy77.smembers(Unknown Source) ~[?:?]
at com.huawei.ies.cache.redis.SimpleOper.smembers(SimpleOper.java:53)
at com.huawei.ies.cache.manage.CacheDataService.getRelationObjectOnOther
at com.huawei.ies.cache.manage.CacheDataService.lambda$null$7(CacheDataService.java:308) ~
at java.util.ArrayList.forEach(ArrayList.java:1259) ~[?:1.8.0_272]
at com.huawei.ies.cache.manage.CacheDataService.lambda$getCacheRelationObject$8
at java.util.HashMap.forEach(HashMap.java:1289) [?:1.8.0_272]
at com.huawei.ies.cache.manage.CacheDataService.getCacheRelationObject
at com.huawei.ies.cache.manage.CacheDataService.getRelationFromRedis
at com.huawei.ies.cache.service.OpenDataServiceImpl.getRelationData
at com.huawei.ows.ceae.infrastructure.script.call.dim.DIMQueryUtil.getRelations
at jdk.nashorn.internal.scripts.Script$Recompilation$1166$2255A$^eval_._consumerFun#getCloudLineIdByCircuitNo(:81) [?:?]
at jdk.nashorn.internal.scripts.Script$Recompilation$964$1932$^eval_._consumerFun#main(:49) [?:?]
at jdk.nashorn.internal.scripts.Script$Recompilation$962$1815A$^eval_._consumerFun(:39) [?:?]
at jdk.nashorn.internal.scripts.Script$Recompilation$961$1716A$^eval_.run(:31) [?:?]
at com.huawei.ows.ceae.infrastructure.script.api.RunScript$$NashornJavaAdapter.run(Unknown Source) [?:?]
at com.huawei.ows.ceae.infrastructure.script.sandox.SecureJSExecutor.operate(SecureJSExecutor.java:26)
at com.huawei.ows.ceae.infrastructure.script.sandox.BaseSecureJsOperator.run(BaseSecureJsOperator.java:71)
at com.huawei.ows.ceae.infrastructure.script.sandox.SecureJSExecutor.run(SecureJSExecutor.java:15)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_272]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_272]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_272]
Caused by: java.lang.ThreadDeath
at java.lang.Thread.stop(Thread.java:853) ~[?:1.8.0_272]
at delight.nashornsandbox.internal.ThreadMonitor.run(ThreadMonitor.java:124)
@tangrammer @turbanoff @obourgain @sinaa `Please answer.
The text was updated successfully, but these errors were encountered: