I am trying to build a resource monitoring service that monitors the db connection status and returns the isAvailable based on it.(Connection Not available - false ; Connection available - true)
I have configured the trigger to handle Transient Error Handling with retry failure as Suspend and retry later option.
I have also configured the retry intervals and max retry attempts.
The throwForRetry is also present in the catch block for the service that gets invoked by the trigger.
I have also used a debugLog statement containing the number of retries to write in server log.
But when the trigger executes the service, the retry mechanism is not happening. As per the info in publish and subscribe guide,the triggers gets disabled when the max attempts are reached.
In my case, on seeing server logs, the retry count is set to ‘0’ and its not getting incremented.
Ideally the retry should have happened for every retry interval and it should have got incremented till ‘3’ and trigger must have been suspended.
But nothing happened.
Something else needs to be set or configured like some extended settings??
Another doubt is can a resource monitoring service be built in such a way that it monitors many connections or only one resource monitoring service per connection.
I was wondering if there would be some way to achieve this.
Suppose if i have to monitor 2 connection, should i build 2 trigger and 2 resource monitoring service.
If some information could be extracted from the document that trigger subscribes, it can be built in a generic way.
For example, if doc X is subscribed by trigger, that doc X contains some field A containing connection details. If A can be extracted in resource monitoring service, we can build that service to check the specific connection details based on A.
I believe there is no possible way to extract information/details back from the trigger, If I understood you question clearly…All you will have is trigger can handle document conditions and based on it can drive the subscription service.
The resource monitoring i did was to monitor a DB connection in a IS which is working fine
I want to do a web service call to another system. So this resource monitoring service should monitor that system.
Should i use a ping command to monitor the system. But again,I guess if i use the ping command and if the system is running and up but the port to which this web service call is made is not listening, I could get positive response which is wrong in this case.
So what should be ideally used to check that actual service in the system is up?? May be a telnet??
I would say just use the http ping command on that host:port and you should get in response timely manner otherwise some thing wrong going on the server either slow or hung case:
How are you guys handling infinite retry situation. For example, the database is down for an entire week. In this case, they do not want webMethods to queue the broker documents.
Any suggestions?
Also, How are you throwing the exception as transient in the catch block? I think we need to write a custom code based on the error codes. Please let me know if there is any best way to do it.
IF the DB is down for a extended period of time (weeks and not a Day or so) you have no choice for retrying unless you have some other ways of source data is save in TN or queued on the Broker side.
Thank you for the response. I’m just thinking of a situation where a target database eg: A is down for 7 days and rest of the targets eg: B,C, D so on are fine on the IS. Due to the infinite retry during the 7 day period for the target A, the server might come to unresponsive state. What should we do in this scenario?
Can we simply delete the broker documents from the broker? or just want to know how to handle this kind of situation. I’m not worried about resubmission at this point, i am worried about IS being unresponsive due to this situation in Production.
When you have 4 (eg. A, B, C & D) independent backend databases to update based on one broker/publishable document. In that case, ideally you should have four independent subscriber services with individual triggers. Then Broker will place the same document on all the four client queues. If one of your backend (eg. A) is unavailable for extended period of time then disable the subscription as well as processing state of particular trigger corresponding to that subscriber service A on IS. It will queue up the documents in client queue on the Broker side.
Note - Don’t delete the documents - because if the documents are guaranteed documents then you will not be able to restore them back. Based on the document “live time” property settings - these may also go to dead letter queue.
Yes as described above its the safe way of handling the pub/sub triggers and so that the docs get queued for the extended period of time and support for the reprocessing way.
Thanks and I agree with your points. But do you think if a database is down for 3-4 days and all broker documents gets queued up. Do you think there will be any memory issues.
The service is retried for 3 times siuccessfully and logs are wrriten.
But Trigger needs to be suspended for the above condition but it is enabled.
Kindly help us on this regard.
Note: Resource Monitoring service is set in the trigger (isAvailable = True/False). But Resource monitoring also not invoked here.
