I have a BPM Process model which runs in to sleeping threads often from the subscription trigger,Because of this BPM stops accepting new documents published as the subscription trigger is concurrent and allows 10 max threads.
Here are the thread dump from the sleeping threads. Do you happen to know what is happening here?
Integration Server thread dump Java HotSpot(TM) 64-Bit Server VM (25.141-b15 mixed mode):
Mon Sep 28 09:55:48 EDT 2020
"TriggerTask:9:VASNPoCProcess.RFIDProcess.Dev_BPM:subscriptionTrigger" Id=248 in TIMED_WAITING
at java.lang.Thread.sleep(Native Method)
at com.wm.app.b2b.server.invoke.InvokeManager.invoke(InvokeManager.java:601)
at com.wm.app.b2b.server.invoke.InvokeManager.invoke(InvokeManager.java:443)
at com.wm.app.b2b.server.invoke.InvokeManager.invoke(InvokeManager.java:357)
at com.wm.app.b2b.server.dispatcher.trigger.Trigger.invokeService(Trigger.java:567)
at com.wm.app.b2b.server.dispatcher.trigger.Trigger.processMessage(Trigger.java:490)
at com.wm.app.b2b.server.dispatcher.trigger.DefaultTriggerTaskHelper.process(DefaultTriggerTaskHelper.java:256)
at com.wm.app.b2b.server.dispatcher.trigger.TriggerTask.run(TriggerTask.java:307)
at com.wm.util.pool.PooledThread.run(PooledThread.java:127)
at java.lang.Thread.run(Thread.java:748)
Started : Fri, 25 Sep 2020 19:37:21
Service Execution:
wm.prt.dispatch:handlePublishedInput
It is difficult to say why the threads are going into a sleep state, at a high level looks to me like there are many process documents getting published and the trigger is going to waiting due to built-in join conditions handled by the subscription trigger.
You can try to run debug related services to analyze more which are available in WmPRT.wm.prt.debug folder. These services are to be run at our own risk though. But they might give information if the IS is having Trace enabled.
Also, try to make the trigger serial and see that the process completes successfully without any issues. See if the issue replicates here as well.
As Firoz mentioned, Yes I would also suggest you to debug more on the PE layer (WmPRT) service and deep dive the trace level logs also I suspect the Broker/UM side of the messaging layer (concurrent throughput) as well…I hope this can be replicated in your LLE and troubleshoot there safe side.
Interestingy, I found that the subsciption trigger transient retry properties are causing it. By Default, the Subscription trigger has a retry until “Successful” ,we had kept this value was “maxAttempts” in the beginning as given below.
[ ]
But strangely, this value is set to its defaults((Successful) every time i do a build and upload of my process model. Do you have any idea how can i control this behavior?
Is it documented somewhere, i want to understand Why there is transient error handing by default on a subscription trigger?
A subscription trigger is generated to the Integration Server whenever you build and deploy the BPM.
I suggest you do not alter the properties of this trigger as it is managed by WmPRT & IS itself.
Also, I don’t see how it is related that your trigger is going for sleep due to these properties.
What exactly this means is to - Retry the trigger processing the service till the service is successful.
Regarding version and services, I checked it on 10.3 and found many folders under wm.prt.**, probably you should be finding similar on 10.1 as well. Check if you are running on the latest fixes for PRT or not.
]