Hi there

It is expected that the process will not show up in the Pending Process list while it is running Server Code. During such time, it would not be considered to be Pending, but rather Working. As such, it would not appear in a Pending list.

Ian

Hi,

I think you misunderstand. I am not receieving a list of pending tasks minus the 2 that is running.

What I am saying is the pending tasks failed to load. It is being blocked.

And if the server event is long enough (e.g. 10mins), the K2 client connection will timeout first even before returning a result of pending tasks.

Even though you are not using console mode can you check to see if it's exhibiting the following restriction?

Console Mode has the following limitations and performance implications for all Development Servers:

• Requires Local Login
• Single-threaded Execution only
• Single CPU only (multiple processor use is disabled)

How can I check that?

My licenese is listed under license management is "Partner Software"

I have tested this in my development vm as well as my SIT server. I don't think my development vm nor my SIT server is on 

• Single-threaded Execution only

We are on partner license.

I have capture a screencast based on the scenario.

https://docs.google.com/uc?id=0BxJ0ELWcUhuaNHhjXzQyQUIwVTQ

In the example you posted your code uses the system.threading.sleep method.  You do not want to use threading.sleep within a K2 process as you will cause issues and the behaviour you're seeing is expected.  Granted you're trying to replicate the server event performing some long running task but what you're actually doing is causing that K2 thread to not be able to respond for that period of time.

To test out your scenario more accurately just create a simple web service that uses System.Threading.Timer and call that web service from within the server event.  You may need to deal with timeout issues which in that case you should probably look at using an async server event which basically means it will call an external system and that asysnc server event will wait for the external system to call back to K2 and say its done and pass in any relevant information.  

Async server event with code sample:

http://help.k2.com/kb000272

You are right I am dooing a loop for 2 mins to simulate a 2 min unit of work.

That's not the main issue. Regardless whether it's an empty code block or doing some legititmate work. As long it is running for long period of time.

I think you are missing the point. How can an it be that when I call a pending tasks api during a goto and not returning any results be acceptable in an enterprise platform?

int x = 0;

while (true)
{

   x = 1 +1;

   if (time elapsed 2 mins) 
      break;
}

Making a event async requires that the sub system I interface with tell K2 when a transaction/completed.

1. What if that is not an option, changing the second system is not an option or a cost to bear.

2. I should have the choice to make it sync. As I want the state to move only when the event is completed.

Once again it is not the duration of the activity that's the concern, it is during multiple long runninng events a goto is perofrmed.

Other functionality is crippled.

That should not be the case.

Making a event async requires that the sub system I interface with tell K2 when a transaction/completed.

1. What if that is not an option, changing the second system is not an option or a cost to bear.

You're correct that modifying the other system is typically not an option.  However, you can create a simple web service that the async server event calls which in turn calls the other system waits for the response.  Handles timeouts and such and when it gets the correct data then calls back into the K2 async server event and passes the relevant data to it and the workflow can then continue on.  That's how I would approach this scenario.

2. I should have the choice to make it sync. As I want the state to move only when the event is completed.

Although it may not work the way you want it the async server event works well for calling systems where a response is often not immediate.

Hi Tim, 

My production system has been running over couple of years and latey the performance and usability has caused major issues.

Now I appreciate your suggestions to workaround. But I think we are skirting the fundamental issue. We are devising workarounds to what is a broken mechanism.

But what I want to essentially bring up is I believe a design flaw or an architectural mistake.  

A long running process or poor performing process should be isolated.

What I think is happening (my hunch) is there is a mutex on the data while a server event is running and is not released till the event is over. In the mean time other functionality such as client API for getting pending tasks is blocked until this mutex is release.

E.g.

Imagine we have a large mnc with site offices all over the world. The strategy is to have centralised workflow server.

Process development are done by various teams to support business processes and system processes all over the world.

All it takes is one process definition with a long server event and it will crippled the entire workflow system/API corporate wide.

Is this acceptable? Is this enterprise behaviour?

A running server event should be excluded or should not cause other API such as pending tasks or execute action to be blocked.