Page Publisher issue

38 views
Skip to first unread message

Rayette Toles-Abdullah

unread,
Feb 10, 2012, 1:37:47 PM2/10/12
to Tridion PowerTools
We’re at our wits end with an issue we’re experiencing and of course
Tridion Support will not effectively assist us with this issue. Page
Publisher is a critical part of our workflow and content management
process so I’m reaching out to whomever will listen and provide
suggestions. We have repaired MS XML, reinstalled CME and
reinstalled PowerTools to no avail.

Here's the error we get when publishing directories with 400+ pages.

error 800706be /CustomPages/Powertools/Page_Publisher, line 473

We've running Tridion 5.3 and have always used the Page Publisher w/o
any problems.

Julian Wraith

unread,
Feb 10, 2012, 3:36:33 PM2/10/12
to tridion-p...@googlegroups.com

Hi Rayette,

I can appreciate you frustration with your current situation. However, I am not sure this group is the best direction with which to vent this frustration.

However, this group is a highly motivated team of Tridion experts from both SDL (including support) and partners, so I am sure someone can give you some guidance.

I work EMEA hours so I can look closer on Monday/Tuesday. Maybe you can share the ticket number so I can read the case history.

Cheers,
Julian

john winter

unread,
Feb 10, 2012, 4:26:04 PM2/10/12
to tridion-p...@googlegroups.com
I see the code on line 473 is:

Call objPage.Publish(arrTargetTypes(i), blnActivateBlueprinting, blnActivateWorkflow, blnRollbackOnFailure,datePublishTime, dateUnpublishTime, dateDeployTime, blnResolveComponentLinks, enumPublishPriority,blnIgnoreRenderFailures, intMaxFailures)

I suspect either:

1) The api has changed in 5.3 or
2) One of the values here is not correct.

I'm afraid I don't have an environment to test the code on, anyone got a 5.3 to take a look?  If you can give access to your environment where the problem exists, I'd be happy to take a look.

Thanks

John

Jeff Wisor

unread,
Feb 10, 2012, 4:30:13 PM2/10/12
to tridion-p...@googlegroups.com

Hi Rayette,

 

I’m sorry to hear about the difficulties you are experiencing with the PagePublisher; However, as the Engineer mentioned early on in the incident, support for the Power Tools is not provided by SDL Customer Support.


While support can continue to work with you from the perspective of this being a product issue (ie., publisher threads, memory, etc.), and the kind folks on this mailing list will look into the issue, you may want to also post your issue to the SDLTridionWorld forum to allow the wider community to comment.


@John - Rayette has been using the power tools on R5.3 for some time without encountering this issue, so it is unlikely to be a version issue. It may be that they have begun pushing larger volumes of content through the page (6k pages in one go, I believe).

 

Best Regards,

 

Jeff

Dominic Cronin

unread,
Feb 11, 2012, 9:05:51 AM2/11/12
to tridion-p...@googlegroups.com, rayt...@gmail.com
As Jeff says, the powertools are not supported by SDL customer support, but equally, the tool in question seems to be calling a standard Tridion API without any "funny business", and I'm quite sure that on that basis, they will deal with it appropriately.

I suspect the facts of the case may point elsewhere, though. The error code in question doesn't show up on Google, or at least not particularly helpfully. Perhaps support can help with identifying whether this is a Tridion error, and if so, which one. (ISTR that Tridion errors are in a lower range, but you never know.)

I'd advise the following:

1) Check the logs on your server and look for entries at about the same time. This means not just the Tridion logs, but System, Application and so forth.
2) Consider the possibility that bulk publishing actions are exercising your templating code much more heavily than one-off publishing does. If you have a memory leak (or other resource leak) in your templates, this may show up when you do bulk publishes. Configure perfmon logs for e.g. private bytes, handle count and similar things on both the publisher process, and on the relevant COM surrogate process (dllhost.exe). Monitor the system while doing a bulk pubish, and see if you learn anything
3) Revisit any recent changes in your templating code. Could they have introduced a problem. Does reverting to an older version of your templates make the problem go away?
4) Check your patch levels. Do you have all the relevant service packs and hotixes?
5) Eliminate the page publisher from the problem if possible. Use search to create a list of pages, and select and publish them. Do you still experience the problem?
6) Consider why you describe Page Publisher as a "critical" part of your process. Is this really true? If so, that would be unusual. Can you work differently?
7) Check whether any recent changes were made to the operating system, database etc.

That's just a start. There's always far more you can do to gather more information, and work towards a solution. In the words of the good book: Don't Panic!

Cheers
Dominic Cronin

On 10-2-2012 22:30, Jeff Wisor wrote:

Hi Rayette,

�

I�m sorry to hear about the difficulties you are experiencing with the PagePublisher; However, as the Engineer mentioned early on in the incident, support for the Power Tools is not provided by SDL Customer Support.


While support can continue to work with you from the perspective of this being a product issue (ie., publisher threads, memory, etc.), and the kind folks on this mailing list will look into the issue, you may want to also post your issue to the SDLTridionWorld forum to allow the wider community to comment.


@John - Rayette has been using the power tools on R5.3 for some time without encountering this issue, so it is unlikely to be a version issue. It may be that they have begun pushing larger volumes of content through the page (6k pages in one go, I believe).

�

Best Regards,

�

Jeff


On Fri, Feb 10, 2012 at 4:26 PM, john winter <johnw...@gmail.com> wrote:
I see the code on line 473 is:

Call objPage.Publish(arrTargetTypes(i), blnActivateBlueprinting, blnActivateWorkflow, blnRollbackOnFailure,datePublishTime, dateUnpublishTime, dateDeployTime, blnResolveComponentLinks, enumPublishPriority,blnIgnoreRenderFailures, intMaxFailures)

I suspect either:

1) The api has changed in 5.3 or
2) One of the values here is not correct.

I'm afraid I don't have an environment to test the code on, anyone got a 5.3 to take a look?� If you can give access to your environment where the problem exists, I'd be happy to take a look.

Thanks

John






On 10 February 2012 19:37, Rayette Toles-Abdullah <rayt...@gmail.com> wrote:
We�re at our wits end with an issue we�re experiencing and of course
Tridion Support will not effectively assist us with this issue. �Page

Publisher is a critical part of our workflow and content management
process so I�m reaching out to whomever will listen and provide
suggestions. � �We have repaired MS XML, reinstalled CME and

Nick Roussakov

unread,
Feb 11, 2012, 10:20:17 AM2/11/12
to tridion-p...@googlegroups.com, rayt...@gmail.com
Nice response Dom.  You're the grand master guru of troubleshooting!  

Sent from my iPhone

On 2012-02-11, at 8:06, Dominic Cronin <dominic...@gmail.com> wrote:

As Jeff says, the powertools are not supported by SDL customer support, but equally, the tool in question seems to be calling a standard Tridion API without any "funny business", and I'm quite sure that on that basis, they will deal with it appropriately.

I suspect the facts of the case may point elsewhere, though. The error code in question doesn't show up on Google, or at least not particularly helpfully. Perhaps support can help with identifying whether this is a Tridion error, and if so, which one. (ISTR that Tridion errors are in a lower range, but you never know.)

I'd advise the following:

1) Check the logs on your server and look for entries at about the same time. This means not just the Tridion logs, but System, Application and so forth.
2) Consider the possibility that bulk publishing actions are exercising your templating code much more heavily than one-off publishing does. If you have a memory leak (or other resource leak) in your templates, this may show up when you do bulk publishes. Configure perfmon logs for e.g. private bytes, handle count and similar things on both the publisher process, and on the relevant COM surrogate process (dllhost.exe). Monitor the system while doing a bulk pubish, and see if you learn anything
3) Revisit any recent changes in your templating code. Could they have introduced a problem. Does reverting to an older version of your templates make the problem go away?
4) Check your patch levels. Do you have all the relevant service packs and hotixes?
5) Eliminate the page publisher from the problem if possible. Use search to create a list of pages, and select and publish them. Do you still experience the problem?
6) Consider why you describe Page Publisher as a "critical" part of your process. Is this really true? If so, that would be unusual. Can you work differently?
7) Check whether any recent changes were made to the operating system, database etc.

That's just a start. There's always far more you can do to gather more information, and work towards a solution. In the words of the good book: Don't Panic!

Cheers
Dominic Cronin

On 10-2-2012 22:30, Jeff Wisor wrote:

Julian Wraith

unread,
Feb 13, 2012, 4:13:02 AM2/13/12
to tridion-p...@googlegroups.com, rayt...@gmail.com
I've reviewed the case history from Customer Support and seems like they have covered all aspects that it can be. The ticket is low priority and it's been open for 4 days; the response time for a low priority ticket is 5 days. So is this really low priority or high?

Combine Supports information with Dominic's answer below, there are lots of things to try.

To recap;
You submit 6000+ pages to the queue but only 894 or so make it to the actual queue. If I understand this you mean the other 5000+ just never show up. This would sound like the API call(s) that are being done can't cope with the 6000. So if this did work before then something did indeed change and if you assume there are constants that did not change (e.g. code, powertools) then content and performance might be the two you are looking for. As the last update from CS suggests, I would start looking at the DB server as the potential problem.

You could try some additional activities to prove what is wrong;
1) use other CM server to fire off the publishing request to see if the server you are using has a particular issue. connect it to the same database as the other. Does it fail too?
2) connect the CM server to another database and run the same request, does it still fail?
3) Next you can write a test page to do what the powertool does but in a controlled way (like Jeff suggests, if 894 is the max and you submit 895 does 1 get missed?)

Cheers,
Jules...

Rayette Toles-Abdullah

unread,
Feb 14, 2012, 5:06:20 PM2/14/12
to tridion-p...@googlegroups.com
Thanks All for your responses!  You guys and gals rock.  Right now I'm at an OOM problem.  So I'm off to find out about any template changes that could be a problem.  The publishing transactions making it to the queue is changing but its around 800 - 900 pages.  The content editors have become really comfortable with powertools' page publisher, I'm sure we can work differently i.e. publishing for search results. 
Reply all
Reply to author
Forward
0 new messages