Developer forum

Any nlb settings sneaked in?

Is the solution using a URL that could be part of 2 windows schedulers?

Your index and build has the same name - try deleting your task and create a new one using another name.

Hi Nicolai,

Good call. I'll look it up with Terri.

There is definately NLB set up, but what's weird is that this is the only task that's causing the issue (i.e. the Products is not).

I'll do what you suggested too. I compared the .task file with another one that's not causing issue and nothing stood out though.

Hi Nicolai and Nuno,

This isn't caused by NLB. I see this on most of our solutions. We currntly have 2 Load Balanced solutions on different versions but I see that error on our single hosted sites as well.

So, is your tasks in these solution having the same name as the index? And could that be the issue? (it will have to fixed for sure, but want to find the cause)

HI Terri,

Can I get one of the logfiles for the exception? It should contain a full stacktrace.

We really should not be getting argument exceptions at any time.

BR

Martin

Hi Martin,

Here is the info from the eventviewer. 

2021-03-10 05:12:40.151: An active task with the given name ('Products\Product.task') already exists. Please provide a different name or wait until the existing task completes.
System.ArgumentException: An active task with the given name ('Products\Product.task') already exists. Please provide a different name or wait until the existing task completes.
at Dynamicweb.Diagnostics.Tasks.TaskManager.StartTaskInternal(String name, Action task, Tracker tracker)
at Dynamicweb.Diagnostics.Tasks.TaskManager.StartTask(String name, Action`1 task, Tracker tracker)
at Dynamicweb.Indexing.Repositories.Tasks.Task.Run()
at Dynamicweb.Indexing.Repositories.Tasks.TaskRunner.RunTasks()

I think the exception text is causing the confusion. It should probably something like this:

An active task with the given name ('Products\Product.task') is already running

So I think that the task is started before its previous run has completed - maybe set to run every 5 mins, but the build takes 7.

Hi Nicolai,

I checked and the task runs every 2 hours. The build takes 35 minutes or so (for A/B).

Thanks,

Terri

Could it be that you have both a schedule and a task that collide.

And did you try to change the name of the task to not have the same name as the index...?

Hi Nicolai,

My index and task have different names on Hewitt. I deleted and recreated the task for Nuno's request. We'll see if it helps.

Hi Nicolai,

I renamed the task and this error is still being written.

An active task with the given name ('Secondary users\BuildIndex.task') already exists. Please provide a different name or wait until the existing task completes.

Hi Nicolai,

This is still happening on both solutions even after renaming the build task to make sure it doesn't match the repository name. Is there anything else that can be done to resolve this?

Thanks.

Hi Nicolai,

Were you guys ever able to replicate this? Both our customers still have the issue and are still waiting to hear back.

Nuno Aguiar

Hi Nicolai,

I did notice 1 thing that might be relevant. The URL assigned to the error in the Monitoring tool is not always the same:

• /Admin/Public/TaskExecute.aspx
• /Admin/Public/WebServices/IntegrationV2/ScheduledTaskRunner.aspx?taskId=1&token=21c(...)679
  (I removed the token)

Does this provide any clues?

Nuno Aguiar

Yes - as first stated it seems like you have 2 tasks executing the index on top of each other. In this case, it seems like the scheduler runs and when doing an integration it also runs the indexing. And they run on top of each other, so somehow take that into consideration.

BR Nicolai

Hi Nicolai,

Understood. I will revisit this in more detail. Thanks

Nuno Aguiar

Hi Nicolai,

So that's proven. We disabled the "Repository Task handler" and stopped having issues every X minutes. 

However it's throwing the exception even when the Repository Task is not supposed to be triggered. For example: 

• The error is bring thrown very frequently - sometimes every 5 minutes
• The rebuild task is set to be every 2h
  (check attachments)

This tells me the exception is thrown too soon, before even checking if it's time to rebuild the index.

So it looks like the validation needs to be adjusted to have a better handle. I wonder if this exception shouldn't even be downgraded to a Warning rather than an error, because it's nothing likely actionable, simply calling out that it was already running.

Does that sound accurate to you?

Nuno Aguiar

I'll add to this thread of Nuno's. We still have issues on some of our sites, and one in particular is becoming more of a problem.

I used Process Monitor to capture when it occurred to ensure that we didn't have any other external dependencies (antivirus, NLB, scripts, etc).

There are some 18 pages of reads and writes to Status.xml pages per second. So it's very chatty. Sometimes there is a locking issue that occurs. We've mitigated the issue by adding a 3rd index, but it's still a problem. About 2-4 times per day there's a lock and the indexes have to be manually kicked off again, or wait until the next automated rebuild.

The following image is from using Process Monitor filtered to Status.xml. I was able to find when a situation occurred (due to an email notification when it fails) and find where the error occurred. It shows as a sharing violation. Note that it’s all for the same w3wp.exe PID, so it’s not being locked by antivirus or any other application. This is happening within the platform itself. The site is on 9.10.12. (note, the filter in the screenshot below is Status.xml in the path, and ‘END OF FILE’ and ‘SUCCESS’ for the Result are filtered out. That left me with just those 6 records in that 3 minute timeframe).

Any other ideas, and is there anything further that we can provide to help troubleshoot this? It's the same site and situation as on this post too: https://doc.dynamicweb.com/forum/cms-standard-features/cms-standard-features/index-failing-frequently

Thanks,

Scott

This is kind of an old solution, so hard for us to look into with any meaningful outcome.

We have change some things in relation to this file. We only write to state.xml when building, so that amount of writes sounds a bit weird...

Do you have anything custom in relation to indexing? Extenders, calls in tempaltes or anything?

Can this be reproduced on a clean DW solution?

Hi Nicolai,

Good questions. It is an older version now, so I was wondering if there had been any significant changes since that version. You've suggested that there have been. 

I wasn't clear in my post, but the 18 pages per second are mostly reads. The writes only occur when the index is rebuilding (I do remember the issue about the unnecessary writes). 

We do have a custom extender, but it's just getting extra data and doesn't appear to do anything on disk. We have tons of other customizations on this site. 

We haven't seen a repro anywhere else, including in their dev and qa enviornments. That said, I don't have an email notification if it happens in those environments so I've set it up now to do so. I assumed it only happens under load, but I'll try harder to get a repro in those environments.

I'll try harder for a repro elsewhere and post back when I have further info or questions.

Scott