cancel
Showing results for 
Search instead for 
Did you mean: 

Adjust timeout settings for fetching items from a dying Centera. Is it possible? (EV 10.0.3)

TorInge
Level 3

We are currently trying to move archives from a dying, out of support, Centera solution. We have used the internal move-archive function from a Centera Partition to a HCP Partition. This has worked well for 2/3rds of the users, until recently where Centera went down yet again. This time the regen in Centera does not complete after drives were replaced. But retries forever.

The issue now is that some objects we are trying to fetch from centera takes about from 2 minutes to 15 minutes per item, before it times out. Is there a way to adjust this, so we can actually copy data that still exist before the entire thing goes belly up?

What I want to do is move everything that is left. When everything is moved, then do "retry failed items" as long as possible.

This is an example of an object that takes too long to time out:

84á797á958 13:42:26.505 [14á972] (EVMoveArchiveTask) <13420> EV:M Error accessing SimpleStore. Attempt:1 EntryId:1D1684236E5E9504F8A488065A1074BCD1110000evmbx01 hr=Unspecified error  (0x80004005)
84á797á959 13:42:26.505 [14á972] (EVMoveArchiveTask) <13420> EV:M CItem::Get Elapsed time 152992.5ms
84á797á960 13:42:26.505 [14á972] (EVMoveArchiveTask) <13420> EV:H {CItem::Get} HRXEX fn trace : Error [0x80004005], [.\Item.cpp, lines {800,1298}, built Dec 11 16:21:00 2012].
84á797á961 13:42:26.505 [14á972] (EVMoveArchiveTask) <13420> EV:M CItem::Get com_error raised Error [0x80004005] (err=80004005)
84á797á962 13:42:26.505 [14á972] (EVMoveArchiveTask) <13420> EV:M CItem::Get Id: 2003A146AD8927A2DD7DF092570F7321 ArchiveId:1D1684236E5E9504F8A488065A1074BCD1110000evmbx01 hr: Unspecified error  (0x80004005)
84á797á963 13:42:26.521 [14á972] (EVMoveArchiveTask) <13420> EV-H {VerifyMovedItem.LoadItemVerificationContext} Exception: An internal failure occurred. Internal Error: 'Unspecified error  (0x80004005)'. Info:Archive:1D1684236E5E9504F8A488065A1074BCD1110000evmbx01 transactionId 2003A146AD8927A2DD7DF092570F7321 Diag:HRESULT: 80040306 Type:System.Runtime.InteropServices.COMException ST:   at KVS.EnterpriseVault.Interop.IItem2.Get(Int32 DetailLevel)

   at KVS.EnterpriseVault.MoveArchiveTask.Verification.VerifyMovedItem.LoadItemVerificationContext(IContentManagementAPI4 cmAPImaThread, ItemVerificationContext ctx) Inner:None

1 ACCEPTED SOLUTION

Accepted Solutions

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

Hello,

I am not sure it is possible to get MA to do what you want. It is made to be very secure, as usually, you want to be 110% sure that all items have been moved from A to B. Having said that, you might want to have a look at he EVMoveArchiveTask.exe.config file. There is an example file (Example EVMoveArchiveTask.exe.config) which shows the options you have. There also is a write up in the Admin guide I believe.

What I would try is the following:

Use the WaitForBAckupMode section = 2 (never wait)

ItemLevelMaxRetryCount = 1

It might be however that in your situation, MA might just not work, due to the inability to not read the source items properly. It might be that a 3rd party solution does a better job (in regards to skipping items it can't read), but that obviously comes with a cost.

 

Regards. Gertjan

View solution in original post

4 REPLIES 4

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

Hello,

I am not sure it is possible to get MA to do what you want. It is made to be very secure, as usually, you want to be 110% sure that all items have been moved from A to B. Having said that, you might want to have a look at he EVMoveArchiveTask.exe.config file. There is an example file (Example EVMoveArchiveTask.exe.config) which shows the options you have. There also is a write up in the Admin guide I believe.

What I would try is the following:

Use the WaitForBAckupMode section = 2 (never wait)

ItemLevelMaxRetryCount = 1

It might be however that in your situation, MA might just not work, due to the inability to not read the source items properly. It might be that a 3rd party solution does a better job (in regards to skipping items it can't read), but that obviously comes with a cost.

 

Regards. Gertjan

Thank you for your answer!

Actually I was looking for the max retry count (posted another message). I will add that to the config file and try it out. I have already added the no wait for backup back in March to speed up the process.

And yes, I will suggest that we will need a 3rd party solution as the EV Move Archive task is not built for this situation.

Again, thank you!

Just a follow up, does this look correct?

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
 <sectionGroup name="MoveArchive">
  <section name="common" type="System.Configuration.DictionarySectionHandler"/>
   </sectionGroup>
</configSections>
<runtime>
 <generatePublisherEvidence enabled="false"/>
</runtime>

<MoveArchive>
 <common>
  <add key="WaitForBackupMode" value="2" />
  <add key="ItemLevelMaxRetryCount" value="1" />
 </common>
 </MoveArchive>
</configuration>

Never mind, found the example config file now! It has all the answers.