Re: [foxboro] AIM* collector failure
- From: "Johnson, Alex P (IOM)" <Alex.Johnson@xxxxxxxxxxxx>
- To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 22 Mar 2010 20:56:38 -0500
Re: When part of a system is powered down, it is always a good idea to run a
CHECKPOINT on all CP's after the power is restored (before process is
re-started). This ensures that all peer connections are formed. If the cables
or switches are disconnected then you can run the tool to reconnect the device
monitor in usr\fox\cs.
I agree with Terry and I'd like to add to his comment.
When the CP reboots, it retrieves its checkpoint file and when ready announces
to the world the names of the compounds that it holds. This announcement is a
one-time event implemented as a multicast.
As has been discussed, one-shot multicasts can be lost, e.g., dropped by a busy
computer. When this occurs, programs like AIM* that have open lists will miss
the multicast and fail to reconnect to the data source.
When the CP checkpoints, it reissues the multicast. Assuming that things are
"calmer," the applications should reconnect.
This leads me to a suggestion. I think that you might want to get field service
in to check the loading of your network. If it has a high amount of multicast
traffic on a regular basis something like this CP reboot might well have
generated messages that are lost. Another possibility is that the
connectionless input buffer on the AW is full because the machine can't keep up
with its load.
In other words, this could be a symptom of other issues.
Best,
Alex
________________________________________
From: foxboro-bounce@xxxxxxxxxxxxx [foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of
Terry Doucet [doucet427@xxxxxxxxxxx]
Sent: Monday, March 22, 2010 8:01 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] AIM* collector failure
Matt,
When part of a system is powered down, it is always a good idea to run a
CHECKPOINT on all CP's after the power is restored (before process is
re-started). This ensures that all peer connections are formed. If the cables
or switches are disconnected then you can run the tool to reconnect the device
monitor in usr\fox\cs.
Terry
> Subject: [foxboro] AIM* collector failure
> Date: Mon, 22 Mar 2010 17:47:18 -0600
> From: Matt.Gunter@xxxxxxx
> To: foxboro@xxxxxxxxxxxxx
>
> Please bear with me while I describe this scenario...
>
>
> 1) We are running AIM* (3.3.1) off platform.
>
> 2) We are running I/A 7.1.5 (all Solaris boxes).
>
> 3) We took four pair of redundant CPs off line. This included
> taking them "off line" in the System Monitor (probably an unnecessary
> step), then cutting power to them.
>
> 4) After completing the needed facility work, we restored power.
> All CPs came up "on line."
>
> 5) We thought everything was OK but determined some days later that
> no data from one of the CP pairs was being collected by AIM*. This
> particular pair was in a rack with two other pair, the data for which
> was collecting just fine.
>
>
>
> Restoring data collection was a simple matter of rebooting the redundant
> CPs. This means that we did not have to restart either the remote, or
> local collectors. Fortunately we had not been processing using those
> CPs, but the lack of data could otherwise have been a disaster. As a
> result, our method of powering up a CP (for any reason) will have to
> include determining if its data is successfully being collected. Seems
> pretty simple until the time we forget - which, of course, could be "the
> disaster."
>
>
>
> We are currently cooking up an method to continuously test to see data
> from all CPs are successfully being collected and that the AIM* server
> is actually alive. I just wondered if anyone else has seen this
> behavior, what the cause might be, and what can be/has been done to
> prevent it - maybe we can put our cookbooks away.
>
>
>
> Thanks to all!
>
>
>
> Matt
>
> ATK Space Systems
>
>
>
>
>
>
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
> foxboro mailing list: //www.freelists.org/list/foxboro
> to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
_________________________________________________________________
Stay in touch.
http://go.microsoft.com/?linkid—12959
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
*** Confidentiality Notice: This e-mail, including any associated or attached
files, is intended solely for the individual or entity to which it is
addressed. This e-mail is confidential and may well also be legally privileged.
If you have received it in error, you are on notice of its status. Please
notify the sender immediately by reply e-mail and then delete this message from
your system. Please do not copy it or use it for any purposes, or disclose its
contents to any other person. This email comes from a division of the Invensys
Group, owned by Invensys plc, which is a company registered in England and
Wales with its registered office at Portland House, Bressenden Place, London,
SW1E 5BF (Registered number 166023). For a list of European legal entities
within the Invensys Group, please go to
http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77.
You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail
inet.hqhelpdesk@xxxxxxxxxxxxx This e-mail and any attachments thereto may be
subject to the terms of any agreements between Invensys (and/or its
subsidiaries and affiliates) and the recipient (and/or its subsidiaries and
affiliates).
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
