Jump to content


Longer or configurable “First”-Commit-Timout for configuration updates sent by cc

CC Configuration-Update Commit Started Configuration-Update-Timeout

This topic has been archived. This means that you cannot reply to this topic.
No replies to this topic

#1 Johannes Bucher

Johannes Bucher
  • Members
  • 21 posts

Posted 24 March 2014 - 11:28 AM

On barracuda-firewalls it happens quite often, that a configuration-update sent by a cc is not processed (time between commit started -- commit finished) as fast as needed on the firewall-box, so the command-center kills (Commit operation: 0 Refresh: killall -USR1 xxxxx) this updateprocess and sends a complete update which seems to have longer timeouts for the execution on the firewall-box.

According to the MC-update-logs on the firewall it seems that the first timeout is within 0 to 1 seconds which seems to be really very short particularly if the firewall is working hard. That is why I think that it would be necessary that this “first commit-timeout” should be longer or even configurable.
This would reduce configuration traffic and load on the firewall-box and the command-center too!