Sounds like there may be an issue with the server group signalling - see this KA for how to enable logging to see if that shows what's hapening.
Thank you, i will check this.
But after read article not understand how to fix problem with metadata based on this log file - it's network problem or wrong settings on ARS group
The logging will (hopefully) help show where the source of the problem then we can start to look for a way to fix it :-)
The source server should send a notification to all of the other servers in the group letting them know that there is an object change that they need to flag in their cache, so the next time that object is used it'll get the updated code.
When you look at the log of the source server (Admin), are you seeing any errors related to that signaling?
2 of 2 people found this helpful
Good Morning All,
The server group mechanism uses 3 key technical components in order to share objects across servers in a server group. JMS Messaging (which is used for the vast majority of server group communications), RMI Peer Listener, and the Peer Remote Object. All 3 of these communicate across the server group and manage cached objects including forms, filters, and other AR Objects - but also manage other cached objects like users and licenses. Here are the 3 parameters used to configured this:
You should make sure all 3 of these connections are able to communicate to each server in your group. You also should look at the following tables in your database to ensure there are no rouge systems listed:
SELECT * FROM servgrp_board;
SELECT * FROM servgrp_config;
If you have rouge systems listed in either of these tables please shut down all AR System Servers and then truncate these tables manually, then start the servers back up.
Once you've made sure that all 3 of those connections can communicate, these DB tables are clean, then please check back in with us.
One last thing, there is a know issue with the server group coordinator that in extremely high volume environment it can 'hang' and not perform very well. This only affects 9.1.04 and above, and there is now a hotfix to address that. Please see the KA below:
Often times we see this impact other areas of AR Server, but it could also impact other server group operations like object sharing.
1 of 1 people found this helpful
Looking at this log it looks like only the Peer Listening traffic is happening. I don't see any JMS traffic (Default-messaging-port) happening.
Check Default-messaging-port at ar.conf on all machines, check firewall - all ok
Good Afternoon Sergey,
Thanks for your response. Can you please capture the server group logging again? The last one didn't contain any normal server group entries. I'd want to see logs from both the admin servers where you're making the changes as well as the non-admin where the changes aren't being propagated.
It would also be nice to see these since a restart, so if you can do a restart then make the changes and provide the logs from start to finish that would be nice.
3 of 3 people found this helpful
Check ARS logs and find that on administrative ARS i had error that DB-host-name different from other machines in group. In ar.conf at this parameter on admin ARS i had IP-address, on other machines - DNS name.
Change to name, reconfigure all group (stop all ARS, delete records from servgrp tables) and now all works as need
Good Morning Sergey,
Thanks for your response. Oh wow, yes that will certainly cause a problem. Glad that you figured it out and it was that simple!