流程停置在并行活动前无法继续流转，寻求除错思路
依视频教学建立新流程,在「拟稿」关卡之后建立2个活动「主管A」及「主管B」，
前置一个“并行活动”，后置一个“合并活动”，
路由皆采用预设值，如下图。
在拟稿关卡时点击“继继流转”，画面停止不会进入并行活动之后的「主管A」/「主管B」。
查看前台主控台及后台out.log都无异状。
版本：9.1.3
并行活动出去的2条路由上条件怎么写的？ 原本2条路由都用预设值
后来改成return true;
结果都是停置在loading...
而重新整理后，流程监控停留在拟稿关卡。
主管A/主管B/主管C处理人都是设成身份->特定成员 这种情况，要么浏览器，要么日志里，肯定是会有反应的，您截图出来看看 您好，在等待5分钟左右，在日志和浏览器已显示错误，如下图
浏览器错误如下图
日志稍長，貼上文字log
2024-09-27 14:08:47.154 ERROR com.x.processplatform.service.processing.jaxrs.work.WorkAction - id:2108e831-d029-4b14-ba00-22b2b1b4cff9, name:com.x.processplatform.service.processing.jaxrs.work.WorkAction, message:null, exception:java.util.concurrent.TimeoutException, id:2108e831-d029-4b14-ba00-22b2b1b4cff9, name:com.x.processplatform.service.processing.jaxrs.work.WorkAction, message:null, exception:java.util.concurrent.TimeoutException, person:cipher, method:PUT, request:http://127.0.0.1/x_processplatform_service_processing/jaxrs/work/6da52e4f-f6bd-436e-8b24-90f66c804b0e/processing, remoteHost:127.0.0.1, emoteAddr:127.0.0.1, head:Cache-Control:no-cache, no-transform
Accept:text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Access-Control-Allow-Credentials:true
Access-Control-Allow-Methods:GET, POST, OPTIONS, PUT, DELETE, HEAD, TRACE
x-token:KPTnTlJbhYIIUGH2pZ43giv-S8gcMUsyh1ten2IrzFo
User-Agent:Java/11.0.23
Connection:keep-alive
Host:127.0.0.1
Pragma:no-cache
Content-Length:275
Access-Control-Allow-Headers:x-requested-with, x-request, Content-Type, x-cipher, x-client, x-token
Content-Type:application/json;charset=UTF-8, body:{
"loop": 1,
"ignoreEmpowerIdentityList": [],
"person": "姓名@工號@P",
"identity": "姓名@部門_工號@I",
"signalStack": [],
"debugger": false,
"manualForceTaskIdentityList": [],
"type": "task",
"series": "911a60a0-45a4-4ba1-96d8-f6008a6c9a36"
}..
java.util.concurrent.TimeoutException: null
at java.util.concurrent.FutureTask.get(FutureTask.java:204) ~[?:?]
at com.x.processplatform.service.processing.jaxrs.work.ActionProcessing.execute(ActionProcessing.java:52) ~
at com.x.processplatform.service.processing.jaxrs.work.WorkAction.processing(WorkAction.java:80) ~
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52) ~
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:124) ~
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:167) ~
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$VoidOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:159) ~
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79) ~
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:475) ~
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:397) ~
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:81) ~
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:255) ~
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248) ~
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244) ~
at org.glassfish.jersey.internal.Errors.process(Errors.java:292) ~
at org.glassfish.jersey.internal.Errors.process(Errors.java:274) ~
at org.glassfish.jersey.internal.Errors.process(Errors.java:244) ~
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265) ~
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:234) ~
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:684) ~
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:394) ~
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:346) ~
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:366) ~
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:319) ~
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:205) ~
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:763) ~
at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1633) ~
at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:228) ~
at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~
at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1609) ~
at com.x.base.core.project.jaxrs.CipherManagerJaxrsFilter.doFilter(CipherManagerJaxrsFilter.java:66) ~
at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193) ~
at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1609) ~
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:561) ~
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602) ~
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) ~
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1612) ~
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) ~
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1434) ~
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) ~
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501) ~
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1582) ~
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) ~
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1349) ~
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~
at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:59) ~
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:716) ~
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~
at org.eclipse.jetty.server.Server.handle(Server.java:516) ~
at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383) ~
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:556) ~
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375) ~
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273) ~
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) ~
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) ~
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) ~
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) ~
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) ~
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) ~
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) ~
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375) ~
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:773) ~
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:905) ~
at java.lang.Thread.run(Thread.java:834) ~[?:?]
2024-09-27 14:08:47.161 ERROR com.x.processplatform.assemble.surface.jaxrs.task.ActionProcessing - id:da0f2589-da64-48ce-a56d-59877acbea69, name:com.x.processplatform.assemble.surface.jaxrs.task.ActionProcessing, message: , exception:java.lang.Exception.
java.lang.Exception:
at com.x.base.core.project.connection.ActionResponse.getData(ActionResponse.java:16) ~
at com.x.processplatform.assemble.surface.jaxrs.task.ActionProcessing.processingProcessingWork(ActionProcessing.java:349) ~
at com.x.processplatform.assemble.surface.jaxrs.task.ActionProcessing.processingTask(ActionProcessing.java:299) ~
at com.x.processplatform.assemble.surface.jaxrs.task.ActionProcessing.lambda$execute$1(ActionProcessing.java:93) ~
at java.lang.Thread.run(Thread.java:834) ~[?:?]
会发生此状况是在docker-compose.yml修改了O2OA版本(v.9.1.0 -> v9.1.3)，
后来改回v.9.1.0还是一样发生此问题；
如果此问题无解，我会尝试起一个干净的v9.1.3，再将设定迁移到新的容器中。 发现逾时是在com.x.processplatform.assemble.surface.jaxrs.task.ActionProcessing.java:110行发生,
Wo wo = responeQueue.poll(300, TimeUnit.SECONDS);
300秒后回传wo为null;
而上一步的
startSignalThreadIfAsyncSupported(param, id, responeQueue);
未进入if (BooleanUtils.isNotFalse(param.asyncSupported))的条件。
已解决，自问自答（因为期间有其他任务，所以现在才回覆）
这与之前启用GraalVM脚本调试功能有关。
在log可以看到Debugger监听的讯息(Debugger listening on ws://0.0.0.0:9222/xxxxxxxx........)，
只不過有“并行 - 合并”的流程启动监听的时机会不太一样。(如下图）
在进入拟稿关卡时，会启动监听2次；
在进入并行活动时，会启动监听1次。
所以将以上监听位址用Chrome开启并跳过中断点即可正常运行。
页:
[1]