Messages stuck in VV

[Simon_Butler]

Here's the scenario:

VV enabled - policy allows user to copy items directly into VV for upload to Vault.  Copied 1500 items from PST directly in VV when Sync first ran it managed a few items then got stuck on 1.  Subsequent syncs error.  An ASP error is thrown on EV server.  No further items can be uploaded and now the only copy of these messages is held in the VV, so not great should the VV fail.

I realise I can probably attempt to fix this by copying the pending items out of the VV and blowing it away and restarting, but that is not going to tell me what went wrong and would not be a great solution with 30,000 VVs enabled.

Checking the archive - it seems that a duplicate copy of the item is archived during every failed sync run - there are now 100+ copies of 1 item in the archive.

Has anyone else come across similar failed upload syncs?  (I have opened a ticket with support)

EV8 SP4 Server, 2003 x64, Outlook 2003 SP3
Latest V8 post-SP4 client, Outlook 2007 SP2, XP SP3

Cheers,
Si

[Simon_Butler]

Should add that other clients are ok.

ASP error for anyone interested:

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.Event Type: Warning
Event Source: ASP.NET 2.0.50727.0
Event Category: Web Event
Event ID: 1309
Date:  28/05/2010
Time:  13:08:17
User:  N/A
Computer: Vault1
Description:
Event code: 3001
Event message: The request has been aborted.
Event time: 28/05/2010 13:08:17
Event time (UTC): 28/05/2010 12:08:17
Event ID: 0620dc1d90604dab8fae7eb220193027
Event sequence: 1610
Event occurrence: 91
Event detail code: 0
 
Application information:
    Application domain: /LM/W3SVC/1/ROOT/EnterpriseVault-1-129194417938132351
    Trust level: Full
    Application Virtual Path: /EnterpriseVault
    Application Path: C:\Program Files (x86)\Enterprise Vault\webapp\
    Machine name: Vault1
 
Process information:
    Process ID: 6996
    Process name: w3wp.exe
    Account name: NT AUTHORITY\SYSTEM
 
Exception information:
    Exception type: HttpException
    Exception message: Request timed out.
 
Request information:
    Request URL: http://vault1.domain.com/EnterpriseVault/UploadItem.aspx
    Request path: /EnterpriseVault/UploadItem.aspx
    User host address: 10.1.1.1
    User: domain\vaultuser
    Is authenticated: True
    Authentication Type: Negotiate
    Thread account name: NT AUTHORITY\SYSTEM
 
Thread information:
    Thread ID: 9
    Thread account name: NT AUTHORITY\SYSTEM
    Is impersonating: False
    Stack trace:
 
 
Custom event details:

[Simon_Butler]

Stuck item has a 1.25MB ZIP attachment which decompresses to 20Mb of log files.  Just text.

Unfortunately I left Outlook open over the weekend - now have 100+ copies in my Vault.

[RichardG]

It looks like the size of the item is causing the web server to time out the page before the item has been fully archived - so the client assumes that the item has not been archived. However it appears that each time the item does eventually get archived hence the multiple copies.

The timeout is controlled by a setting in <EV install>\WebApp\web.config called UploadItemExecutionTimeout. You could try doubling it from the default of 300 (seconds) to 600.

Richard.

[Simon_Butler]

Hi Richard - We came to the same conclusion - We've tried the setting of 900 for executiontimeout and this has allowed the item to upload successfully.

I believe this highlights a configuration issue - the timeout for item conversion on the server is higher the the VV tmeout.  Seems the VV upload will not be marked as complete until the item is converted.  So if the conversion takes more than 300 seconds or times-out, then the item will not be marked as successfully uploaded & is retried on the next sync.

I'm interested to know what other factors could contribute to multiple copies of the same message being archive - I now have 150 copies of this message stuck in a vault.

[RichardG]

Assuming you have allowed delete then VV could be used to delete the copies.
I don't know of any other specific reasons for the sync to result in multiple copies of archived messages. It could be argued that the client should include the page time out as a reason for marking an item as could not archive - this would have resulted in 3 copies (by default) and the sync would have proceeded on to the other items. However that could have resulted in the issue going unnoticed rather than being investigated and resolved.