How SNMP probes in InterMapper determine lost packets or "No SNMPvX Response"

Here is an excellent write-up by William W. Fisher about the behavior of SNMP probes by InterMapper.  As we are building our DC Insight solution on top of InterMapper, a thorough understand of InterMapper is very important.
I would like to republish it here for those who are interested to have a deeper understand of how InterMapper behaves.

InterMapper polls devices by sending a request packet and receiving back a response packet. If InterMapper sends a request packet and does not receive a response within the specified timeout (usually 3 seconds), IM counts that packet as 'lost' and retries the request. If InterMapper's request fails to elicit a response three consecutive times, the device's status is set to down. (3 is the default)

With an SNMP probe, the lost packets are SNMP packets. There are three possibilities for where the packet was 'lost':

1. The request didn't reach the target device.
2. The target device did not generate a response within 3 seconds.
3. The response did not make it back to InterMapper.

The SNMP probe is slightly complicated by the fact that the final retry will be a ping packet instead of SNMP. We implemented it this way after finding that some devices do not reliably answer SNMP packets on time. For example, a busy router might leave SNMP packets unanswered, but answer pings immediately. (Responding to a SNMP query is more computationally intensive than answering an ICMP echo). A device that answers the final ping retry is marked as "No SNMP response".

If pings get through fine, but an occasional SNMP packet is lost to one particular device, my sense is that nothing is wrong with the network. I would advise that you increase the threshold for packet loss for that one device to 10% and leave it at that.

Let me know if this helps.

Regards,

Bill Fisher
Dartware, LLC

Source: http://www.mail-archive.com/intermapper-talk@list.dartware.com/msg03281.html

Contributing back to the open-source. A JSP taglib to read maven generated version values from MANIFEST.MF

Update 2011-08-09: Turns out it is not possible to externalized it into a separate taglib project.  I suspect it is actually reading the MANIFEST.MF from the taglib jar itself rather than the MANIFEST.MF file of the referencing project. The project from bitbucket have been deleted.
------
I have been searching the web to find a taglib which read the version information from the MANIFEST.MF file. Since this is very commonly used, I am surprise I was not able to readily find such a JSP taglib available!

This got to be a common problem since I found plenty of references on how to read version information from the MANIFEST.MF file. For example:

http://stackoverflow.com/questions/1906266/maven-2-how-to-package-current-project-version-in-a-war-file
http://www.flexthinker.com/2010/04/avoid-users-cache-when-deploying-new-versions-of-flex-app/
...

Instead of keep repeating myself, I decide to just quickly put one together and share it through the web. I have also threw together some quick instruction on how to use it on the bitbucket wiki https://bitbucket.org/lsiu/qds-commons-web/wiki/Home.

Here is the taglib in action:

The "1.0 (5956254adaaa+)" is just reading from the MANIFEST.MF file which in turn is populated automatically during the maven build process by the maven-war-plugin.

BTW, if anyone know of such a tag library, please give me a shout.  I will be happy to "unpollute" the web with yet another "roll-my-own-code" doing the exact same thing.

DC Insight - Analytic - Giving Data Center facility managers and operators what they want, when they want

Over the past couple of weeks, I was working closely with a data center operator to complete a cooling optimization project.  The customer deployed our DC Insight solution, which allow us to have a very high-density environment monitoring solution.  We have 2 sensors at each rack and 4 at each CRAC, as well as door sensors, dry contacts and fluid tags all deployed with no cabling required.

We have allowed our system to collect the "as-is" data for a week, then we went on optimizing the air-flow distribution of the data center, including installing HotLok blanking panels and KoldLok grommets.  We also re-arranged some perforated tiles to allow better air-flow distribution to the server equipment.

We then sit and waited for another week to allow our DC Insight solution to collect data.

Using the before and after data, we compiled a comprehensive report for our customer, confirming some existing suspicions, as well as discovering new interesting trends and potential risks.  Bottom line, this is a very data-driven process which allows data center operators to truly understand the environment which houses their mission critical systems.

The time has now come to streamline this experience.  This is where DC Insight - Analytic comes in. We are moving towards gathering the grass-root experience, and merge it with the best practice of today, to provide an Analytic platform for our data center users and operators.  This is still in alpha stage of development, but anyways, here is a screenshot:

Looks familiar? It is time to bring intuitive user-experience consumer had enjoyed for years to the world of data centers.

With DC Insight we now have all the pieces to make this happen:

• DC Insight - Integrator: The data collection platform to collect virtually any device with an electronically readable output.
• DC Insight - Operation: Utilizing the best-of-breed and proven platform of InterMapper, this provide operation team a familiar user-experience: map-in-map view, tiered notifications and alerts, acknowledgement  and device maintenance mode, multiple authentication source options, and admin/operator/read-only user role seperation.
• DC Insight - Analytic: The platform which brings all these together.  The number crunching and processing platform to bring an aggregated view and provide business intelligence to operators, managers and executives of today's data centers.

Wraps up a busy week in Beijing

With a project still underway in Hong Kong, I still end up heading to Beijing for a week.  Thanks to my colleagues in Hong Kong for holding the fort, we were able to handle some ad-hoc customer request regarding the project while I was away.

Thanks to my colleagues in Beijing, we were able to meet with 2 System Integrators in Beijing on such short notice.  We showcased our Wire-Free RFID environment monitoring solution, soon-to-be re-brand DC Insight. We received some positive response from the System Integrators and they even suggested they would start putting this in as part of the standard data centre design proposal!

I also spend a good amount of time training my technical colleague Mr. Niu on the system.  He is a pretty quick learner.  By the 3rd day, he has no issue setting up the demo and presenting it to the customer for our second meeting with another SI.  Boy, was I relieve as it was very difficult for me to present in my broken mandarin. As China present ample of opportunities, I see a strong need to really pick up mandarin quickly!

In the evening, we spend some time networking and socializing over dinner with some of my dad's friends and former associates in China.  Thanks to my dad for arranging these events.

With my broken Canton-Mandarin, I did try to chime in occasionally.  In the beginning, I was often met with these confused "what-the-heck-is-he-saying" look. A couple more beers, either I stop caring, or the conversation started to flow a little better. At the end of the day, we exchanged some contacts and email addresses.  Hopefully this well lead to some lasting relationships and opportunities for both parties on the motherland.

"Find X biggest object by retained size" function in jVisualVM help find memory leak in your program

After adding the component to interface RF Code Zone Manager with a custom InterMapper SNMP probe, I went about load testing it to ensure the stability of the solution. I have created a map of many many probe and set them to poll at 1 second interval.

During the load testing, I observed this steady growth in memory:

Not a good sign.

Good news is the jVisualVM has made finding the memory leak so easy!  I recall in the old days memory leak hunting use to be a pain without enterpricy tools such as YourKit.
I don't know when this was added to jVisualVM, but this function, "Find X biggest object by retained size", is tremendously helpful in finding the root cause of the memory leak!

Why is this function helpful? To understand how this function will help determine the root cause from memory leak, refer to this article, "Shallow and retained sizes", by the folks at YourKit.
Now just examine the classes with the largest retained size, and they are probably the classes giving you your memory leak problem!

Event Driven Tags for Environmental Monitoring Solution - InterMapper NMS + RF Code Hardware

With the recent success in integrating InterMapper NMS and RFCode temperature and temperature + humidity tags, we took one step further and integrated event driven tags: Dry Contact, Door Tag and Fluid Tags.

Since there is a protocol mis-match between InterMapper and RFCode, to support event-driven tags, we developed a middleware which integrates nicely with RFCode Zone Manager.  The middleware acts as a virtual appliance which utilized existing SNMP standards such RFC 4133, RFC 4344 to provide a SNMP interface to the RFCode tags.

The concept is illustrated in the diagram below where in InterMapper, we select the QDS -> "DCI - Truth Value" Probe.  We set the "Virtual port" to "1" which is mapped to Tag ID "RCKDOR00001339" in the middleware.

Now our customer will be able to utilized the excellent monitoring interface of InterMapper and combine it with the benefit of RFID wire-free sensors.

Learn more about our Wire-Free RFID Environment Monitoring Solution.

STS maven "Select Dependency" not giving you any result?

The folks behind STS has purposely disable downloading the index of maven repositories.

Just turn it back on in the STS preferences > Maven - Check the option "Download repository index updates on startup" and restart STS.

In the Spring forum thread, Christian Dupuis mentioned "a lot of people were suffering from this behavior" (the behavior being the index downloading).  I wish he would elaborate on what he meant...