tray icon keeps disappearing

[Dean Roddey]

That would make sense, because it was failure to set the collection that accepts the incoming requests (and from which the tray monitor itself pulls those requests) thread safe. So, hit it at just the right point and it could be a problem.

[Shaky]

I'll try and upgrade when I get a chance as well and let ya know.

[Shaky]

Caught a crash today with logging on high. Although I don't see much in there and hopefully you have this corrected in the latest Beta, I sent you the log just in case it leads to something. I'll see if I can maybe get on the Beta stream here sooner than later to test.

[Dean Roddey]

I'm fairly confident that it's not worth digging into the log unless the fix I made is proven to not be as effective as I think it is. It's such an obvious culprit that it's a high likelihood kill.

[Shaky]

Well, unfortunately the tray icon has died on me again and I'm on the latest beta.  There's also some strangeness in the logs about a missing $timeout in several drivers.  That seems to have overshadowed anything else that may have been in there.  Will email the logs.

[Dean Roddey]

You have the data logger driver loaded, and it is set up to access a bunch of fields that either don't exist, or the drivers have been moved or renamed or something. So it's logging a lot of stuff.

[Shaky]

You have the data logger driver loaded, and it is set up to access a bunch of fields that either don't exist, or the drivers have been moved or renamed or something. So it's logging a lot of stuff.

That's odd and started directly after upgrading from the last version. I have values in the DB for all those fields with timestamps just before the upgrade.  Nothing should have changed with drivers availability or names especially for 4 separate drivers which are logged. 

I just validated that my Master server can access the MYSQL database too.  All those drivers it complained about are still very much active and I can see values for the fields it's complaining about in the drivers viewer window and various IV fields.  Is it possible something in the new version has changed to cause this?  Might need some help here as now the logs are flooded so can't see anything on the tray monitor if/when it fails next.

[Dean Roddey]

Hmmmm.... Anything is possible. Are you actually trying to access the $Timeouts fields? Just making sure that's legit. Can you flush the logs, put the data logger into high verbosity for a few minutes, then take it back out and get me a dump? All we are getting currently is just that the driver isn't available, and other one being that the so and so driver doesn't have a field named $Timeouts. Looks like it's trying to read these fields once a minute, and getting a failure on all of them each time.

So this driver has a text file that lists the drivers and fields to read or something like that?

If it just happened for a while that wouldn't be terribly weird if you were starting and stopping systems or upgrading. But if it's still going on, then that's pretty strange.

[Dean Roddey]

Is the data logger driver running on the same machine as the drivers it's getting data from?

[Shaky]

OK, I'll send a new log with high verbosity. I'm not really sure what that $Timeout field is referring to. Not something I am trying to use on purpose.

This driver is set up to use certain fields via actual entries in the database itself and you specify how much time in between polls of which I'm at a minute for most fields. It's an ongoing thing so wasn't just a recycle of the driver or CQC we're seeing. It can't actually write any fields into the database now which is the error we're seeing every minute when it tries to write out all the fields it's configured to do.

The driver is running on the master server which also has all my drivers running on it so yeah it's on the same machine. The MySQL DB however is on a different machine but in ODBC on the Master Server it is able to connect to the DB via the built in test.