So far the best solution I've seen on the forums is this:
- For a delay between step 1 and step 2, Setup a dummy receive step R
- Setup a join between step 1 and R with a join timeout of the desired timeout
- Set the transition going from the join to step 2 with a condition of timeout
Creating a sub-process can at least hide the complexity and technical details and make the process flow more readable.
While I don't know the implementation details of the join timeout I wouldn't be surprised if the thread is held while waiting for the join (that never happens). Have you investigated this?
ReplyDeleteI haven't directly checked it, but when I was researching this was the one way I found which is NOT supposed to hold the thread. It can be common to have long join times (waiting for external or async docs, etc) so it would make sense that this would not hold the thread.
ReplyDeleteHi, there is way of doing this by using the ps.util.system.sleep service in the PS_Utilities2 package available across. This service would put a service thread to a sleep state for the said timeline and then wakes it up for continued execution. Hope this helps.
ReplyDeletenightfox...
Yes, and that works for very short times (several seconds, maybe up to a minute) but for longer times you will then actually be keeping the thread alive and eating up server threads and you don't want to do that for long delays.
ReplyDelete