Skip to content
January 14, 2013 / kiranpatils

Is your publishing stuck and and log file shows due to WebDeploy?

Challenge:

My dear readers & Sitecore aficionados — happy new year to all of you! Thanks for all your support and encouragement for the last year. Honestly, It keeps me encouraged to write and share Sitecore basics with you! I promise that will write and share more Sitecore basics with you this year! [Because – I believe that you should always try to deliver best than you delivered last time! – Competing with yourself!]. And needless to say, without your support and encouragement it won’t be possible! And I’ve paramount faith in you that you will not let me down! — Correct?

Sorry for being away from you since so long. But no worries. I’m back with new post — means a new thing to share with you! And Keep visiting lot of new posts are on their way..

It was a long time back, our publishing was stuck. After publishing a sublayout. [Just a note:  We use sublayouts a lot , and we do publish them from CM to CD via WebDeploy]

Publishing was stuck for quite a long time, and unfortunately to make it working we have to Recycle Application Pool.

We checked log for that time, and found following entry [If this is not a log entry for you, then please refer earlier article on publishing stuck]:

ManagedPoolThread #78 05:33:18 ERROR MSDEPLOY: Failed to synchronize folder . Please verify that the folder exists and is accessible.

Exception: System.IO.IOException: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host.
—> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.MultipleSend(BufferOffsetSize[] buffers, SocketFlags socketFlags)
at System.Net.Sockets.NetworkStream.MultipleWrite(BufferOffsetSize[] buffers)
— End of inner exception stack trace —
at System.Net.ConnectStream.InternalWrite(Boolean async, Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.ConnectStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.IO.BufferedStream.FlushWrite()
at System.IO.BufferedStream.Flush()
at System.IO.BufferedStream.Dispose(Boolean disposing)
at System.IO.Stream.Close()
at Microsoft.Web.Deployment.PackageSerializer.Dispose()
at Microsoft.Web.Deployment.AgentClientProvider.RemoteDestSync(DeploymentObject sourceObject, DeploymentSyncContext syncContext)
at Microsoft.Web.Deployment.DeploymentObject.SyncToInternal(DeploymentObject destObject, DeploymentSyncOptions syncOptions, PayloadTable payloadTable, ContentRootTable contentRootTable)
at Microsoft.Web.Deployment.DeploymentObject.SyncTo(DeploymentProviderOptions providerOptions, DeploymentBaseOptions baseOptions, DeploymentSyncOptions syncOptions)
at Sitecore.Publishing.WebDeploy.DeploymentTaskRunner.Execute()

Solution:

We were not sure. How WebDeploy can affect publishing. So, we raised a support case with our Sitecore support friends! And our ticket has been accepted by a wonderful support team member — Ekaterina — She approached problem nicely and helped us to reach to the solution!

1. First she asked for a memory dump, whenever such issue occurred.

And then from memory dump. She provided us a hotfix. With following explanation:

“I can’t say if it was that exact issue – complaints were about slow WebDeploy, comparably to standard MS WebDeploy calls, and I do not have dumps for those cases. As I see main issue in WebDebloy class lock in your dumps, and I can assume that when lock happens, actions on file synchronization are so slow, that all these locks are waiting to be released for too long. So part of the solution is to speed up synchronization itself. The solution proposed makes WebDeploy not to compare checksum of the files being synchronized, and it appeared to be much faster.

http://technet.microsoft.com/en-us/library/dd569089%28v=ws.10%29.aspx”

And it worked! So, as we were synchronizing big number of files from CM to CD via WebDeploy. And it was doing it in async manner. Where thread gets locked for synchronization. And as our operation was time-consuming. Lot of other threads were waiting in queue for publishing.

So, if you are also facing similar problem. Please raise a support case and ask for — Sitecore.Support.355500.dll [Support case — # 368349]

Happy Publishing! 🙂

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: