Product: OpenFusion Notification Service

Version: ALL

Description:

How to clean up inactive proxies?

Resolution:

Inactive proxies can be removed as follows:

1. Removing proxy push consumers and proxy pull suppliers.

The MaxInactivityInterval QoS property can be used to do this. MaxInactivityInterval is the connection timeout for push suppliers and pull consumers. It is a relative timeout value and is reset each time the proxy sucessfully recieves or delivers an event. When the proxy has been idle for the MaxInactivityInterval then the proxy is disconnected. The unit for this QoS is 100ns. If set to 0 then idle push suppliers and pull consumers will not time out. The range 1-9999 is not supported, the smallest value that can be set is 1 millisecond.

2. Removing proxy push suppliers.

a. Connection Reliability set to Best Effort.
If the ConnectionReliability QoS is set to BestEffort then the Notification Service will always destroy a proxy push supplier if the proxy fails to deliver an event to its attached consumer.

b. Connection Reliability set to Persistent.
If the ConnectionReliability is set to Persistent then when a proxy supplier attempts to deliver events to a consumer and gets an exception it will try to reconnect that consumer. The only times it will not do this are:

1) It receives a Disconnected exception

2) It receives an OBJECT_NOT_EXIST exception. The way an OBJECT_NOT_EXIST exception is handled depends on the ORB. Some ORBS throw an OBJECT_NOT_EXIST exception when the object is actually inactive. If you are using one of these ORBs the proxy will not be disconnected.

When the Notification Service is attempting to reconnect the proxy, it will do this forever unless you tell it otherwise. You can use the MaxReconnectAttempts and the ReconnectInterval QoS properties to manage this behaviour as follows:

The MaxReconnectAttempts QoS property defines the maximum number of times the Notification Service will attempt to reconnect to a failed pull supplier or push consumer. The Notification Service disconnects the client as though the disconnect operation had been invoked on the proxy when the client is still unavailable after the maximum number of attempts have been made. For example, If the MaxReconnectAttempts property is left set to its default value of 0 then the Notification Service will continue to try and send the event to its consumer, no matter how many times it fails. If the MaxReconnectAttempts property is set to some other value, then the Notification Service will only try to deliver an event to the consumer MaxReconnectAttempts number of times before destroying the proxy.

The ReconnectInterval QoS defines the amount of time that the Notification Service will wait before retrying persistent pull suppliers and push consumers that are unavailable. The unit for this QoS is 100 nanoseconds and the default value is 1 second. A value in the range 1 -9999 is not supported.

Theoretically, the absolute timeout value for pull suppliers and push consumers is the product of the MaxReconnectAttempts property value and the ReconnectInterval property value. However, the actual time taken for the entire timeout period can take longer than the absolute timeout value. This is explained below:

The ReconnectInterval property is the interval of time the Notification Service will wait before making another connection attempt. This interval is measured from the time that it becomes aware that a connection attempt failed e.g. by receiving an exception from the ORB.

The absolute timeout value cannot account for the length of time taken from when a client disconnection occurs until the time that the Notification Service becomes aware of the disconnection. Normally, this is not an issue, but under certain circumstances such as when the orb daemon is not running on particular ORBs, the affect of this delay can be significant.

For example, if an ORB takes 20 seconds to pass an exception indicating client disconnection, then the ReconnectInterval will effectively be increased by 20 seconds. Assuming that the ReconnectInterval is set to 1 second and the number MaxReconnectAttempts is set to 120, then the actual absolute timeout will be 120 x (20 1) = 2520 seconds = 42 minutes, instead of the expected 120 seconds =2 minutes.

The proxies will only be disconnected if there are events in the channel when the consumer disconnects. The Notification Service will only receive the exception notifying it that the consumer is not available if it is trying to send it an event.