ID range for high frequency schedules / alternatives to the scheduler

Hi folks,

I'm starting a workflow that has to check a datasource for changes and exceute a IPC event based on the result. (It runs a stored procedure and only has to react if there are results.)
So far I've got the workflow scheduled using the scheduler in Management. This works without an issue.
However: If I'm not mistaken, everytime a workflow is started through the scheduler it is started as a new instance and thus the ProcInstID increases.

I'm not sure of the exact ID range for the ProcInstID or if there is another way to avoid blowing the ID out of proportion.
My initial thought was to have one workflow always running that would just loop indefinitely. I've read that this might cause the state to grow too much. Also if the workflow fails somewhere, it freezes up my process.

For reference, the schedule I need is: Once every 5 minutes during workhours. (So you can see why the ID would increase rapidly!)

Has anyone had a similar situation? Or a different approach?
Thank you in advance for pointers on this topic.

Kind regards,

Alex

Page 1 / 1

In the K2 database, the ProcInstID should be represented as the int datatype. The ProcInstID is therefore limited by the range allowed for that datatype. According to Microsoft, that range is -2^31 (-2,147,483,648) to 2^31-1 (2,147,483,647).

I have yet seen anyone complain about the ProcInstID hitting that limit, so I will suggest you test this out in a separate environment before implementing it in production.

Hi,

if the datatype is really the only limit, the workflow could run for almost 55 years (pretending it is the only one). That would not be a problem. You'd have keep in mind not to implement to many such scheduled workflows on one system.

I think you're right, I'll have to try it on a differnt system to see how it impacts performance and such.

Thanks!

In such a scenario you might want to use the Windows Task Scheduler that will call a powershell script or a simple exe to start the K2 process and schedule it every 5 minutes.

https://help.k2.com/onlinehelp/k2blackpearl/devref/4.7/default.htm#Using_the_Windows_Powershell_to_start_a_K2_Process.html

I would recommend against creating one workflow process instance that "stays alive" and does its thing every 5 minutes. I've taken that path in the past and found it was hard to manage, and if it went down for some reason it was very difficult to know. maintaining that thing and keeping it alive became a daily hassle. Any of the other suggestions presented here would be better approaches

Hi Tim,

but that would still create a new instance every time, wouldn't it?

Alex

Hi,

yeah, I think with this number of instances I'm not going to run into any issues soon.

Still, I'm not happy with creating an instance every time.

The number of possible instances certainly makes this more of a cosmetic issue, though.

Thank you!

Alex

@boringNerd wrote:
In the K2 database, the ProcInstID should be represented as the int datatype. The ProcInstID is therefore limited by the range allowed for that datatype. According to Microsoft, that range is -2^31 (-2,147,483,648) to 2^*personal details removed* (2,147,483,647).

I have yet seen anyone complain about the ProcInstID hitting that limit, so I will suggest you test this out in a separate environment before implementing it in production.

Yes, it would create a new instance every time but as others have noted, the K2 database is setup in such a way that it should not be an issue to create so many process instances on a regular basis.

Hi,

It sounds like the concern is K2 thread pool. I would agree with tbyrne777 on this, K2 database is setup in a way to handle this but it could be the threadpool from K2 server that might have to be tuned/twisted a bit.

K2 Server Thread Pool settings

https://help.k2.com/kb001446

Thread pool

https://help.k2.com/kb000209