We had a similiar issue intially. We had resolved it by adding the line" releasefileatonce=true" the RDServer.ini.
Regards, Chandrakanth On Aug 31, 11:50 am, Daniel <[email protected]> wrote: > We are having nearly the same symptoms on our server from time to > time. The publishing job (ftp transfer) keeps listed as active in the > asynchronous job list and the publication hangs. That means, no pages > are published for this project the following days, if not nothing is > done. After doing some research we saw that the cause of this seems > the high CPU utilization during the publication on the server. > A temporary solution (we hope it will get better with MS Version 10) > is to lock the project against publication (server manager > project > settings) and to restart the server. After releasing the project to > publication again, all pages are worked off and published (even if the > publication failed for several days). > > Hope this helps... > Daniel > > On Aug 28, 10:13 pm, rwagner <[email protected]> wrote: > > > > > Thanks guy, you've each given me a little more information that I > > already had. > > > To help further: > > - We do not appear to have any network issues > > - We do have "always replace media files" checked, but we may need to > > keep that on in the long term for other reasons (in the meantime we > > may experiement with that) > > > Keep the suggestions coming! > > -rw > > > On Aug 28, 3:08 pm, Dave Bellous <[email protected]> wrote: > > > > I had a similar situation after checking "always replace media files" > > > in the Publications Settings dialog. > > > > Publication works like this (roughly): > > > > 1. RedDot writes everything out to /RedDotTemp directory > > > (the job moves from an 'active' job - to completed in the publication > > > log section at this point) > > > 2. Directory or FTP transfer takes place > > > > The publication report gets 'drafted' and then rewritten as the FTP > > > process occurs. > > > > It sounds like the FTP process is hogging the connection - and it's a > > > linear process - so while your publishing is multi-threaded, your FTP > > > process will queue up like a soup line. > > > > If you're republishing all your media files - that can produce a much > > > longer publish. I'd have a look at that particular setting in the > > > Administer Publication > Project > (action menu) Edit General Settings > > > > 6th item in that list (Always replace media files). Uncheck that > > > if you're trying to reduce the publish time of your project. > > > > You may need to check that box to ensure everything is flushed out > > > once a week, but if you're getting great delays - have a look at that > > > section. > > > > Wayne's suggestion below is a good workaround for the long term - and > > > a better setup in general. > > > > Luck, > > > > .dave > > > > On 28-Aug-09, at 9:26 AM , Wayne Bouwmeester wrote: > > > > > I guess this may seem like an obvious question, but have your network > > > > folks changed anything that may be slowing down the connection to the > > > > FTP server around the same time you noticed the significant slowdown? > > > > > Something to think about: > > > > As a test, I'd create a publishing target to the file server, try a > > > > full publish to it, then again the next night (the times may differ > > > > depending on your settings) > > > > If you get way better response publishing to the file server (I'm > > > > guessing you will), I'd look into implementing a product that can push > > > > the files out from the file server to ftp server. We always see faster > > > > publishing to a file server target, and then you can use best of breed > > > > software to move the files after the publish / keep them in sync > > > > during the day. One of my clients used winscp and it worked fairly > > > > well. I haven't done a lot of research into other tools. > > > > > NB - I'm not sure how much better CMS 10 is for FTP vs file server - > > > > it may have made great gains. > > > > > Wayne. > > > > > On Aug 28, 7:47 am, rwagner <[email protected]> wrote: > > > >> I want to throw this out to the big brains out there. > > > > >> We have a CMS nightly publication that is 6000+ pages and we expect > > > >> to > > > >> take about three hours to publish to LiveServer. Lately, it's been > > > >> taking in excess of 12 hours, and sometimes we have to shut the job > > > >> down because it prevents publications from taking place the next day. > > > > >> The publication report in the CMS says "finished" but only displays > > > >> the media files published, no pages. After that it takes hours and > > > >> hours before an email gets send and the rest of the pub report fills > > > >> out. During this interval there is an async process called "FTP- > > > >> Transfer for PROJECT NAME" that sits in the async queue and does not > > > >> permit any other publication jobs to pass through. > > > > >> Has anyone out there seen something like this? If so, any ideas on > > > >> what might be causing it or how to approach fixing it? > > > > >> Much thanks for any help. > > > > >> -rw > > > > -- > > > daveb- Hide quoted text - > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en -~----------~----~----~----~------~----~------~--~---
