Hello -
I've found a problem with 3.12.2 CA repeater on both our VAX and AXP
platforms running OpenVMS 6.2 and MultiNet V4.0 Rev B-X. This problem
results in either IOC reconnect problems or problems connecting to a newly
booted IOC if the IOC was down when the CA client was started up. The
problem is NOT related to the fast-booting-IOC reconnect problem reported
by Jeff Hill a few weeks ago.
I believe the problem is in the MultiNet software and reported it to them
last week. In the meantime, I've made a simple change to CA repeater to
get around this bug. Details follow in this message. I'd be interested
to know if anyone else (using OpenVMS) has seen this problem? Perhaps
I have a setup or build problem? If MultiNet does not come up with a
solution, can CA repeater be changed permanently to get around it?
Thanks,
Stephanie Allison [email protected]
===========================================================================
Problem
-------
When multiple CA clients are registered with CA repeater and one of the
clients exits, the next time CA repeater forwards an IOC beacon, it will
receive a bad status (with ECONNREFUSED errno) from the "send" call for
all clients it sends to after the one that has exitted. Depending on
the order that the clients registered and the position of the closed client
in the list, it may take a few beacons for CA repeater to close all
sockets, but ultimately ALL sockets are closed and beacons are no longer
forwarded to the clients that are still up.
The clients that no longer receive beacons now go into some sort of polling
mode with the IOCs with which they are connected. My experience is that
clients that are doing straight periodic gets at some slow rate will usually
reconnect after an IOC boots. However, recently I've added clients that
do monitors and they usually do NOT reconnect.
Solution
--------
I took the CA repeater code from patch 7 of 3.12.2. A routine called
verifyClients has been added, apparently for some problem with the Solaris
platform. In the fanOut routine of repeater.c, instead of closing the
socket and removing the client from the list on a bad send, I set a
"verify" flag to TRUE. At the end of fanOut, if the "verify" flag is
set, verifyClients is called and sockets are properly closed or left
open.
I have reported this problem (with additional detail like TCPDUMP's)
to Process Software. It is PSC #1929. When (if?) I get a resolution,
I'll forward it on to tech-talk.
- Navigate by Date:
- Prev:
[no subject] J. P. BOUCHER
- Next:
RE: CA Repeater Problem on OpenVMS Systems using MultiNet Jeff Hill
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
[no subject] J. P. BOUCHER
- Next:
RE: CA Repeater Problem on OpenVMS Systems using MultiNet Jeff Hill
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|