Unexpected RSS authentication failure for 'leap16_2_c_tcp' during the Initialization Phase.
Jon Ritson reported an RSS node occasionally failing with an authentication error and SQLCODE -243/ISAM -154 on rss_tab_int, leaving it in fast recovery until restarted. Andreas Legner suspected a lock conflict and suggested onmode -d RSS instead of a restart. Gerd Kaluzinski said swapping DBSERVERNAME and DBSERVERALIAS worked for him. Jon considered it a transient lock when several nodes start together.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Just an observation really, occasionally on a fully functioning cluster the following is reported leaving the RSS instance in Fast Recovery ... a simple restart (onmode -ky; oninit) of the RSS and all is good ...
13:17:22 ERROR on the following statement SQLCODE:
-243 ISAM:-154select * from rss_tab_int where rss_servername = 'leap16_2_c_tcp'13:17:22 Unexpected RSS authentication failure for 'leap16_2_c_tcp' duringthe Initialization Phase.
Ensure that:
1. You are using the correct server name.
2. If using passwords, that you are using the correct password.
3. The HA_ALIAS setting is correct.
4. You have run the 'onmode -d add RSS' command at the primary to
register the RSS node attempting to connect.
------------------------------
Jon Ritson
------------------------------
Hummm, any circumstances that could explain this locking conflict? Any other RSS connecting/definition/deletion activity around such time? Anything in logical log for the
rss_tab_int table?
Also, I guess that instead of restarting such RSS a simple "onmode -d RSS <source_name>" might be sufficient to initiate a new connection attempt.
Greetings!
Andreas
------------------------------
Andreas Legner
Informix Dev
HCL Software
------------------------------
Hi ya
There is an HDR and another RSS starting around the same time. If one follows the message one could go down a rabbit hole ;) If I get this again I will try the onmode command to see if it kicks back to life.
Sent from Sky Yahoo Mail for iPhone
I had the same issue and found a simple solution: change DBSERVERNAME and DBSERVERALIAS, so that the RSS connection is using the DBSERVERNAME. I do not know why, but this worked for me Mit freundlichen Grüßen / Kind regards Gerd Kaluzinski Delivery Consultant Data IBM Technology Expert Labs Phone: +49 175 228 1983 IBM Deutschland GmbH Email: gerd.kaluzinski@de.ibm.com Mies-van-der-Rohe-Straße 6, 80807 München IBM Deutschland GmbH Vorsitzender des Aufsichtsrats: Ivo Körner Geschäftsführung: Wolfgang Wendt (Vorsitzender), Dr. Andreas Buchelt, Dr. Frank Kohls, Christine Rupp Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, HRB 14562
If HA_ALIAS is set and DBSERVERNAME is set to the relevant TCP connection and all onmode commands use the same setting as the HA_ALIAS then the issue is transient due to locking on a specific table as reported in the message I placed above when starting more than one HDR / RSS around the same time.
Not even sure the setting of the DBSERVERNAME / ALIAS is relevant if HA_ALIAS is set ... but I tend to set it to the TCP connection (and all onmode commands should be referencing HA_ALIAS).
Sent from Sky Yahoo Mail for iPhone
Hi JJ, since you only posted the actual errors, what would've been the overall timing there, esp. how much time passed from that RSS's connection attempt to the actual error (ISAM -154 indicating a lock timeout)? I'm wondering whether a simple retry upon hitting -154 would be advisable there... and what the actual lock timeout is. ------------------------------ Andreas Legner Informix Dev HCL Software ------------------------------
This was a rolling "onmode -uky; oninit" across Primary then HDR, RSS1 and RSS2 ... the attached shows the Primary log ... hopefully you can see the timelines :)
------------------------------
Jon Ritson
------------------------------