nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Dummytask timeout stuck

System

I have a dummytask to wait for 1 minute in one of my workflows. Occasionally the job will wait about a minute, then proceed. But on other occasions, the dummytask will get stuck for much longer than a minute, sometimes several minutes before it continues on. WTF? Seems like such a simple concept. Has this happened to anyone else?

Solaris
TS 6.7.1
No service pack.

[HTML]

[/HTML]

Find more posts tagged with

Comments

moonkhanna

671 Windows

We have been using Dummy Tasks in most of our Wfs. No issues reported so far

nipper

Hey L-User

We use dummytasks for a delay. I have never really checked to the minute that something goes (my timeouts are to delay deployment to prod until Thursday, etc).

2 questions, first are they hardcoded to 1 minute or is it a value calculated by Perl in the template script section ? Second, how is the load on the machine ? I am not certain what process would be doing this but could there be such a load n iwserver that it cannot get to the work ?

Migrateduser

I was hoping the IW Master would respond and put me in my place.

The 1 minutes is hard coded. I am thinking you're probably right about the system load. Sucks that it has to be inconsistent like that. I don't think the server is so taxed that it would take TS several minutes to figure out a minute has passed since a WF task started. But what do I know? Don't answer that...

We coded our own delay for stuff that we want delayed for hours or days based on user input. Maybe I should use that process instead of IW's stupid dummytask. Our code always seems to work. I should have known better. Smiley Surprised

)

nipper

I am not certain which process is that overloaded. I have seen issues with triggers being delayed when a large import is done, so I assume it is due to the iwserver.

You should try to match the event log with a known delay and see if there was a large amount of traffic. Then call support, which is very high on your list of things you like to do.

Migrateduser

If this was a bigger issue and I actually gave a ****, I would do as you suggested. It's more of a nuisance as it is right now.

Happy to see you're still out there, though.

example.zip

Migrateduser

Hey I just scanned some of the recent posts since I haven't been here in a while. Doesn't look like WFM is catching on very well. I'm not really surprised.

moonkhanna

Hey I just scanned some of the recent posts since I haven't been here in a while. Doesn't look like WFM is catching on very well. I'm not really surprised.

Hi Dave,

Not sure why you think like that. WFM has been working for me very well. Many of our workflows have been accomplished or migrated from wft using WFM.

You may like to try the tool. Its really fun as compared to the previous Workflow Builder..and much more robust..

Since, its a different way of doing workflows, this may take some time initially but becomes pretty handy later..

Migrateduser

Fun? Seriously? OK, so you're one person who likes the tool. Anyone else?

I would be interested in hearing why you think it's more robust than developing WFT workflows. I sat through the webcast a few months ago and it seemed monumentally complex to me. As the workflow engine is designed, there's just no way to make a really useful GUI type tool to make developing workflows easy.

Based on the number of posts about WFM, it's either so simple and wonderful that no one has any problems with it, or no one is using it. Except you of course. Smiley Surprised

)

moonkhanna

Fun? Seriously? OK, so you're one person who likes the tool. Anyone else?

I would be interested in hearing why you think it's more robust than developing WFT workflows. I sat through the webcast a few months ago and it seemed monumentally complex to me. As the workflow engine is designed, there's just no way to make a really useful GUI type tool to make developing workflows easy.

Based on the number of posts about WFM, it's either so simple and wonderful that no one has any problems with it, or no one is using it. Except you of course. )

Dave, I was not commenting on your post. I understand, it is complex initially the way we have been seeing workflows however if you go through the complete tutorial, you will find, things have been well done this time as compared to the previously know WORKFLOW BUILDER.

WFTs still stay the best way out but not the quickest and simplest.

Another thing, I kind of learnt is that Workflow Modeler is no more using the Workflow Engine used by WFTs, rather its having its own separate module which coincides with the wfts after the initialisation phase of the workflow...

I am sure, many of the Developers are liking WFM by now..

Having stated the above, I have observed some bugs with the WFM, which IWOV is working on resolving...

I believe the right person to comment on wether WFM is working well or not would be someone from the IWOV who is working on collecting these analytics. From my end, yes, it is a fantastic tool though not as good as WFTs untill it stablises itself and touches your heart :-)

ISCBorisB

...if you go through the complete tutorial, you will find, things have been well done this time as compared to the previously know WORKFLOW BUILDER...

You've chosen a strange benchmark. "well done [...] compared to the [...] WORKFLOW BUILDER" is seriously tongue-in-cheek compliment.
It does not take much to be more useful than WF Builder.

Overall, WFM is a GUI/API to build (almost?) the same WF Specifications run by the same WF Engine. And yes, instantiation differs or so it seems.
Granted, it now has Client footprint and uses SOAP - WOOHOO! You also can no longer get away with bloated Event Subsystem if you use
WFM but hey... What's an extra RDB + tables with hundreds of thousand of rows between ECMS friends.

moonkhanna

You've chosen a strange benchmark. "well done [...] compared to the [...] WORKFLOW BUILDER" is seriously tongue-in-cheek compliment.
It does not take much to be more useful than WF Builder.

Overall, WFM is a GUI/API to build (almost?) the same WF Specifications run by the same WF Engine. And yes, instantiation differs or so it seems.
Granted, it now has Client footprint and uses SOAP - WOOHOO! You also can no longer get away with bloated Event Subsystem if you use
WFM but hey... What's an extra RDB + tables with hundreds of thousand of rows between ECMS friends.

Bo, Though I do not agree to the above... I would end the thread here..

Migrateduser

Why end the thread? Are you connected to Interwoven in some way? You certainly don't put up a very strong argument for your position. And you certainly don't get to decide when a thread ends.

moonkhanna

Why end the thread? Are you connected to Interwoven in some way? You certainly don't put up a very strong argument for your position. And you certainly don't get to decide when a thread ends.

Dave - I have put my point of view clearly. I am not connected to Interwoven any way currently.. I am ending the thread at my end as I am having something else more important to do currently...

You are most welcome to continue posting on the thread..

As far as your comment "You certainly don't put up a very strong argument for your position", I have made my postion clear, I have got many workflows running at my end using WFM and many others have too.. So that enables me to certify my position..

I believe, you do not have any points on your side rather than a vague statement- "Hey I just scanned some of the recent posts since I haven't been here in a while. Doesn't look like WFM is catching on very well. I'm not really surprised."

Please note, my intention was not to go against your statement, but just to bring things into your notice, that things are going good for WFM at many implementations..

Migrateduser

If you define many as one, then that's a brilliant argument! Well done.

moonkhanna

If you define many as one, then that's a brilliant argument! Well done.

We will come to know with the new thread I just initiated.

Migrateduser

Hey I thought you were leaving my thread. Make up your mind...

Untitled.png

Migrateduser

For what it's worth, because the original problem this thread was written about keeps happening (dummytask doesn't finish when timout should complete), we decided to write an externaltask script to replace it. Lucky for us, perl seems to work as you'd expect it to work. Can't say the same about a dummytask. Thanks, Interwoven.