You are viewing limited content. For full access, please sign in.

Question

Question

Troubleshooting error 9035

asked on July 27, 2021

Our users are intermittently getting - "The current request could not be performed because there are too many existing operations running. [9035]". There are no corresponding errors in the server event log. This is a very intermittent error. A few times a day maybe. I haven't seen it with my own usage and have only seen it reported by a handful of users.

My understanding from reading these forums is that this is LFS policing itself and not a resource issue.

So my main question - is the user who gets the error message the one who is using too many resources, or is it more that resources are getting low across the server (maybe due a rogue external process) and the end user is thus randomly getting this error?

Also is there anywhere I could check in the database to identify what the problem is?

As far as real system resource usage goes everything is fine - processor, RAM, database, etc. Laserfiche Server 11.0.1 (build 294) running on an Azure VM. Users are connecting via TLS over the Internet (IP whitelisting is in place).

1 0

Replies

replied on July 27, 2021

Do you know what the users are doing when this occurs? Laserfiche has a limit of 10 concurrent operations per session and that could be a factor depending on their activities.

For example, if you open the LF Client and perform a long running operation like a complex search or a briefcase export in 10 different windows then tried an 11th it would hit the limit and trigger the error.

It doesn't necessarily need to be in separate windows; the important part is that each session can only run a maximum of 10 concurrent operations and you could try checking activity in the admin console.

0 0
replied on July 28, 2021

Didn't seem like folks were doing anything out of the ordinary. To troubleshoot I switched everybody to use our VPN connection to our Azure environment so that each client would appear with its own IP address and not a single NAT'd address coming over the internet. This shouldn't make a difference as each session is listed distinctly in the activity monitor regardless of how each client connects.

It's only been a day but so far so good. This shouldn't necessarily work but we are running a custom LF build to avoid Azure SQL PaaS database timeouts so maybe connection identification and handling are a little non-standard. Or maybe somebody else will get the error soon and I'll go back to the drawing board.

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.