I’ve a couple of questions about publishing hubs that I’m interested in peoples thoughts on…
First question - do many people have publishing hubs set up in their environments? If not, is this because of cost, or do your publishing editions not cause any kind of slowdown to content contributors?
Second question - I’m thinking that a hot-standby server could double-up as a publishing hub. So, all publishing is performed by the publishing hub, but if for whatever reason the main content server/hub becomes unavailable, the publishing hub could be quickly configured to act as a standby server (and publishing server) for users. Does this seem like a feasible approach?
Having a hot(or cold)-standby server just sitting there doing nothing and waiting for problems sounds like a fine opportunity for a publishing hub configuration.
I’d be interested to hear any thoughts on the subject.
I think the “official” support for publishing hubs was deprecated with the introduction of 6.5.2.
Nevertheless, I have pondered the very same questions.
Just off-the-cuff, I think you’d have to do the following…
One obvious ingredient is an exact copy of your production file system on the standby server, pointed to the same datasource.
The standby probably should have the FTS engine turned off. You don’t want to risk corruption given that there’s a level of synchronicity between the database and the filesystem search indexes. I don’t know if that’s still true in 6.6, but in 6.5.2, the search index queue is in the database while the actual search index is in the file system… I’d imagine the same is true in 6.6…
You should probably also disable the polling action by rxserver. Otherwise, your two applications are going to be dueling to transition items through the workflow (nearly) simultaneously.
Lastly, recall that the publogs are dependent on the database and the filesystem… so your production server is going to show logs as being available, but the applicable xml document in publogs.war will be missing from your production server if the publication was performed by the standby.
Probably not telling you anything that you haven’t already thought of… Let me know your results.
We’re delivering 76 sites with over 35000 content items and still growing… It’s getting to the point we’re we are publishing practically every minute of every day, so I’m looking for a similar solution.
I’m not sure what gives you this impression, but it is not correct. Percussion still supports publishing hubs.
Check your license and confirm that it supports this practice. It might be wise to consult your Percussion sales representative to confirm that both you and Percussion interpret the license the same way.
I must have confused “remote publisher” with “publishing hub.” Functionally, those two concepts appear to be the same. Both appear to exist on a server separate from the rhythmyx server and publish content.
From Upgrading_to_Rhythmyx_Version _6_6.pdf:
In Rhythmyx Version 6.6, the publishing engine is re-implemented.
In the new implementation, remote publishers are no longer supported. Implementations that use remote publishers should be re-implemented to use File Transfer Protocol (FTP) or to deliver content directly to the output location.
So yes, it’s remote publishers that are no longer supported.