Hi
Our webMethods trading networks integration server has been working fine up until yesterday. We had some issues with the database server (unrelated to webMethods) and now I’m finding that when we send a document integration server is ignoring the ebxml acknowledgement being received and continuing to retry sending the document. This happens until the retry limit is reached and then a delivery failure error is received.
I’ve tried restarting the integration server and no luck.
Anyone seen this behaviour before? Our gateway has been running for 18 months and this is the first time this has occurred. We’re running v6.5
Do you see any unusual happened in the TN/IS logs before this issue popped up??
If you want there is way to control those retry/tasks setting in the Partner profile/ Delivery Methods section per partner specific…or underlying default setting in the
packages\WmTN\config\properties.cnf the settings
tn.task.maxRetries=5
tn.task.retryFactor=1
(this change applies to all partners) and reload WmTN Package.
Sorry ignore this if you are not looking to change this and want to know root cause??.
Hi
We did have a couple of processes deadlocked.
Previously I had found that integration server was a little slow at updating the document status following an acknowledgement - but it did in the end (typically withing the hour)
We have a setup where we route ebxml documents to participants via a hub. What used to happen is:
Send routing document (status sendMessage:1)
Receive ebxml Acknowledgement (typically within around 1 min)
Approx 30-60mins later the routing document would get update to sendMessage:ack
However we’re finding that the routing document is never getting updated to sendMessage:ack so the document is resent (and we receive another subsequent) and so on until our retries (3) is hit and then we receive either a timetolive or delivery failure error.
It’s almost like the process that updates the routing document delivery task is not firing?
Do you know if I can increase the time between it’s ‘checks’ ie the check to see if an ack has been received?
There doesn’t appear to be any errors in the logs relating to this.
In addition to the above - it does now look like we are getting errors:
2008-12-18 07:04:14 EST wm.ip.ebxml.trp:simpleDelivery com.wm.app.b2b.server.ServiceException: com.wm.net.NetException: [ISC.0064.9324] Server Error: OK
Do you know if I can increase the time between it’s ‘checks’ ie the check to see if an ack has been received" Via custom code:
You can handle the checks by checking task status(Pending,Error,Done) making use of Task services and set some repeat intervals incombination with tn.task.sweepTime (until the Task is Complete) and you should also clearly know the span that ack being returned incase of error conditions/delivery of the original request etc…