Limits vs Deadlines

[Sterba]

I am about to implement Time-checking functionality into my application, and it seems that Shark offers me two options: Limits and Deadlines.

My question is, when to use which one of them and what is the best practice to implement them? Which one approach to use if it is needed to reassign Activity to another user in case of timeout?

This is what I have learned so far and may be this will help other users to orient themselves in this topic:
Limits
1. Defined in XPDL for both ProcessDefinitions and Activities in Duration units (List: Days, mins, secs...)
2. Checking for Limits is responsibility of the client program (manual, or some kind of SchedulerThread) - org.enhydra.shark.client.utilities.LimitChecker
3. The desired action when Limit is reached is not defined in XPDL. Its implementation depends fully on the client program

Deadlines
1. Defined in XPDL Activities as Deadline condition using java.util.Date in its script
2. Checking for Deadlines is responsibility of the client program as well (manual, or some kind of SchedulerThread -CORBA can do this automatically) org.enhydra.shark.client.utilities.DeadlineChecker as seen in SharkAdmin application
3. The desired action when Deadline is reached is defined in XPDL as Exception Transaction leading to defined Activity. Its implementation is defined in XPDL as well.
4. Allowing Synchronous and Asynchronous execution - If it is asynchronous deadline, the user's activity won't be terminated, and if it is synchronous one, it will be terminated.

Conclusion: Limits are good for simple tasks: Notifying responsible participant when limit is reached, or closing ProcessInstance if nobody is working on it for long time, ...
Deadlines are good for complex tasks, fully defined in XPDL: Time limit is in any way affecting or changing the process flow...

If I am mistaking, please let me know... thx

BTW documentation FAQ says something about LimitAgent interface, but it seems not to exist in current release...

[Sasa Bojanic]

Hi,

you've understood everything correctly. LimitAgent interface from the
FAQ is deprecated in Shark2.0. Previously it was one of shark's internal
components. In Shark 2.0 we changed the logic, and provided an interface
to get the information about limits for activities and processes.

About the best practice...it depends on the use-case :-)

Regards,
Sasa.

Sterba wrote:

> I am about to implement Time-checking functionality into my application, and
> it seems that Shark offers me two options: Limits and Deadlines.
>
> My question is, when to use which one of them and what is the best practice
> to implement them? Which one approach to use if it is needed to reassign
> Activity to another user in case of timeout?
>
> This is what I have learned so far and may be this will help other users to
> orient themselves in this topic:
> Limits
> 1. Defined in XPDL for both ProcessDefinitions and Activities in Duration
> units (List: Days, mins, secs...)
> 2. Checking for Limits is responsibility of the client program (manual, or
> some kind of SchedulerThread) -
> org.enhydra.shark.client.utilities.LimitChecker
> 3. The desired action when Limit is reached is not defined in XPDL. Its
> implementation depends fully on the client program
>
> Deadlines
> 1. Defined in XPDL Activities as Deadline condition using java.util.Date in
> its script
> 2. Checking for Deadlines is responsibility of the client program as well
> (manual, or some kind of SchedulerThread -CORBA can do this automatically)
> org.enhydra.shark.client.utilities.DeadlineChecker as seen in SharkAdmin
> application
> 3. The desired action when Deadline is reached is defined in XPDL as
> Exception Transaction leading to defined Activity. Its implementation is
> defined in XPDL as well.
> 4. Allowing Synchronous and Asynchronous execution - If it is asynchronous
> deadline, the user's activity won't be terminated, and if it is synchronous
> one, it will be terminated.
>
> Conclusion: Limits are good for simple tasks: Notifying responsible
> participant when limit is reached, or closing ProcessInstance if nobody is
> working on it for long time, ...
> Deadlines are good for complex tasks, fully defined in XPDL: Time limit is
> in any way affecting or changing the process flow...
>
> If I am mistaking, please let me know... thx
>
> BTW documentation FAQ says something about LimitAgent interface, but it
> seems not to exist in current release...
>
>  

--
You receive this message as a subscriber of the shark@... mailing list.
To unsubscribe: mailto:shark-unsubscribe@...
For general help: mailto:sympa@...?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

[Sterba]

Thanks for your response Sasa!
  Actually it seems that I haven't understood Limit checking for Activities correctly... Considering test_js_basic example I am not able to get any of reached limits for its Activities. I am fallowing these steps:
1. start test_js_basic Process in TWS Admin
2. I run my test code, which check periodically for all reached Activities and Process limits:
for (int i = 0; i < 60; i++) {
                        System.out.println("i: " + i);
                        ExecutionAdministration execAdmin = Shark.getInstance().getExecutionAdministration();
                        WMActivityInstance[] returned = execAdmin.checkLimitsWithActivityFiltering(seshandle, /*actFilter*/null).getArray();
                        System.out.println("\tacitvities: " + returned.length);
                        WMProcessInstance[] returned2 = execAdmin.checkLimitsWithProcessFiltering(seshandle, /*actFilter*/null, true).getArray();
                        System.out.println("\tprocesses: "+ returned2.length);
                        Thread.sleep(1000);
                }

After 60 seconds I will get reached limit for the Process but never for the Activities. I was expecting, that after 10 seconds from process start I will get reached limit for A1 Activity, after another 10 seconds for A2, etc.

Another confusing thing (which is in opposition with my expectations above) is Activities limit definition in TWE documentation (page 78), which says that "It is counted from the starting date/time of the Process". According to this all Activities in test_js_basic example have only 10 seconds to complete each - apparently I misunderstood something....  From whitch time is it counting for each Activity?

Regards,
Peter Sterba

Sasa Bojanic wrote:

Hi,

you've understood everything correctly. LimitAgent interface from the
FAQ is deprecated in Shark2.0. Previously it was one of shark's internal
components. In Shark 2.0 we changed the logic, and provided an interface
to get the information about limits for activities and processes.

About the best practice...it depends on the use-case :-)

Regards,
Sasa.

Sterba wrote:
> I am about to implement Time-checking functionality into my application, and
> it seems that Shark offers me two options: Limits and Deadlines.
>
> My question is, when to use which one of them and what is the best practice
> to implement them? Which one approach to use if it is needed to reassign
> Activity to another user in case of timeout?
>
> This is what I have learned so far and may be this will help other users to
> orient themselves in this topic:
> Limits
> 1. Defined in XPDL for both ProcessDefinitions and Activities in Duration
> units (List: Days, mins, secs...)
> 2. Checking for Limits is responsibility of the client program (manual, or
> some kind of SchedulerThread) -
> org.enhydra.shark.client.utilities.LimitChecker
> 3. The desired action when Limit is reached is not defined in XPDL. Its
> implementation depends fully on the client program
>
> Deadlines
> 1. Defined in XPDL Activities as Deadline condition using java.util.Date in
> its script
> 2. Checking for Deadlines is responsibility of the client program as well
> (manual, or some kind of SchedulerThread -CORBA can do this automatically)
> org.enhydra.shark.client.utilities.DeadlineChecker as seen in SharkAdmin
> application
> 3. The desired action when Deadline is reached is defined in XPDL as
> Exception Transaction leading to defined Activity. Its implementation is
> defined in XPDL as well.
> 4. Allowing Synchronous and Asynchronous execution - If it is asynchronous
> deadline, the user's activity won't be terminated, and if it is synchronous
> one, it will be terminated.
>
> Conclusion: Limits are good for simple tasks: Notifying responsible
> participant when limit is reached, or closing ProcessInstance if nobody is
> working on it for long time, ...
> Deadlines are good for complex tasks, fully defined in XPDL: Time limit is
> in any way affecting or changing the process flow...
>
> If I am mistaking, please let me know... thx
>
> BTW documentation FAQ says something about LimitAgent interface, but it
> seems not to exist in current release...
>
>  




--
You receive this message as a subscriber of the [e-mail] mailing list.
To unsubscribe: mailto:[e-mail]
For general help: mailto:[e-mail]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

[Sasa Bojanic]

Hi,

as far that I can see, it works correctly ... (of course I had to begin
and commit transaction inside the for loop).
This is the output that I get:

i: 0
2008-07-02 14:41:18,968: -----> Activity : 201_201_test_js_basic_A1 has
reached its limit
    acitvities: 1
2008-07-02 14:41:19,000: -----> Process : 201_test_js_basic has reached
its limit
2008-07-02 14:41:19,000: -----> Activity : 201_201_test_js_basic_A1 has
reached its limit
    processes: 1

Limit time for the process is exceeded 60 seconds after process has started.

The same is for the activities. E.g. limit for activity A2 will be
exceeded 10sec after activity is created (which happens immediately
after activity A1 has finished).

Greetings,
Sasa.

Sterba wrote:

> Thanks for your response Sasa!
>   Actually it seems that I haven't understood Limit checking for Activities
> correctly... Considering test_js_basic example I am not able to get any of
> reached limits for its Activities. I am fallowing these steps:
> 1. start test_js_basic Process in TWS Admin
> 2. I run my test code, which check periodically for all reached Activities
> and Process limits:
> for (int i = 0; i < 60; i++) {
> System.out.println("i: " + i);
> ExecutionAdministration execAdmin =
> Shark.getInstance().getExecutionAdministration();
> WMActivityInstance[] returned =
> execAdmin.checkLimitsWithActivityFiltering(seshandle,
> /*actFilter*/null).getArray();
> System.out.println("\tacitvities: " + returned.length);
> WMProcessInstance[] returned2 =
> execAdmin.checkLimitsWithProcessFiltering(seshandle, /*actFilter*/null,
> true).getArray();
> System.out.println("\tprocesses: "+ returned2.length);
> Thread.sleep(1000);
> }
>
> After 60 seconds I will get reached limit for the Process but never for the
> Activities. I was expecting, that after 10 seconds from process start I will
> get reached limit for A1 Activity, after another 10 seconds for A2, etc.
>
> Another confusing thing (which is in opposition with my expectations above)
> is Activities limit definition in TWE documentation (page 78), which says
> that "It is counted from the starting date/time of the Process". According
> to this all Activities in test_js_basic example have only 10 seconds to
> complete each - apparently I misunderstood something.... :confused: From
> whitch time is it counting for each Activity?
>
> Regards,
> Peter Sterba
>
>
> Sasa Bojanic wrote:
>  
>> Hi,
>>
>> you've understood everything correctly. LimitAgent interface from the
>> FAQ is deprecated in Shark2.0. Previously it was one of shark's internal
>> components. In Shark 2.0 we changed the logic, and provided an interface
>> to get the information about limits for activities and processes.
>>
>> About the best practice...it depends on the use-case :-)
>>
>> Regards,
>> Sasa.
>>
>> Sterba wrote:
>>    
>>> I am about to implement Time-checking functionality into my application,
>>> and
>>> it seems that Shark offers me two options: Limits and Deadlines.
>>>
>>> My question is, when to use which one of them and what is the best
>>> practice
>>> to implement them? Which one approach to use if it is needed to reassign
>>> Activity to another user in case of timeout?
>>>
>>> This is what I have learned so far and may be this will help other users
>>> to
>>> orient themselves in this topic:
>>> Limits
>>> 1. Defined in XPDL for both ProcessDefinitions and Activities in Duration
>>> units (List: Days, mins, secs...)
>>> 2. Checking for Limits is responsibility of the client program (manual,
>>> or
>>> some kind of SchedulerThread) -
>>> org.enhydra.shark.client.utilities.LimitChecker
>>> 3. The desired action when Limit is reached is not defined in XPDL. Its
>>> implementation depends fully on the client program
>>>
>>> Deadlines
>>> 1. Defined in XPDL Activities as Deadline condition using java.util.Date
>>> in
>>> its script
>>> 2. Checking for Deadlines is responsibility of the client program as well
>>> (manual, or some kind of SchedulerThread -CORBA can do this
>>> automatically)
>>> org.enhydra.shark.client.utilities.DeadlineChecker as seen in SharkAdmin
>>> application
>>> 3. The desired action when Deadline is reached is defined in XPDL as
>>> Exception Transaction leading to defined Activity. Its implementation is
>>> defined in XPDL as well.
>>> 4. Allowing Synchronous and Asynchronous execution - If it is
>>> asynchronous
>>> deadline, the user's activity won't be terminated, and if it is
>>> synchronous
>>> one, it will be terminated.
>>>
>>> Conclusion: Limits are good for simple tasks: Notifying responsible
>>> participant when limit is reached, or closing ProcessInstance if nobody
>>> is
>>> working on it for long time, ...
>>> Deadlines are good for complex tasks, fully defined in XPDL: Time limit
>>> is
>>> in any way affecting or changing the process flow...
>>>
>>> If I am mistaking, please let me know... thx
>>>
>>> BTW documentation FAQ says something about LimitAgent interface, but it
>>> seems not to exist in current release...
>>>
>>>  
>>>      
>>
>> --
>> You receive this message as a subscriber of the shark@... mailing
>> list.
>> To unsubscribe: mailto:shark-unsubscribe@...
>> For general help: mailto:sympa@...?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>>
>>    
>
>  

--
You receive this message as a subscriber of the shark@... mailing list.
To unsubscribe: mailto:shark-unsubscribe@...
For general help: mailto:sympa@...?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

[Sterba]

Hi Sasa,
Interesting problem. I know, it definitely should work, but still nothing ... no limits reached for activities.
I have written for this a simple standalone class which is attached. Please look at it. I have also tried to run it on Informix and HSQL as well, but the results are the same.
I have no more ideas to try. Code looks OK. Cud be the problem in configuration?
Thanks. Regards

p.s. when I looked to SHKACTIVITIES table in both DB`s, the column LIMITTIME contains in all test_js_basic rows only 4611686018427397903 value but in all other rows 4611686018427387903  =  Long.MAX_VALUE/2 (for other processes wthitch do not use limits)

Peter SterbaStandaloneLimitTester.java

Sasa Bojanic wrote:

Hi,

as far that I can see, it works correctly ... (of course I had to begin
and commit transaction inside the for loop).
This is the output that I get:

i: 0
2008-07-02 14:41:18,968: -----> Activity : 201_201_test_js_basic_A1 has
reached its limit
    acitvities: 1
2008-07-02 14:41:19,000: -----> Process : 201_test_js_basic has reached
its limit
2008-07-02 14:41:19,000: -----> Activity : 201_201_test_js_basic_A1 has
reached its limit
    processes: 1

Limit time for the process is exceeded 60 seconds after process has started.

The same is for the activities. E.g. limit for activity A2 will be
exceeded 10sec after activity is created (which happens immediately
after activity A1 has finished).

Greetings,
Sasa.

Sterba wrote:
> Thanks for your response Sasa!
>   Actually it seems that I haven't understood Limit checking for Activities
> correctly... Considering test_js_basic example I am not able to get any of
> reached limits for its Activities. I am fallowing these steps:
> 1. start test_js_basic Process in TWS Admin
> 2. I run my test code, which check periodically for all reached Activities
> and Process limits:
> for (int i = 0; i < 60; i++) {
> System.out.println("i: " + i);
> ExecutionAdministration execAdmin =
> Shark.getInstance().getExecutionAdministration();
> WMActivityInstance[] returned =
> execAdmin.checkLimitsWithActivityFiltering(seshandle,
> /*actFilter*/null).getArray();
> System.out.println("\tacitvities: " + returned.length);
> WMProcessInstance[] returned2 =
> execAdmin.checkLimitsWithProcessFiltering(seshandle, /*actFilter*/null,
> true).getArray();
> System.out.println("\tprocesses: "+ returned2.length);
> Thread.sleep(1000);
> }
>
> After 60 seconds I will get reached limit for the Process but never for the
> Activities. I was expecting, that after 10 seconds from process start I will
> get reached limit for A1 Activity, after another 10 seconds for A2, etc.
>
> Another confusing thing (which is in opposition with my expectations above)
> is Activities limit definition in TWE documentation (page 78), which says
> that "It is counted from the starting date/time of the Process". According
> to this all Activities in test_js_basic example have only 10 seconds to
> complete each - apparently I misunderstood something.... :confused: From
> whitch time is it counting for each Activity?
>
> Regards,
> Peter Sterba
>
>
> Sasa Bojanic wrote:
>  
>> Hi,
>>
>> you've understood everything correctly. LimitAgent interface from the
>> FAQ is deprecated in Shark2.0. Previously it was one of shark's internal
>> components. In Shark 2.0 we changed the logic, and provided an interface
>> to get the information about limits for activities and processes.
>>
>> About the best practice...it depends on the use-case :-)
>>
>> Regards,
>> Sasa.
>>
>> Sterba wrote:
>>    
>>> I am about to implement Time-checking functionality into my application,
>>> and
>>> it seems that Shark offers me two options: Limits and Deadlines.
>>>
>>> My question is, when to use which one of them and what is the best
>>> practice
>>> to implement them? Which one approach to use if it is needed to reassign
>>> Activity to another user in case of timeout?
>>>
>>> This is what I have learned so far and may be this will help other users
>>> to
>>> orient themselves in this topic:
>>> Limits
>>> 1. Defined in XPDL for both ProcessDefinitions and Activities in Duration
>>> units (List: Days, mins, secs...)
>>> 2. Checking for Limits is responsibility of the client program (manual,
>>> or
>>> some kind of SchedulerThread) -
>>> org.enhydra.shark.client.utilities.LimitChecker
>>> 3. The desired action when Limit is reached is not defined in XPDL. Its
>>> implementation depends fully on the client program
>>>
>>> Deadlines
>>> 1. Defined in XPDL Activities as Deadline condition using java.util.Date
>>> in
>>> its script
>>> 2. Checking for Deadlines is responsibility of the client program as well
>>> (manual, or some kind of SchedulerThread -CORBA can do this
>>> automatically)
>>> org.enhydra.shark.client.utilities.DeadlineChecker as seen in SharkAdmin
>>> application
>>> 3. The desired action when Deadline is reached is defined in XPDL as
>>> Exception Transaction leading to defined Activity. Its implementation is
>>> defined in XPDL as well.
>>> 4. Allowing Synchronous and Asynchronous execution - If it is
>>> asynchronous
>>> deadline, the user's activity won't be terminated, and if it is
>>> synchronous
>>> one, it will be terminated.
>>>
>>> Conclusion: Limits are good for simple tasks: Notifying responsible
>>> participant when limit is reached, or closing ProcessInstance if nobody
>>> is
>>> working on it for long time, ...
>>> Deadlines are good for complex tasks, fully defined in XPDL: Time limit
>>> is
>>> in any way affecting or changing the process flow...
>>>
>>> If I am mistaking, please let me know... thx
>>>
>>> BTW documentation FAQ says something about LimitAgent interface, but it
>>> seems not to exist in current release...
>>>
>>>  
>>>      
>>
>> --
>> You receive this message as a subscriber of the [e-mail] mailing
>> list.
>> To unsubscribe: mailto:[e-mail]
>> For general help: mailto:[e-mail]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>>
>>    
>
>  



--
You receive this message as a subscriber of the [e-mail] mailing list.
To unsubscribe: mailto:[e-mail]
For general help: mailto:[e-mail]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

[Sasa Bojanic]

Hi,

I just realized there was a bug-fix after version 2.1-1 related to the
limits...and I'm using our internal version for testing :-)

Sorry...if you update from CVS, you will have the version where the
problem is fixed.

Regards,
Sasa.


Sterba wrote:

> Hi Sasa,
> Interesting problem. I know, it definitely should work, but still nothing
> ... no limits reached for activities.
> I have written for this a simple standalone class which is attached. Please
> look at it. I have also tried to run it on Informix and HSQL as well, but
> the results are the same.
> I have no more ideas to try. Code looks OK. Cud be the problem in
> configuration?
> Thanks. Regards
>
> p.s. when I looked to SHKACTIVITIES table in both DB`s, the column LIMITTIME
> contains in all test_js_basic rows only 4611686018427397903 value but in all
> other rows 4611686018427387903  =  Long.MAX_VALUE/2 (for other processes
> wthitch do not use limits)
>
> Peter Sterba http://www.nabble.com/file/p18253503/StandaloneLimitTester.java
> StandaloneLimitTester.java
>
>
> Sasa Bojanic wrote:
>  
>> Hi,
>>
>> as far that I can see, it works correctly ... (of course I had to begin
>> and commit transaction inside the for loop).
>> This is the output that I get:
>>
>> i: 0
>> 2008-07-02 14:41:18,968: -----> Activity : 201_201_test_js_basic_A1 has
>> reached its limit
>>     acitvities: 1
>> 2008-07-02 14:41:19,000: -----> Process : 201_test_js_basic has reached
>> its limit
>> 2008-07-02 14:41:19,000: -----> Activity : 201_201_test_js_basic_A1 has
>> reached its limit
>>     processes: 1
>>
>> Limit time for the process is exceeded 60 seconds after process has
>> started.
>>
>> The same is for the activities. E.g. limit for activity A2 will be
>> exceeded 10sec after activity is created (which happens immediately
>> after activity A1 has finished).
>>
>> Greetings,
>> Sasa.
>>
>> Sterba wrote:
>>    
>>> Thanks for your response Sasa!
>>>   Actually it seems that I haven't understood Limit checking for
>>> Activities
>>> correctly... Considering test_js_basic example I am not able to get any
>>> of
>>> reached limits for its Activities. I am fallowing these steps:
>>> 1. start test_js_basic Process in TWS Admin
>>> 2. I run my test code, which check periodically for all reached
>>> Activities
>>> and Process limits:
>>> for (int i = 0; i < 60; i++) {
>>> System.out.println("i: " + i);
>>> ExecutionAdministration execAdmin =
>>> Shark.getInstance().getExecutionAdministration();
>>> WMActivityInstance[] returned =
>>> execAdmin.checkLimitsWithActivityFiltering(seshandle,
>>> /*actFilter*/null).getArray();
>>> System.out.println("\tacitvities: " + returned.length);
>>> WMProcessInstance[] returned2 =
>>> execAdmin.checkLimitsWithProcessFiltering(seshandle, /*actFilter*/null,
>>> true).getArray();
>>> System.out.println("\tprocesses: "+ returned2.length);
>>> Thread.sleep(1000);
>>> }
>>>
>>> After 60 seconds I will get reached limit for the Process but never for
>>> the
>>> Activities. I was expecting, that after 10 seconds from process start I
>>> will
>>> get reached limit for A1 Activity, after another 10 seconds for A2, etc.
>>>
>>> Another confusing thing (which is in opposition with my expectations
>>> above)
>>> is Activities limit definition in TWE documentation (page 78), which says
>>> that "It is counted from the starting date/time of the Process".
>>> According
>>> to this all Activities in test_js_basic example have only 10 seconds to
>>> complete each - apparently I misunderstood something.... :confused: From
>>> whitch time is it counting for each Activity?
>>>
>>> Regards,
>>> Peter Sterba
>>>
>>>
>>> Sasa Bojanic wrote:
>>>  
>>>      
>>>> Hi,
>>>>
>>>> you've understood everything correctly. LimitAgent interface from the
>>>> FAQ is deprecated in Shark2.0. Previously it was one of shark's internal
>>>> components. In Shark 2.0 we changed the logic, and provided an interface
>>>> to get the information about limits for activities and processes.
>>>>
>>>> About the best practice...it depends on the use-case :-)
>>>>
>>>> Regards,
>>>> Sasa.
>>>>
>>>> Sterba wrote:
>>>>    
>>>>        
>>>>> I am about to implement Time-checking functionality into my
>>>>> application,
>>>>> and
>>>>> it seems that Shark offers me two options: Limits and Deadlines.
>>>>>
>>>>> My question is, when to use which one of them and what is the best
>>>>> practice
>>>>> to implement them? Which one approach to use if it is needed to
>>>>> reassign
>>>>> Activity to another user in case of timeout?
>>>>>
>>>>> This is what I have learned so far and may be this will help other
>>>>> users
>>>>> to
>>>>> orient themselves in this topic:
>>>>> Limits
>>>>> 1. Defined in XPDL for both ProcessDefinitions and Activities in
>>>>> Duration
>>>>> units (List: Days, mins, secs...)
>>>>> 2. Checking for Limits is responsibility of the client program (manual,
>>>>> or
>>>>> some kind of SchedulerThread) -
>>>>> org.enhydra.shark.client.utilities.LimitChecker
>>>>> 3. The desired action when Limit is reached is not defined in XPDL. Its
>>>>> implementation depends fully on the client program
>>>>>
>>>>> Deadlines
>>>>> 1. Defined in XPDL Activities as Deadline condition using
>>>>> java.util.Date
>>>>> in
>>>>> its script
>>>>> 2. Checking for Deadlines is responsibility of the client program as
>>>>> well
>>>>> (manual, or some kind of SchedulerThread -CORBA can do this
>>>>> automatically)
>>>>> org.enhydra.shark.client.utilities.DeadlineChecker as seen in
>>>>> SharkAdmin
>>>>> application
>>>>> 3. The desired action when Deadline is reached is defined in XPDL as
>>>>> Exception Transaction leading to defined Activity. Its implementation
>>>>> is
>>>>> defined in XPDL as well.
>>>>> 4. Allowing Synchronous and Asynchronous execution - If it is
>>>>> asynchronous
>>>>> deadline, the user's activity won't be terminated, and if it is
>>>>> synchronous
>>>>> one, it will be terminated.
>>>>>
>>>>> Conclusion: Limits are good for simple tasks: Notifying responsible
>>>>> participant when limit is reached, or closing ProcessInstance if nobody
>>>>> is
>>>>> working on it for long time, ...
>>>>> Deadlines are good for complex tasks, fully defined in XPDL: Time limit
>>>>> is
>>>>> in any way affecting or changing the process flow...
>>>>>
>>>>> If I am mistaking, please let me know... thx
>>>>>
>>>>> BTW documentation FAQ says something about LimitAgent interface, but it
>>>>> seems not to exist in current release...
>>>>>
>>>>>  
>>>>>      
>>>>>          
>>>> --
>>>> You receive this message as a subscriber of the shark@... mailing
>>>> list.
>>>> To unsubscribe: mailto:shark-unsubscribe@...
>>>> For general help: mailto:sympa@...?subject=help
>>>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>>>
>>>>
>>>>    
>>>>        
>>>  
>>>      
>>
>> --
>> You receive this message as a subscriber of the shark@... mailing
>> list.
>> To unsubscribe: mailto:shark-unsubscribe@...
>> For general help: mailto:sympa@...?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>>
>>    
>
>  

--
You receive this message as a subscriber of the shark@... mailing list.
To unsubscribe: mailto:shark-unsubscribe@...
For general help: mailto:sympa@...?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

[Sterba]

Thank you, I am on it

Sasa Bojanic wrote:

Hi,

I just realized there was a bug-fix after version 2.1-1 related to the
limits...and I'm using our internal version for testing :-)

Sorry...if you update from CVS, you will have the version where the
problem is fixed.

Regards,
Sasa.


Sterba wrote:
> Hi Sasa,
> Interesting problem. I know, it definitely should work, but still nothing
> ... no limits reached for activities.
> I have written for this a simple standalone class which is attached. Please
> look at it. I have also tried to run it on Informix and HSQL as well, but
> the results are the same.
> I have no more ideas to try. Code looks OK. Cud be the problem in
> configuration?
> Thanks. Regards
>
> p.s. when I looked to SHKACTIVITIES table in both DB`s, the column LIMITTIME
> contains in all test_js_basic rows only 4611686018427397903 value but in all
> other rows 4611686018427387903  =  Long.MAX_VALUE/2 (for other processes
> wthitch do not use limits)
>
> Peter Sterba http://www.nabble.com/file/p18253503/StandaloneLimitTester.java
> StandaloneLimitTester.java
>
>
> Sasa Bojanic wrote:
>  
>> Hi,
>>
>> as far that I can see, it works correctly ... (of course I had to begin
>> and commit transaction inside the for loop).
>> This is the output that I get:
>>
>> i: 0
>> 2008-07-02 14:41:18,968: -----> Activity : 201_201_test_js_basic_A1 has
>> reached its limit
>>     acitvities: 1
>> 2008-07-02 14:41:19,000: -----> Process : 201_test_js_basic has reached
>> its limit
>> 2008-07-02 14:41:19,000: -----> Activity : 201_201_test_js_basic_A1 has
>> reached its limit
>>     processes: 1
>>
>> Limit time for the process is exceeded 60 seconds after process has
>> started.
>>
>> The same is for the activities. E.g. limit for activity A2 will be
>> exceeded 10sec after activity is created (which happens immediately
>> after activity A1 has finished).
>>
>> Greetings,
>> Sasa.
>>
>> Sterba wrote:
>>    
>>> Thanks for your response Sasa!
>>>   Actually it seems that I haven't understood Limit checking for
>>> Activities
>>> correctly... Considering test_js_basic example I am not able to get any
>>> of
>>> reached limits for its Activities. I am fallowing these steps:
>>> 1. start test_js_basic Process in TWS Admin
>>> 2. I run my test code, which check periodically for all reached
>>> Activities
>>> and Process limits:
>>> for (int i = 0; i < 60; i++) {
>>> System.out.println("i: " + i);
>>> ExecutionAdministration execAdmin =
>>> Shark.getInstance().getExecutionAdministration();
>>> WMActivityInstance[] returned =
>>> execAdmin.checkLimitsWithActivityFiltering(seshandle,
>>> /*actFilter*/null).getArray();
>>> System.out.println("\tacitvities: " + returned.length);
>>> WMProcessInstance[] returned2 =
>>> execAdmin.checkLimitsWithProcessFiltering(seshandle, /*actFilter*/null,
>>> true).getArray();
>>> System.out.println("\tprocesses: "+ returned2.length);
>>> Thread.sleep(1000);
>>> }
>>>
>>> After 60 seconds I will get reached limit for the Process but never for
>>> the
>>> Activities. I was expecting, that after 10 seconds from process start I
>>> will
>>> get reached limit for A1 Activity, after another 10 seconds for A2, etc.
>>>
>>> Another confusing thing (which is in opposition with my expectations
>>> above)
>>> is Activities limit definition in TWE documentation (page 78), which says
>>> that "It is counted from the starting date/time of the Process".
>>> According
>>> to this all Activities in test_js_basic example have only 10 seconds to
>>> complete each - apparently I misunderstood something.... :confused: From
>>> whitch time is it counting for each Activity?
>>>
>>> Regards,
>>> Peter Sterba
>>>
>>>
>>> Sasa Bojanic wrote:
>>>  
>>>      
>>>> Hi,
>>>>
>>>> you've understood everything correctly. LimitAgent interface from the
>>>> FAQ is deprecated in Shark2.0. Previously it was one of shark's internal
>>>> components. In Shark 2.0 we changed the logic, and provided an interface
>>>> to get the information about limits for activities and processes.
>>>>
>>>> About the best practice...it depends on the use-case :-)
>>>>
>>>> Regards,
>>>> Sasa.
>>>>
>>>> Sterba wrote:
>>>>    
>>>>        
>>>>> I am about to implement Time-checking functionality into my
>>>>> application,
>>>>> and
>>>>> it seems that Shark offers me two options: Limits and Deadlines.
>>>>>
>>>>> My question is, when to use which one of them and what is the best
>>>>> practice
>>>>> to implement them? Which one approach to use if it is needed to
>>>>> reassign
>>>>> Activity to another user in case of timeout?
>>>>>
>>>>> This is what I have learned so far and may be this will help other
>>>>> users
>>>>> to
>>>>> orient themselves in this topic:
>>>>> Limits
>>>>> 1. Defined in XPDL for both ProcessDefinitions and Activities in
>>>>> Duration
>>>>> units (List: Days, mins, secs...)
>>>>> 2. Checking for Limits is responsibility of the client program (manual,
>>>>> or
>>>>> some kind of SchedulerThread) -
>>>>> org.enhydra.shark.client.utilities.LimitChecker
>>>>> 3. The desired action when Limit is reached is not defined in XPDL. Its
>>>>> implementation depends fully on the client program
>>>>>
>>>>> Deadlines
>>>>> 1. Defined in XPDL Activities as Deadline condition using
>>>>> java.util.Date
>>>>> in
>>>>> its script
>>>>> 2. Checking for Deadlines is responsibility of the client program as
>>>>> well
>>>>> (manual, or some kind of SchedulerThread -CORBA can do this
>>>>> automatically)
>>>>> org.enhydra.shark.client.utilities.DeadlineChecker as seen in
>>>>> SharkAdmin
>>>>> application
>>>>> 3. The desired action when Deadline is reached is defined in XPDL as
>>>>> Exception Transaction leading to defined Activity. Its implementation
>>>>> is
>>>>> defined in XPDL as well.
>>>>> 4. Allowing Synchronous and Asynchronous execution - If it is
>>>>> asynchronous
>>>>> deadline, the user's activity won't be terminated, and if it is
>>>>> synchronous
>>>>> one, it will be terminated.
>>>>>
>>>>> Conclusion: Limits are good for simple tasks: Notifying responsible
>>>>> participant when limit is reached, or closing ProcessInstance if nobody
>>>>> is
>>>>> working on it for long time, ...
>>>>> Deadlines are good for complex tasks, fully defined in XPDL: Time limit
>>>>> is
>>>>> in any way affecting or changing the process flow...
>>>>>
>>>>> If I am mistaking, please let me know... thx
>>>>>
>>>>> BTW documentation FAQ says something about LimitAgent interface, but it
>>>>> seems not to exist in current release...
>>>>>
>>>>>  
>>>>>      
>>>>>          
>>>> --
>>>> You receive this message as a subscriber of the [e-mail] mailing
>>>> list.
>>>> To unsubscribe: mailto:[e-mail]
>>>> For general help: mailto:[e-mail]?subject=help
>>>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>>>
>>>>
>>>>    
>>>>        
>>>  
>>>      
>>
>> --
>> You receive this message as a subscriber of the [e-mail] mailing
>> list.
>> To unsubscribe: mailto:[e-mail]
>> For general help: mailto:[e-mail]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>>
>>    
>
>  



--
You receive this message as a subscriber of the [e-mail] mailing list.
To unsubscribe: mailto:[e-mail]
For general help: mailto:[e-mail]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

[Sterba]

Now, when Limit checking works in Shark 2.2.1 I am back with stumbling uppon this topic :)
How can I get the actual limit as Date value when the limit for activity or process will be reached?

Well I can parse XPDL for limit and for TimeUnit values and compute it by my self using ACTIVITY(PROCESS)_STERTED_TIME, but why when desired value is already in Sharks table column 'limittime'...

Is there any other, more direct way, how to get these value as Date?

Thanks for answer,

Peter

Sterba wrote:

I am about to implement Time-checking functionality into my application, and it seems that Shark offers me two options: Limits and Deadlines.

My question is, when to use which one of them and what is the best practice to implement them? Which one approach to use if it is needed to reassign Activity to another user in case of timeout?

This is what I have learned so far and may be this will help other users to orient themselves in this topic:
Limits
1. Defined in XPDL for both ProcessDefinitions and Activities in Duration units (List: Days, mins, secs...)
2. Checking for Limits is responsibility of the client program (manual, or some kind of SchedulerThread) - org.enhydra.shark.client.utilities.LimitChecker
3. The desired action when Limit is reached is not defined in XPDL. Its implementation depends fully on the client program

Deadlines
1. Defined in XPDL Activities as Deadline condition using java.util.Date in its script
2. Checking for Deadlines is responsibility of the client program as well (manual, or some kind of SchedulerThread -CORBA can do this automatically) org.enhydra.shark.client.utilities.DeadlineChecker as seen in SharkAdmin application
3. The desired action when Deadline is reached is defined in XPDL as Exception Transaction leading to defined Activity. Its implementation is defined in XPDL as well.
4. Allowing Synchronous and Asynchronous execution - If it is asynchronous deadline, the user's activity won't be terminated, and if it is synchronous one, it will be terminated.

Conclusion: Limits are good for simple tasks: Notifying responsible participant when limit is reached, or closing ProcessInstance if nobody is working on it for long time, ...
Deadlines are good for complex tasks, fully defined in XPDL: Time limit is in any way affecting or changing the process flow...

If I am mistaking, please let me know... thx

BTW documentation FAQ says something about LimitAgent interface, but it seems not to exist in current release...

[Sasa Bojanic]

Hi,

there is no shark API to get the limit time for the activity, but there
is an API to get the activities/processes where limit time is already
exceeded (look at the ExecutionAdmin API and search for checkLimitsXXX
methods).

Greetings,
Sasa.

Sterba wrote:

> Now, when Limit checking works in Shark 2.2.1 I am back with stumbling uppon
> this topic :)
> How can I get the actual limit as Date value when the limit for activity or
> process will be reached?
>
> Well I can parse XPDL for limit and for TimeUnit values and compute it by my
> self using ACTIVITY(PROCESS)_STERTED_TIME, but why when desired value is
> already in Sharks table column 'limittime'...
>
> Is there any other, more direct way, how to get these value as Date?
>
> Thanks for answer,
>
> Peter
>
>
> Sterba wrote:
>  
>> I am about to implement Time-checking functionality into my application,
>> and it seems that Shark offers me two options: Limits and Deadlines.
>>
>> My question is, when to use which one of them and what is the best
>> practice to implement them? Which one approach to use if it is needed to
>> reassign Activity to another user in case of timeout?
>>
>> This is what I have learned so far and may be this will help other users
>> to orient themselves in this topic:
>> Limits
>> 1. Defined in XPDL for both ProcessDefinitions and Activities in Duration
>> units (List: Days, mins, secs...)
>> 2. Checking for Limits is responsibility of the client program (manual, or
>> some kind of SchedulerThread) -
>> org.enhydra.shark.client.utilities.LimitChecker
>> 3. The desired action when Limit is reached is not defined in XPDL. Its
>> implementation depends fully on the client program
>>
>> Deadlines
>> 1. Defined in XPDL Activities as Deadline condition using java.util.Date
>> in its script
>> 2. Checking for Deadlines is responsibility of the client program as well
>> (manual, or some kind of SchedulerThread -CORBA can do this automatically)
>> org.enhydra.shark.client.utilities.DeadlineChecker as seen in SharkAdmin
>> application
>> 3. The desired action when Deadline is reached is defined in XPDL as
>> Exception Transaction leading to defined Activity. Its implementation is
>> defined in XPDL as well.
>> 4. Allowing Synchronous and Asynchronous execution - If it is asynchronous
>> deadline, the user's activity won't be terminated, and if it is
>> synchronous one, it will be terminated.
>>
>> Conclusion: Limits are good for simple tasks: Notifying responsible
>> participant when limit is reached, or closing ProcessInstance if nobody is
>> working on it for long time, ...
>> Deadlines are good for complex tasks, fully defined in XPDL: Time limit is
>> in any way affecting or changing the process flow...
>>
>> If I am mistaking, please let me know... thx
>>
>> BTW documentation FAQ says something about LimitAgent interface, but it
>> seems not to exist in current release...
>>
>>
>>    
>
>  

--
You receive this message as a subscriber of the shark@... mailing list.
To unsubscribe: mailto:shark-unsubscribe@...
For general help: mailto:sympa@...?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws