Cobalt 32.67.xx unable to delete datZ files

[markKHA]

We have several controllers running Cobalt 32.67.10 and 32.67.20. We've identified in this version that the hi-res data files are actually one directory deeper than ATSPM expects (econolite/set1/ instead of set1/). We've corrected for this in the ControllerTypes table and are able to pull back and process the datZ files, but the FTPFromAllControllers component throws an exception trying to delete the files. This results in the same files getting processed over and over again.

Has anyone seen this issue, and if so, found a resolution? Thanks!

[Lee-ATSPM]

Mark,

We too have seen this issue on newly purchased Cobalt controllers with firmware 32.67.20. We were able to roll a few controllers back to 32.66.xx as this firmware was working on properly for ATSPMS on our other controllers. We also were able to write a batch script that used command line FTP parameters to download and delete logs from 32.67.20 firmware controllers. The command line ftp seems to be able to delete the .datZ logs.

[markKHA]

We've been looking into your response and had a couple questions:

1. Did you hardcode the IPs the batch script should connect to and pull data, or do you have it talking to the database?
2. How did you emulate the enable/disable snmp command to generate a new dat file after you pull and delete the existing one?

[udotdevelopment]

Hi guys. We are putting together a release that will fix this issue. It is an ftps issue.

[Lee-ATSPM]

It is good to hear a fix is on its way. Is there a timeline on the release?

To answer your questions on the makeshift fix, I wrote the script to function as similarly to the UDOT script as possible. It connects to the SQL database to obtain intersection numbers, IP's, filepath, and username & passsword each time it is executed. I also wrote in a few SNMP commands to enable data logging if not already enabled.

[udotdevelopment]

We are testing it on our server now.

…

On Fri, Jan 8, 2021 at 11:15 AM Lee-ATSPM ***@***.***> wrote: It is good to hear a fix is on its way. Is there a timeline on the release? To answer your questions on the makeshift fix, I wrote the script to function as similarly to the UDOT script as possible. It connects to the SQL database to obtain intersection numbers, IP's, filepath, and username & passsword each time it is executed. I also wrote in a few SNMP commands to enable data logging if not already enabled. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#92 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFY4K462AJXTAHWYPMK5CALSY5DTPANCNFSM4VAAYKKQ> .

-- Derek Lowe IT Analyst III Utah Department of Technology Services Cell - 801-842-3183

[Lee-ATSPM]

We have also seen this issue with Trafficware controllers. Will the release include updates to other ftp scripts as well?

[udotdevelopment]

The release is now available. Please let me know if you see any issues.

[markKHA]

Which file has the FTP fix? I looked at SignalFtp.cs but didn't see anything relevant.

[udotdevelopment]

Sorry I have been looking into this. Apparently the fix did not get merged into master. I am working on getting that in and testing it. As soon as I do I will update the release. Sorry about that. Thanks for bringing it to my attention.

[udotdevelopment]

As a side note the fix is specific to eos controllers but will work for cobalt 32.66.xx if you set their type as eos in the ATSPM site.

[markKHA]

I see a new setting "MaximumNumberOfFilesTransferAtOneTime" has been added to the config file for FTPFromAllControllers. What does UDOT recommend as a default value for that setting?

[ZachParkerCR]

As a side note the fix is specific to eos controllers but will work for cobalt 32.66.xx if you set their type as eos in the ATSPM site.

@udotdevelopment , can you point me to the fix that you mentioned in this thread? Also, are there ample instructions one upgrading version 4.2 to whatever the fixed version is?

Thanks!