Hacker News Reader

Comment by click170 | Hacker News Reader

My experiences are very different.

Many Linux services have a concept of reloading. If the config file changes you can send the running program a signal and it will re read the config. This is very useful for production systems.

Tableau (9 at least) has no such concept.

Change the email address it reports to? Restart tableau.

Change the location of the SSL certificates? Restart tableau.

Want to apply an update for tableau? Uninstall your current version and install the new one. Oh and until recently when you downloaded the installer for tableau server the file name didn't actually contain the version number.

This product was not designed with ops in mind at all.

Edit: I forgot, I've actually had a tableau server fill itself up with logs. Tableau has logs in many different locations outside of windows event viewer and doesn't include log rotation facilities for all if them.

View on HN

That sounds like most Enterprise software.

It's like that because R&D and Operations never talk; and of course your average Windows Ops person has a poor understanding of operating systems.

Those things are indeed a pain with Tableau, and also common with a lot of Windows based applications.

Never understood why Tableau is either Windows only or has the restart to reconfig issue. Last I looked, it was largely a Tomcat and PostgreSQL based product.

[Replied to wrong comment]

What's the actual issue with restarts? Is the downtime due to a restart unacceptable? Is it that users lose application state when a restart happens?

Just trying to understand since I've written software with the same restart to config workflow and would like to understand what causes it to be problematic.

If you run tableau in an enterprise environment you will likely have a lot of c level executives, global sales teams and more relying on tableau to be available outside of your local business hours. This means any maintenance needs to be planned and communications sent out to all stakeholders.

If reloading was an option then there wouldn't be downtime, and I wouldn't need to schedule a maintenance window for something as simple as updating an email address. The idea being that if there is a config error during a reload, the system just continues uninterrupted with the original config. If I have to stop the system completely in order to run the config sanity checks when it starts again, the potential for prolonged downtime is much greater.

Thanks for that perspective, I hadn't thought of that.

Would a system that did something like an internal cut-over be useful? e.g. try to start a whole new instance of the application, if it loads, then let it become the running application, if not, write an error log and shutdown?

It would still lose all the state associated with the previous instance, e.g. user sessions, but would avoid this specific issue.

I agree that it's pretty silly that things like email addresses need a restart, but I'm wondering in general how bad this pattern is.

That would work IMO, yes.

An interrupted session isn't a big deal if it's an infrequent occurrence and they can just login again.

I think an improved solution in this vein would be a tool that would let you sanity check the config before reloading.

"tabadmin cleanup" helps a little.

But yeah, this thing is a mess.

Reply on news.ycombinator.com