|
|
General Tips
Troubleshooting Tips and Error Messages
General Tips
Are there any restrictions on the values used for the "TYPE" and "CLASSNAME "properties of a managed object? What is the typical use of these properties? Are there predefined values which we should be using? Are there any semantics associated with the properties? Does the "CLASSNAME" or "TYPE" need to match the Object's .class filename or database table name?
The "type" property is used to identify the type of the ManagedObject such as Network, Node, Interface, Switch, Router, etc. There is no restriction in using the 'type' property. You can set any value for the "type" property as per your requirement. But the "classname" property should exactly be the object's class name. By default while adding the ManagedObject, NMS will set the correct classname for the Objects since it is used internally in NMS . Hence, the classname property must not be modified.
What are the tables that are affected in the Topology database when a node is added to the database?
When a node is added to the database, entries are made in the following tables:
Node Table
TopoObject Table
ManagedObject Table
In all the above mentioned tables, the isNode property is set to true. Entries are also made for the corresponding interface object as 'IF' - prefixed to the name of the node. For example if the name of the node is 'mynode', then its interface object would be IF-mynode. The entries for the interface object are made in the IpAddress Table, TopoObject table, and the ManagedObject table with the isInterface property set as true.
MODELING RELATIONSHIP AMONG MANAGED OBJECTS
There is a set of Network Elements that are connected to another set Network Elements through Proxy Network Elements (in a hierarchical network). How can such a relationship be achieved and stored in Web NMS?
Let us name these Network Elements as Shadow Network Elements. There can be two instances of modeling the relationship between the Shadow NE and the Proxy NE.
Case 1: Shadow NEs are connected to the Proxy NE and are also reachable through other NEs
In this type of scenario, you have to model each shadow NE as a separate Network Element.
Case 2: Shadow NEs are connected only to Proxy NEs and are not reachable through other Network Elements.
This relationship can be achieved by modeling the NEs as a Containment Relationship. The Proxy NE can be configured as a container and the set of Shadow NEs as the Children Objects. The Containment Relationship can be modeled by extending the ManagedObject class with the isContainer property of the ManagedObject Table set as true. The relationship is captured between the Proxy NEs and the Shadow NEs through the childrenKeys property of the Proxy NE (parent object) and the parentKey property of the Shadow NEs (child object).
What are the conditions that need to be satisfied in order to set the ParentKey value?
For parentKey to be set for an object, two conditions need to be satisfied:
The ManagedObject set as the parentKey must be present in the Database
The ManagedObject set as parentKey should have implemented ContainerInterface or the property 'isContainer' should be set to true
Even if any one of the above conditions are not satisfied, the parentKey for the object is set as 'null' and added.
What is the relationship between Interface, Node and Network?
The Interface, Node and Network have a special kind of relationship and they do not come under Parent child relationship.
1.The interface object holds the following properties:
parentNode- The node to which this interface belongs.
parentNet - The network to which this interface belongs.
One Interface can have only one parentNode and an Interface can belong to only one Network object.
2.The Node object holds the following properties.
ParentNets - the networks to which this node belongs
InterfaceList - a vector of Interfaces associated to it.
Each node can have any number of interfaces. This property is not directly persisted in DB instead they are queried internally from the parentNode and parentNet properties of the Interface object from IpAddress table.
3.The Network object holds 2 vector properties namely
InterfaceList - containing the Interfaces corresponding to that network
NodeList - containing the Nodes corresponding to that network.
Again these properties are not directly persisted but queried from the IpAddress table while fetching the Network object.
MANIPULATING DISCOVERED MANAGED OBJECTS
The parentKey for the slots, cards, and ports have been set in the discovery filter. But when the object is returned, the parentKey get overwritten as null. What is the cause for this behaviour?
The reason for this behavior is given here: When a parent object has been discovered, some children objects are added to it through the discovery filter. The possibility is that the childrenKeys property might not have been set for the parent object and returned. If children objects are added from the filterObject() method of discovery filter, you have to either return null or set the childrenKeys for the object and then return it. If the object that is passed to the filterObject() has its childrenKeys property set as null, this will cause the parentKey property of the children to be set as null. This would be the case even if the parentKey has been set to some other value previously.
This can be avoided by updating the childrenKeys property of the parent object after adding each child object using the ManagedObject.addChildrenKeys() method and finally return the parent object.
How to add a Node from the Discovery Filter. I tried using the addNode() method but ended up with some errors.
To add a custom object from the discovery filter, addObject() method of TopoAPI from the filterObject() method of the discovery filter must be used. The addNode() method of TopoAPI should not be used for added objects from the discovery filters. This is because, the addNode() method will invoke the discovery filters before adding the object into the database. This will cause a recursive call between the discovery filters and addNode() method.
In which order do the discovery filters receive the objects being added?
The discovery filters receive the interface objects first followed by the corresponding node object.
How does the Node identify its corresponding interface objects in the database?
Web NMS associates the discovered interface objects to its corresponding node object. The interfaces that have been discovered and passed to the discovery filters have their parentNet property set to the corresponding node object. The node also maintains a property called 'InterfaceList', which is a vector containing the names of the interfaces corresponding to the particular node.
The displayName property of the MO has been changed using the addNode() method. But these changes are not reflected in the object passed to the discovery filter. What are the possible reasons for this behavior?
When an object is added using the addNode() method, the object gets discovered and properties associated with a node are set. Only properties that are required for the discovery process such as the snmpport, community, etc., are taken from the node object that has been added. Thus even if you try to set the name of the object using the addNode() method, it will not be set. Internally, the Name and Display Name of the node are set from its DNS Name. If the particular node does not have the DNS Name, its IP Address will be set as the name and Display Name of the Node Object.
When a node that has been added using addNode() is passed to the discovery filter (i.e., using filterObject()), the node object will not contain the Display Name that you have set. Instead, the object is passed with its default display name. Instead of setting the name for the node object by using addNode(), you can set it inside filterObject() and return it and this gets added to the Database.
Each time the server is restarted, it tries to discover all the nodes in a particular network even if the objects are already present in the Database. An error message 'Managed Object already exists. Cannot add' gets printed. How can this be avoided?
When the Web NMS Server is restarted without reinitialization (warm start), the objects added during the previous start would be still present in the Database. Now when Web NMS attempts to add Objects that are already present in the Database, the above error appears. To avoid this, you have to check the presence of the Managed Object in the Database before adding the discovered object. The TopoAPI method TopoAPI.isManagedObjectPresent(String objName) can be used for this purpose. Please refer to Javadocs for more details on this method.
The code snippet would be as follows :
...
if (!api.isManagedObjectPresent(objName))
{
api.addObject(ManagedObject) //If the isManagedObjectPresent() returns false, then you will add the object to the database.
...
...
}
...
...
Some Network Segments have been discovered by the Discovery Engine with their 'Managed' property set to "false". The managedObject.setManaged() has been invoked to change the "managed" property to "true". When managedObject.getManaged() was invoked, it returned "true". But the data in the Database still shows false and eventually the discovery cannot be started for this network.
When managedObject.setManaged(true) is used to modify the 'Managed' property, you have to invariably use topoapi.updateObject(mo) to update the database with the specified value for the particular object.
Let us consider that mo is the Managed Object. The sequence to be followed is given here:
....
mo.setManaged(true);
topoapi.updateObject(mo);
....
You also need to check if 'Managed' property has been set to true for the Managed Object in the discovery filter and then return the Managed Object or check if this property has been modified in a TopoActionListener.
Whenever I add a node that already exists or a junk node, it gets accepted and the status message says 'Request being processed, please check events for results ...'. What is the cause for this behavior?
The above-mentioned status message is displayed when the option 'Return Immediately After Submitting Request' is selected in the Add Node UI in the Web NMS Client. When this option is enabled, Web NMS creates a separate thread to add a Node, such that you would be able to proceed with some other process simultaneously. In order to see the result of the added node in the status bar of the Add Node UI, please disable the option 'Return Immediately After Submitting Request' and then add a node through the UI.
Access denied exceptions are thrown when update or delete operations are done on a checked out Managed Object.
When getByName(mo) is used for checking out a Managed Object and operations are done using update(mo,boolean) or delete(mo,boolean), this exception is thrown. You can avoid this in two ways:
1. You can check out the Managed Object using checkOut() method and then perform the operation using update(mo,boolean) or delete(mo,boolean). Locks are handled in the checkOut() method.
2. You can check out the Managed Object using getByName() method, but for the operations you need to use update(mo,boolean,boolean) or delete(mo,boolean,boolean) with its third argument set as true. The unlocking of the locked Managed Object is taken care automatically when you use the update(mo,boolean,boolean) and delete(mo,boolean,boolean) methods.
Related Document
What are the different methods available for locking a Managed Object?
1. You can use getByName(mo) to check out a Managed Object. The lock() method available in TopoAPI is used to lock the Managed Object. Then the operations can be done by using the update(mo,boolean,boolean) or delete(mo,boolean,boolean) methods, with its third parameter set as true.
2. You can use the checkOut(mo)/checkOut(mo,int) of TopoAPI, which checks out the Managed Object from the database with a valid write lock. Then the update or delete operations can be done by using the update(mo,boolean,boolean) and delete(mo,boolean,boolean) methods respectively.
In both of the above methods, unlocking of the Managed Object need not be done explicitly as it is taken care of by the update(mo,boolean,boolean) and delete(mo,boolean,boolean) methods.
Related Document
Why do I get a TimeoutException when a Managed Object is being checked out?
If checkOut(mo) method is used, it waits for the minutes specified for the LOCK_TIMEOUT in the <Web NMS Home>/conf/NmsProcessesBE.conf file to obtain a lock for the Managed Object and then returns the object. Thus after the configured time, if a valid lock has not been obtained, TimeoutException is thrown. In checkOut(mo,int), the time it has to wait to obtain a valid lock for the Managed Object can be specified. If the time exceeds the specified timing then TimeoutExceptions are thrown. If checkOutIfAvailable(mo) method is used and if the object is not available immediately, then TimeoutException is thrown.
How to achieve Cascade delete in PostgreSQL when an MO is deleted ?
The requirement of Cascade Delete in PostgreSQL can be achieved by writing server-side code. The below mentioned APIs will help to do so:
Get the childrenKeys
using ManagedObject.getChildrenKeys()
.
Retrieve the children
Managed Objects using TopoAPI.getByName().
Check whether the child
object is a container or not using the ManagedObject.getIsContainer().
Use TopoAPI.deleteObject() method to delete the children
objects.
If the children objects
are also containers (check using the getIsContainer()), then use the above
mentioned steps recursively and use deleteObjectAndSubElements() method to delete the objects in each level.
By registering an application with the TopoActionListener, will changes be effected in the database? For example, there are entries of a particular MO in a table in the Database. If the MO is deleted from the Database, will implementing the TopoActionListener take care of deleting the row that contains entries of that particular MO?
Applications that have registered with the TopoActionListener will receive notifications whenever a Managed Object or its properties are added, updated, or deleted from the Database. Only notifications are handled by TopoActionListener. You will have to write your own code, for suitable actions to take place during the reception of a particular type of Notification.
The different steps involved in registering with the TopoActionListener are:
The application should implement the TopoActionListener. For example, public class ExampleObserver implements TopoActionListener
The application has to register with the TopoActionListener by invoking TopoAPI.register() method. For example, topo.register(this)
Registered application receives notification through the update() method
Deregistering of Subscriber is not successfully done from the server side. Updates continue to be sent from the server to the client.
To deregister a TopoSubscriber, the same instance of the TopoSubscriber which was registered has to be passed for TopoAPI.deregisterTopoSubscriber(TopoSubscriber) method. Ensure that only the already registered instance of the subscriber is passed for deregistering and not a new instance of the subscriber.
Can the font used in Telnet Tool be changed?
There is a provision to change the font size in the Telnet Tool as per your requirement. In order to use this facility, you have to append a value in the action_value parameter of the snmpmenu.xml file found in <Web NMS Home>/mapdata/menus directory.
The code is given here:
<MENU-ITEM
name="Telnet to device">
<JAVA-UI
action_type="openframe"
action_value="com.adventnet.telnet.telnetwindow.NmsTelnetFrame ?host=${ipAddress}&">
</JAVA-UI>
</MENU-ITEM>
The highlighted area shows what has to be appended in the snmpmenu.xml file. In the above code, the font size is being set to '11'.
What happens when there are two interfaces for a node and the tester value has been set as max. Which interface will the checkStatus() method check for?
In this case the checkStatus() method checks for the status of both the interfaces and returns the value of the maximum severity among the two.
How many threads are used for status polling? Is it configurable?
Status polling is done concurrently using 3 threads by default. Each thread takes care of the status polling of a single
Managed Object. Total number of threads used for status polling can be configured in the threads.conf file present under
<Web NMS Home>/conf directory.
How is Status Propagation done if the Node behaves as a Containment Object?
During Status Polling of a Node that behaves as a Container, the status of the interface is given priority over the status of the children objects. The children objects's status would be propagated only if the status of the interface object is clear. Thus when the interface object fails, the status of the interface would be propagated to the Node Object.
When does Status Polling for Nodes and Networks get triggered?
Status Polling for Nodes and Networks get triggered on two occasions:
If you have set the statusPollEnabled property to true for Nodes and Networks, Status Polling will be enabled
Whenever the status of Interface changes, Status Polling for Nodes and Networks are triggered. Status Polling would be triggered even if you have set the statusPollEnabled value to false.
How is it that even though status polling
is disabled for a managed object (statuspollenabled is set to false), the status is propagated
from its interface / child object?
The statuspollenabled property
is only for the default periodic status polling by Web NMS (i.e., periodic
polling done every poll interval). So, even if this is set to false, the
default interface to node status propagation will take place. If you have
enabled status polling in containment relationship, then status will be
propagated to the mo form its child object.
If statuspollenabled property
of managed object / parent object is enabled, then apart from the interface's
/ children's status propagation, periodic status polling will also happen
for that managed object.
Why is it that sometimes numerous Events
with message as 'Status Update' are received? How to hide them?
Events with 'Status Update' Messages are generated by Topology module whenever
the Managed Object status is changed during status polling.
If a device does not respond to Status Polling, a MAJOR Event will be generated.
This happens when there is a failure in the device. During the next cycle
of Status Polling, if that device functions as expected and responds,
then a CLEAR Event will be generated with the messages 'Status Update'.
This Event will update the corresponding Alert. And according to the value
set to ALERT_TO_MO_PROPOGATION, the status of this Alert will be propagated
to the corresponding MO.
If a Switch follows parent child relationship and if the child's status
gets updated, an Event will be generated for it. And also, an Event will
be generated for each parent in the hierarchy. So this is one typical
scenario when many Status Update Events will be generated.
So, the status polling events act as an important source of information for the Fault Management System and also in monitoring the network elements. These events will be used to update the MO status. As a result, at any given point of time, the MO reflects the current status of the device.
If you do not want those Events in the Client view, you can filter them out by modifying the custom view. If you give !Status Update as the match criteria for the Message field, you will not be able to see those Events in the Client.
When a node is deleted, why is the
status not propagated to the network immediately? The network keeps showing
the status corresponding to the deleted node itself.
When a node (children object) is deleted, the status polling of the corresponding
Network (parent object) will not be triggered immediately and hence the
status of the network will not be updated.
The parent status will be updated once there is a status change in any of the other existing children.
This has not been handled in our deleteObject API considering the following
reasons:
- This will slow down the performance of deleteObject API as we need to
check whether the deleted object is a children and whether status propagation
feature is enabled, and then check out the parent object and invoke status
polling for it.
- After the deletion of the child, the status of parent will get updated
once there is a change in the status of other existing
children.
If the requirement is to update the status of Network object immediately
after the deletion of children, any one of the below approaches can be
followed.
a. Enable status polling of parent object so that the status of parent will be updated periodically based upon the status of the available children.
b. Register as a TopoActionListener to receive "Delete" notifications. Upon receiving delete notification of a child, you
can invoke status polling of the parentObject by calling the parentObject.pollStatus() method. The pollStatus() method present in ManagedObject class will invoke status polling of the object.
What happens when an interface, whose
status is reflected by the Network, is unmanaged?
Consider a network having multiple interfaces. One of the interface is
having critical status and another one having major status. Now, the status
of the network will be critical (if tester = max). If you now unmanage
this interface (the one with critical status), the interface's status
becomes unknown. The Network status will remains critical. If you choose
Update Status option of the Network object from the Client, status poll
will be triggered for the Network object and thence will reflect the maximum
status of the remaining managed interfaces.
How to customize the properties (like
category, message) of an Event that gets generated due to status polling?
If you want to have a control over the Event object properties to be generated
as a result of status polling, you can follow one of the below approach:
Customizing status polling - here, either by invoking a user class or overriding checkStatus() method, generate your own Event with the desired properties by calling EventAPI.addEvent() and return -1 from the test() method of UserTester or checkStatus() method.
Using Event Parsers to modify the properties
The STATUS_POLL_DELAY parameter is to make the server wait for some time to start the status polling process. This parameter can be used in cases where you have large networks to be discovered during server startup and so you do not want the server to be loaded with both discovery and status polling. You can postpone the status polling for sometime.
If any of the arguments to the updateStatus() method (either the "Interface Name" or "Status") is NULL.
while trying to update a managed object with an invalid severity.
During status update, Web NMS will try to get the handle of the Managed Object to update its status. If the Status Update thread is not able to get the reference of the managed object within the specified timeout period then this method will return false value.
if any exception is thrown while updating the parent status or committing the status in the database or while releasing the obtained handle of the Managed Object.
Why is the following error message got:
13:37:06:055 TOPO: Remote object error:java.rmi.ConnectException: Connection refused to host: 192.168.6.96; nested exception is : java.net.ConnectException: Connection refused
This message is printed by Web NMS when an application which has registered itself with the TopoObserver has disconnected before deregistering from the TopoObserver. The above print in nmserr.txt is harmless and is logged for informative purpose. It is advisable to invoke TopoAPI.unregister(TopoObserver obs) method in order to deregister from the TopoObserver, such that the application no longer gets notified about the changes in the Database
When TopoAPI is accessed via RMI from the Application or Applet Client, exceptions like the ones given below are thrown:
19:32:29:326 MISC: RMI Bind Exception. TopoAPI wont be accessible via RMI java.rmi.ServerError: Error occurred in server thread; nested exception is: java.lang.NoClassDefFoundError: javax/transaction/RollbackException
This exception is thrown when the jta.jar is not included in the class path. Please set it as given below:
Application Client:
Include jta.jar in startApplicationClient.bat/sh file in <WebNMS Home>/bin directory.
Applet Client:
Include the jta.jar in the ARCHIVE tag of clientparameters.conf in the <Web NMS Home>/conf directory.
When Web NMS server is started, the application logs the error message 'TopoAPI not bound in registry. It might not have been initialized'. What causes this message?
During server startup, some of the Web NMS modules try to get the TopoAPI instance. If the TopoAPI was not bound in the RMI Registry at that moment,the above given error message is thrown. Once the TopoAPI is bound in RMI Registry,the error message will not be seen. These error message are harmless and you can kindly ignore them.
When trying to add an object, the following
message is got. What might be the cause?
TOPO: Exception while adding Node Object abc at: java.lang.NumberFormatException:
null
If you are using the Dynamic Schema Extension method to include additional
properties and have not set a value for any integer parameter while adding
the object, NumberFormatException
will be thrown. Hence, if you do not wish to give any value to the integer
parameter, set the value to "0".
Related Document
When a Add Node operation is performed from the Client, the following error message is got:
"Network is Unmanaged. Creating NetWatch without initiating discovery192.168.5.22". Why is this message got?
This message is thrown in the nmsout.txt, when you try to add a Node whose parent network is unmanaged. This is a printed for information and is harmless.
|
|