Server - Event Viewer - Window logs - Application

[JohnBell]

Hi,

Just trying to better understand this...

I was going thru the Event Viewer, and investigating the application events under the window logs. 

Sporadically, I'm seeing the below:

There was an error in Slave_Thread::DoWork: Socket timed out.

What is it?  What should I do, if anything?  Is there a need for concern?

Thanks,

[DiganP]

@JohnBell  This appears to be a MongoDB communication issues with timeouts (queries/etc taking longer than 25 seconds, twice in a row) which typically indicates resource issues on the server.

A few things that you can do to dig into the issue. 

* Enable mongodb logging in runtimesettings.xml C:\ProgramData\Alteryx
* Set service logging to high (I believe it's at medium or low currently) in system settings
* Set engine to run at low priority in system settings > Engine section

You can also reach out to support with the above information with an explanation of the issue as well. 

[KJennings]

Good Morning,

Our location just encountered this issue, with the same errors, causing the Alteryx Service to shutdown.  Thankfully the event occurred on our sandbox but what prevents this occurring on our PROD system?

Is there a way to determine what is causing this to occur?  Is Alteryx looking at root cause or a permanent solution?

Regards,

KJ

[iwonaf]

Having similar problem. Anyone was able to figure out the root cause of this?

[isubho]

Hi DiganP,

I have all the points mention by you. I think what you mentioned is correct and it might be a resource issue.

I just want to understand which workflows are creating these resource issues.

Can you help me identify that, please?

Thanks

Subhojit

[mhayes712]

We found this error in our Event Viewer and the issue appeared to be associated with an unexpected shutdown of our MongoDB server. This caused the update of a lock file, which when showing anything other than a size of zero, will prevent you from being allowed to restart the Alteryx service.

Removal of the lock file allowed us to then be able to restart the service. Another lock file was then generated with the new file appearing blank.

The lock file was located where MongoDB is installed from the System Settings->Controller->Persistence. Open a Windows Folder Browse and navigate to that folder. Check to see if the mongod.lock file is anything but 0k.

Alteryx advises backing up your Mongo instance before deleting the lock file just in case there is corruption. In our case, we had a backup already, so blowing away the lock file did the trick and we were able to start the Alteryx service back up successfully.