Public Queue Delivery Task status

, ,
1

Public Queue Delivery Task status
The status of a task is DELIVERING, when the task is pulled by getQueuedTask service.
I dont see the task status again changing to QUEUED or any other value when i am not updating the task with status success. Reliable Delivery settings are not having any effect either…
Am interested in knowing when the status DELIVERING will become QUEUED again.

Thanks
DG

2

You must always update the task after using getQueuedTask. Set the status to success and the task will show DONE. Set the status to fail and the task will show FAILED if the task has reached is retry limit, or will be QUEUED if not. Place your processing within a try/catch construct to ensure that you always call updateQueuedTask.

3

Thanks Rob,
In my Tasks details for a QUEUED/DELIVERING document, I see the retry limit and number of retries as zero. But in Tools/Server Setup/Tasks, I find Maximum retries set as 5.
My understanding is, public queue by default is ‘reliable delivery’ and it picks the retry limit and no of retries from Tools/Server Setup/Tasks. This queue is not configure to ‘run once’.

On a differnt note, Apparently the status got changed to QUEUED from DELIVERING when Maximum retries is zero and when updateTaskStatus is not invoked. Am doing a post mortem which caused duplication of our transmissions in VAN box

Thanks
DG

4

Hi DG,

Just wondering what you’ve found out from your post mortem on the duplication at the VAN box ? We had a similar scenario where TN registers on occurrence of the document and yet it showed up multiple times at the VAN. This only occurs when the VAN is down.

Our queue and retries setup is the same as your above post.

Thanks
Mary

5

I have a similar problem. I realize this is an old topic, but will see if anyone now has an answer. In tn properties i have the following setting tn.task.maxRetries = 10. For service execution tasks, the retry cound shows up correctly. 10 tries then it fails. However for a scheduled delivery queue, it show retries = 0. The result is that the task tries to send once. The send fails, i use updateQueuedTask to set the status to fail, but since it doesn’t think there are any retries left, it stops. Is there another setting for max retries on queued tasks?

6

Hi,
Is your scheduled delivery queue set up as “Run Once”. In that case, TN will execute the delivery service 1 time even if it fails. You will need to change it to run at simple or complex intervals.

HTH,
Bhawesh.

7

Thanks for the reply!

No, it is currently setup as a simple interval running every 60 seconds.

8

Some more detail on the issue.

I am using a public queue defined as a simple interval running every 60 seconds.

I have a processing rule whose action is set to Delvier Document By Scheduled Delivery to my public queue.

The processing rule and queue seem to be working as expected. If I manually set the retry limit in the datbase DELIVERYJOB table to 100 then it runs through and retries as expected. The problem is that when the jbos is initially scheduled the rety limit is set to 0.

Here are my tn properties

tn.certDir = cert
tn.cluster.notifyCacheChange = true
tn.cluster.notifyProfileAddUser = true
tn.cluster.notifyPropertyChange = true
tn.ff.contenttypes = text/plain
tn.mail.from = tn@webmethods.com
tn.ping.compatibleWith = 6.0,6.0.1
tn.query.threshold = 50
tn.receive.clearKeys = node,bizdoc,sender,receiver,flags,ffdata,TN_Parms
tn.receive.clearTNObjects = true
tn.required.idType = DUNS
tn.task.maxRetries = 10
tn.task.notifyFailure = false
tn.task.retryFactor = 1
tn.task.sweepTime = 300
tn.task.ttw = 60
tn.webmgr.60config = true

TN about

Product webMethods for Trading Networks
Version 6.1
Build Number 705
Integration Server Version 6.1

TNS_6-1_SP1 is installed

9

What are the retries set to in the partner profile?