My group is starting to see the the message below. How can we fix this? This pops up when we are trying to check in files. IT doesn't happen all the time, but often enough that it's a problem.
Vault 2013 Basic:
Has there been any progress on this issue? We are experiencing these issues as well.
Lock up on check-in / out_ IIS-Worker Process errors _ VLog- Token 300 etc...
Hotfix or similar?
Thanks in advance.
Tom
Nothing yet... Just struggling through here. Getting lots of pressure to look for viable alternatives at this point.
Hi Gents,
Please note we have addressed a number of the IIS and 300 issues in the latest vault service pack available here: http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=21017345&linkID=9261341
I would ask that you apply this and monitor any further errors / issues.
Hi Tim,
If you have applied the patches and you are still seeing issues I would recommend opening a support case with Autodesk to get deeper into this issue.
As noted through this thread there are a number of conditions that cause IIS to overload and fail resulting in loss of connection and these subsequent errors - the updates we released dealt specifically with threadsafe components of our product that were contributing to the overload but there may be other causes specific to each site.
@Tom and Dan - have the updates resolved your issues?
Hi Tom,
We will need to investigate your case further, as suggested we have identified one source of this issue which seems to have alleviated your problems but not resolved it all together - if you haven't already done so please log a support case so we can follow this up.
Disabling content indexing and applying the Vault Server 2013 Service Pack 1 has resolved the issue for the cases we have worked on.
You mean the same one we installed on 12/17/2012 that didn't help our problem. I don't mean to sound like an "A....Hole" but it's getting very frustrating going round and round. Also disabling content indexing would limit the search capabilities in at the user level, correct?
Thank you Jeff.
That is our current configuration, but we have still had issues.
Less often since the service pack though.
Additionally, yesterday afternoon we increased the ASPMaxRequestEntityAllowed and AspBufferingLimit parameters for IIS6.0 and
so far
no lock ups today, so we'll see.
Reference: http://support.serverintellect.com/KB/a321/how-to-set-file-uploaddownload-size-limits-in-iis-6.aspx
the script was not correct for our default location of the adsutil.vbs file, but a search for it and then point it..and it worked fine.
Time will tell, I'll report back if it locks up again.
Tom
Disabling content indexing will limit your search results. I can only speak on what I’ve observed with other client installs. In those cases there seemed to be some correlation between checking in new files while content indexing was enabled that caused this error to be thrown.
Typically the sequence of events is as follows:
1.) Add a new file to Vault (with content indexing enabled)
2.) Some files go in with no problem
3.) If not you get a long delay then the target of invocation error appears
4.) At this point the IIS Worker Process has crashed on the server
5.) Next you may receive an error code 0 when you try to add a new file until you perform an IIS Reset on the server.
So does the Vault 2013 Service Pack 1 fix the problem or is it really just a matter of disabling content indexing because it’s not playing nice with some of your files? I'm not sure there is a solid answer yet. I’m curious to know if it fixes your issue though.
Hello Vault-fault bothered!
Are there any new findings in solving this annoying issue? We also ran in that IIS-problem after upgrading to Vault 2013... We're no longer able to copy designs of Inventor assemblies in Vault.
Thanks in advance!
Can't find what you're looking for? Ask the community or share your knowledge.