Ownership in replicated environment

[Anonymous]

Hello,

We are having some issues moving files from one folder to another.  When we try and drop a file into a new folder we get an error saying:

"One or more of the entities required to perform this operation are currently not owned by your workgroup. If the ownership has be requested already, please retry the operation after some time."

This error is reflected in the vlog as Error 322: Work group does not have ownership.  I tried manually tried setting ownership to the server I am working on but still the same error even 'after some time'.  Everything in SQL looks just fine where the servers are communicating.

Could someone shed some light on how ownership works and if there is something I am missing.  I didn't think it would be this difficult to simply move an assembly.  We are using Collaboration 2013 with SQL Server 2008 R2.

Thanks,

Steve

[minkd]

I believe to move a file, your workgroup needs ownership of the source folder, the destination folder and the file itself.

Can you make sure that you have ownership of all three?

-Dave

[Anonymous]

Hi Dave,

Thanks for the input.  I made sure the server I am working on has ownership of those items, however still no luck.  With some more digging, even though the servers looked like they were talking, the weren't because files on one server were not being replicated to the other.  It turns out that somehow the SQL Server Agent froze, for lack of better term, and needed to be restarted, now there is what looks like over a week of updates it needs to replicate.  

I will let you know once it's back in sync if that helped or not.

Thanks,

Steve

[minkd]

It's a good thing you found out the agent was down when you did.  If it had been down for more than two weeks you would need to delete the subscriber and re-create it.

The wiki has some tips for monitoring replication here.

-Dave

[johannes.bauer]

hi,
was the sql agent frozen or the machine restarted?
you might want to check if sql agent is startup type automatic
br

[Anonymous]

The machine hasn't been restarted and the service is set to start automatically.  It actually happened again this morning where the main cause is the folder ownership isn't being passed and is in limbo.  What I mean is one server gives up the ownership but the other doesn't take it and if I manually do it both servers say its not owned by the other workgroup.  My only work around currently is to go into SQL and restart the server agent even though it is running.

Thanks,

Steve

[Anonymous]

Once I restart the SQL agent ownership seems to be passed ok but now I'm getting a replication error 109.  Here is the vlog error:

10/29/2013 9:13:27 AM *******************************************************************
Error: Soap Exception ( mesg-id = 635186348075779412 )
Exception: BadAuthenticationToken [300] 
Stacktrace: 

10/29/2013 9:28:38 AM Begin executing event Autodesk.Filestore.Replication on vault 'Vault' at 10/29/2013 9:28:38 AM
10/29/2013 9:28:39 AM Vault Vault is replicating 7112 number of iterations
10/29/2013 9:34:39 AM End executing event Autodesk.Filestore.Replication on vault 'Vault' at 10/29/2013 9:34:39 AM
10/29/2013 9:34:39 AM *******************************************************************
Event Processing: Error raised while executing scheduled event: Autodesk.Filestore.Replication
Exception: DatabaseError [109] 
Stacktrace: 
Server stack trace: 


Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Connectivity.Core.Services.KnowledgeVaultService.RunFilestoreReplication()
   at Connectivity.Core.EventMonitor.FilestoreReplication.Execute(ScheduledEvent scheduledevent)
   at Connectivity.Core.EventMonitor.Scheduler.ExecuteScheduledEvent(ScheduledEvent scheduledEvent)
   at Connectivity.Core.EventMonitor.Scheduler.ExecuteScheduledEvent(Object data)

Exception(Inner): Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
Stacktrace(Inner):    at Connectivity.Core.Database.TransactionContext.OnSqlException(SqlException e)
   at Connectivity.Core.Database.SqlAccess.ExecuteReaderInternal(SqlCommand cmd)
   at Connectivity.Core.Database.SqlAccess.ExecuteReader(CommandType commandType, String commandText, SqlParameter[] commandParameters, Int32 commandTimeout)
   at Connectivity.Core.DataAccess.Director.InvokeCommand()
   at Connectivity.Core.DataAccess.Director.Execute(Options options)
   at Connectivity.Core.DataAccess.ResourceStore.GetResourcesNotOnSite(String server, Nullable`1 startpointid, Nullable`1 pagesize, Boolean ignoreReplicationFilters)
   at Connectivity.Core.Operations.Replicator.Execute()
   at System.Runtime.Remoting.Messaging.Message.Dispatch(Object target, Boolean fExecuteInContext)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)


It doesnt look like replication has been running for a while.  Any thoughts on this one?

Thanks,
Steve

[minkd]

Filestore Replication and Workgroup Replication are two different things. The former copies the files to each site, and the latter replicates the databases.

The two week limit I referred to only applies to Workgroup Replication.

The error you posted looks like a timeout related to Filestore Replication.  To work around that issue you can increase timeouts. In the web.config on each ADMS, there is a "timeouts" element inside the "connectivity.platform" and "database" elements. Try increasing the "defaultCommand" timeout value.

-Dave