The start and stop fields of a time interval are of type CORBA::ULongLong. Their values are numbers of 10-7 seconds (or 100 nanoseconds) counted from 00:00:00, Oct. 15, 1582 using Greenwich Mean Time (GMT).
Although the start and stop time unit is specified by OMG as 10-7 second, the actual time resolution supported by VisiTelcoLog is in seconds. Start and stop values specified in set_interval() will be rounded to the nearest value of full seconds by the VisiTelcoLog Service.
If the start and stop values are both set to 0 (zero), or rounded to zero seconds, the log will always be in a functional state.
To retrieve the current log duration setting, users can call the get_interval() operation on the target log.
Log scheduling allows users to set a series of fine-grained weekly time intervals (weekly masks) on a given log object. When scheduling is set up the log object will only allow writing log records or events to the log within these time intervals, if it is within a log duration (see “Log duration”), and the log is in an unlocked and enabled state.
The input parameter and return value of above methods are an IDL sequence of an IDL structure WeekMaskItem. They are defined as:
The following C++ code snippet illustrates how to use set_week_mask():
The following C++ code snippet illustrates how to use get_week_mask() and process the result:
On processing set_week_mask() requests, the log object server validates the input weekly mask parameter. Exceptions that are raised on set_week_mask() and their corresponding weekly mask setting errors are explained in the following table.
|
Case 1: Start time is later than stop time. Therefore, an interval starting at midnight and stopping after midnight is not supported. The effect of an interval that spans days should be done using two intervals: one that stops before just before midnight (23:59) and another that starts just after midnight on the next day (00:00).
Case 2: Time intervals overlap. Start or stop time of one scheduled interval is within the bounds of another scheduled interval in the same weekly mask parameter. |
On failure of set_week_mask() due to errors, the log's existing weekly mask will remain and a DsLogNotification::ProcessingErrorAlarm log event (see “Log generated events”) will be sent. On success of set_week_mask() the existing weekly mask will be completely replaced by the new weekly mask. Therefore, to completely erase an existing weekly mask, the application can invoke set_week_mask() with an empty weekly mask that is a weekly mask of length zero. A log with an empty weekly mask will accept logging during the whole week.
According to the OMG Telecom Log Service specification, event-aware Log factories and logs can generate events on log object creation and deletion, state and attribute change, threshold crossover, and processing error. A value-added extension of the VisiTelcoLog Service allows a BasicLog object to generate these events. These log generated events are called log events. Therefore, in VisiTelcoLog Service, a log factory (Basic, Event, TypedEvent, Notify, or TypedNotify factory) is a CosNotifyChannelAdmin::ConsumerAdmin.
|
Figure 3
|
The purpose of LogFactory “is a” ConsumerAdmin is to expose downstream or consumer-side functionality of an event channel inside each log factory. This event channel is called a log event channel. Log events generated from a log factory and from its logs are all sent to the log event channel of this factory. To receive log events an application can create consumer-side proxies on the log factory through its operations inherited from ConsumerAdmin and connect to these proxies.
The following Java code illustrates how to connect an event consumer to a log event channel of a NotifyLogFactory:
This event is emitted from a log factory itself on a successful log object creation. The new log ID and the log creation time is encapsulated in the CORBA Any event body as an IDL structure defined as:
This event is emitted from a log factory itself on a successful log object deletion. The deleted log ID and the log deletion time is encapsulated in the CORBA Any event body as an IDL structure defined as:
This event is emitted from a log on a successful log attribute value change. Information about the attribute value change is encapsulated in the CORBA Any event body as an IDL structure defined as:
|
•
|
logref is the reference of the log object itself.
|
|
•
|
id is the log ID of the log object.
|
|
•
|
time is the time the attribute value change was made.
|
|
•
|
type indicates the type of the changed attribute. See discussion below.
|
|
•
|
old_value encapsulates the original value of the attribute before the change.
|
|
•
|
new_value encapsulates the new value of the attribute after the change.
|
|
This type of AVC event is triggered by a successful set_capacity_thresholds() invocation on a log object and changes its previous capacity alarm threshold setting.
|
|
|
This type of AVC event is triggered by a successful set_full_action() invocation on a log object and changes its previous log full action setting.
|
|
|
This type of AVC event is triggered by a successful set_max_size() invocation on a log object and changes its previous log max size setting.
|
|
|
This type of AVC event is triggered by a successful set_interval() invocation on a log object and changes its log interval start time setting.
|
|
|
This type of AVC event is triggered by a successful set_interval() invocation on a log object and changes its log interval stop time setting.
|
|
|
This type of AVC event is triggered by a successful set_week_mask() invocation on a log object.
|
|
|
This type of AVC event is triggered by a successful set_filter() invocation on a log object and changes its filter.
|
|
|
This type of AVC event is triggered by a successful set_max_record_life() invocation on a log object and changes its max record life setting.
|
|
|
This type of AVC event is triggered by a successful set_log_qos() invocation on a log object and changes its log QoS setting.
|
This event is emitted from a log on OMG specified log state change. Information about the state change is encapsulated in the CORBA Any event body as an IDL structure defined as:
|
•
|
logref is the reference of the log object itself.
|
|
•
|
id is the log id of the log object.
|
|
•
|
time is the time of the state change.
|
|
•
|
type indicates the type of the changed state. See discussion below.
|
|
•
|
new_value encapsulates the new state value after the change.
|
|
This type of state change event is triggered by a successful set_administrative_state() invocation on a log object and changes its administrative state, allowing or disallowing log record write operations (insert, update, delete, etc.).
|
|
|
This type of state change event is triggered by a successful set_forwarding_state() invocation on a log object and changes its forwarding state, which enables or disables event forwarding.
|
This event is emitted from a log object when a log write operation causes the log to grow beyond its size threshold. Information about the attribute value change is encapsulated in the CORBA Any event body as an IDL structure defined as:
|
•
|
logref is the reference of the log object itself.
|
|
•
|
id is the log ID of the log object.
|
|
•
|
time is the time of the occurrence.
|
|
•
|
crossed_value the threshold value just being crossed.
|
|
•
|
observed_value the current log space usage percentage.
|
|
•
|
perceived_severity critical(0), minor(1) and cleared(2).
|
This event is emitted from a log factory or a log object when a problem occurs within the factory or log object. Information about the attribute value change is encapsulated in the CORBA Any event body as an IDL structure defined as:
|
•
|
error_num is the highest 20 bits of this field which are reserved for vendor-specific error ids.
|
|
•
|
error_string is the text string that explains the error.
|