- This topic has 6 replies, 3 voices, and was last updated 13 years, 10 months ago by
.
-
Topic
-
I’m trying to set up an alert in Cloverleaf that will alert me if messages stop moving on a thread. For instance if an outbound thread to an outside vendor stops sending data to them because the vendors’s interface has gone down. It looks to me like I might want to use the Outbound Latency alert, but for the life of me I cannot find any detailed information on what the Outbound Latency settings mean. Or maybe I should use an Outbound Queue Depth alert, but it seems to me that that alert could be non-helpful is for some reason Cloverleaf had a flood of messages and the alert polled right at that moment. So, basically I am looking for an alert to check if any messages have been in the thread for more than 5 minutes, and I think that would be the Outbound Latency alert. Anyway, some help on how to configure it would be greatly appreciated. Thanks.
-
Replies
-
-
-
Are you referring to a set up similar to the image in the attached file? Cause this would say to me that I would only get alerted when any of the queues listed had over fifty messages waiting for five minutes. However, this doesn’t take into account the possibility that I only have twenty waiting to send for two days. It also doesn’t account for a large volume going to the vendor that are being processes, but may take more than five minutes to finish. Maybe I understand the Outbound Queue Depth wrong.
I’m trying to find out if any one message has been waiting for five or more minutes to process, not how many messages have been sitting in queue for a specified time. I think I could reasonably say that if any one message has been sitting in queue for five-ten minutes that my vendor’s side is down. That is why I was looking at the Outbound Latency alert, cause that looks like what I am wanting.
Maybe I’m wrong here, but I cannot find any great documentation on what the different alerts do and what the configuration options for them represent.
-
What do you mean by “stuck”? I am presuming you mean that the thread is in an UP status, that you had sent the message, and that you have not received an ACK back from that message. We look at the last read time and if it is greater than a desginated amount, we trigger an alert. Because of the possibility that no message has been sent for a while, hence no ACK has returned, the alert triggers a TCL script which compares the last read vs. the last write. If the last read is older than the last write, we presume no ACK has returned and take action.
-
I don’t believe I used the word “stuck”. What I am trying to do is have an alert that will tell me on my outbound messages if my vendors have their interfaces turned off. I would know this is my outbound thread starts building up messages and they don’t send within a few minutes. I think I could safely say that if we have a message that has sat in the outbound queue for 5 minutes then my vendor has stopped receiving messages. I think that is the purpose of the outbound latency alert, but I cannot find any information about how to configure the latency alert.
Maybe that is not the right alert type to use. Maybe I should be looking at another alert type, but honestly I can’t find ANY good documentation on how each of the different alert types work.
-
According to the User Guide for 5.4.1, Alerts section Outbound Latency is written as this:
“Specifies the outbound message latency for the specified threads.
This is the elapsed time from when an outbound message is queued for transmission to when it is successfully delivered to the destination host.”
Outbound Queue depth will work just fine if you are wanting to know if and recieving system has shut down. We have many of them.
-
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
