This is not directly a question about code, but FileSystemWatcher/OS behavior. I have an app, which monitors thousends of logfiles. The app
runs since years without any problems. It was running on a Server 2003 against shares hosted on Server 2003.
If it runs on Server 2008 (R2) and the store is on Server 2008 (R2) not much events are generated. I made a simple repro which show the difference [but as I told: The long running old proggi does work properly]. The apps, generating the logs are not under my code control.
In my repro - writing such log with pauses - even a flush for the writer and/or the underlaying stream does not help].
On Server 2003 each update [write operation from the logging app] causes the FSW to fire Size changed events. On Server 2008, this happens only, when the app starts to write the logfile and when the logfile closes. No events in the middle any more. Settings the REG keys to write NTFS timestamps brought no changes to this behavior.
I am not in a position to open a call at MS, but probably, someone has seen this behavior and knows a workaround.
The workaround coming to my mind are: Downgrade to Server 2003 or to Linux. Both works as expected.
Any ideas are really very welcome.
Best regards,
++mabra
[Net 2.0 => 4.0; No question: All patches, OS also]
[edit]
Sorry, there were faults in my analyzis .... Together with the move of my
app to Server 2008, a new app came to the set of files to monitor [Change
never two things at the same time....]. The new app has another behavior,
then the apps which's logs I've read before ....
(1)The old apps use: Open/append, write, close.
(2)The new app uses: Open/create, write, sleep, write, sleep, write, close.
The FSW gives me the changed event for the old apps behavior, but not
for the new one. The FSW Notifyfilters.Size does not work like I have
expected. So, the new app's log cannot be monitored with FSW.
I found no workaround to make the chnaged event fire for size changes
alone.
But this keeps: The is Windows Server 2008 ! Windows Server 2003 and
Linux with mono even gives you the changed event for (2) !!!!! So,
my "title" was not that bad ;-)
Unhappy with .Net now ....
If someone has probably an idea, please let me now !!
And sorry for my sloppy first-time analyzis ... ;-)
br,
++mabra
Just for the case, that someone is watching this ....
I opened an Issue at MS.Connect - some weeks ago - and they
directed it to the VS team.
The bad news are from today, where they first set the issue
to "Won't Fix" and then to close.
I see this as in indirect confirmation of a bug, which
will not be fixed.
I am completely disappointed.
Anyway, best regards,
++mabra
=> MS Connect Issue
Related
I'm trying to debug Azure Function scripts locally, in conjunction with Unity, but getting Timeout errors every time.
I have a few things here, and I'm not sure which one is actually causing the problem... It might be a settings on Windows, as oppose to one of the softwares.
I'm building in Unity 2019.4, and and using PlayFab and it's ability to use Azure Functions. When I try to execute scripts from the Azure servers, it functions correctly. But when I try to run it with Local Debugging, I get WebException: The request timed out System.Net.HttpWebRequest.GetRequestStream (See full error below).
Here's what I'm doing to setup:
Set PlayFab to Local Debugging (via VS Code Extension)(and confirming the json file is made in the temp folder)
Install Azure Functions Core Tools from Here
Start Azure Functions debugging from VS Code (terminal output shows that the the localhost is running it correctly)
Timeout error references the correct address http://localhost:7071/api/CloudScript/ExecuteFunction as confirmed in the VS Code Terminal when the AzFunc debugging is started.
When I clone the project to my MacBook Pro, everything runs smoothly in local debugging.
So, because of this, I've tried checking to make sure ports aren't blocked via PowerShell: netsh firewall show state,and told Windows Defender to not block anything from Unity or Code. When I run Netstat -ab in PowerShell/CMD, I do get:
Can not obtain ownership information
TCP 0.0.0.0:7071 DESKTOP-COMPUTER:0 LISTENING
[func.exe]
TCP 0.0.0.0:7680 DESKTOP-COMPUTER:0 LISTENING
I don't know if this is a problem, or normal...
I don't even know what else to check for. This problem is beyond me. If anyone knows the solution, or can point me in right direction, I'd be very grateful!
Below are the two errors from the Unity log whenever I execute an Azure Function script through PlayFab while local debugging:
WebException: The request timed out
System.Net.HttpWebRequest.GetRequestStream () (at <14e3453b740b4bd690e8d4e5a013a715>:0)
PlayFab.Internal.PlayFabWebRequest.Post (PlayFab.Internal.CallRequestContainer reqContainer) (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:319)
Rethrow as WebException: Timeout: WebException making http request to: http://localhost:7071/api/CloudScript/ExecuteFunction
UnityEngine.Debug:LogException(Exception)
PlayFab.Internal.PlayFabWebRequest:Post(CallRequestContainer) (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:332)
PlayFab.Internal.PlayFabWebRequest:WorkerThreadMainLoop() (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:252)
System.Threading.ThreadHelper:ThreadStart()
Timeout: WebException making http request to: http://localhost:7071/api/CloudScript/ExecuteFunction
UnityEngine.Debug:Log(Object)
DemoScript:onPlayFabError(PlayFabError) (at Assets/PlayFabPartySDK/Examples/DemoScript.cs:264)
PlayFab.Internal.<>c__DisplayClass30_0:<QueueRequestError>b__0() (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:395)
PlayFab.Internal.PlayFabWebRequest:Update() (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:480)
PlayFab.Internal.PlayFabHttp:Update() (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabHTTP.cs:364)
Okay, TLDR: The answer to the problem is that not everything was updated. So, update everything if you're experiencing the same problem.
More specifically in my case, the "Visual Studio Code Editor" asset in Unity's Package Manager.
I just wanted throw this out there in case anyone has a problem like this in the future. It may not be the same specific thing that needs upgrading, but search around for everything involved and make sure it's updated. Not just the big, obvious things (like Unity or your IDE). Thankfully for me in this case, the update was starting to cause other problems, and after much headbanging trying to solve those, I came across it.
Good luck, future fellow idiots!
After upgrading system to Windows 10 - os 1803 we are getting below issues while working with ClearCase 8.0.1.x/9.0.1.x
Unable to checkin/checkout.
Not able to create views.
Not able to add any file to source control.
The system hangs & crashes while performing any ClearCase operation.
There is no error message, but I have attached screenshot for reference.
Please let us know if there is any issue with the Windows 10 ver(1803), any security system enabled?
Or has ClearCase provided any fix?
We have tried 9.0.1.5 and issue still persists.
This is what we got from windows event log.
The computer has rebooted from a bugcheck.
The bugcheck was:
0x000000c2 (0x0000000000000004, 0x00000000535be990, 0x000000000004efd3, 0xfffff803e01848b1)
for most of them whoever has upgraded to windows 1803 ver :( for people who are still using ver1709 it is working perfectly fine
Then I would recommand contacting IBM support: only them can update their ClearCase 9/Windows 10 compatibility matrix and confirm if MVFS is supported on a more recent (1803) Windows 10 edition.
We also facing same problem and I have raised the case with IBM. Still not yet resolved. As IBM said there are some limitations to work ClearCase with windows 10 and windows 2016.
We tried all the options except Secure boot disable. If possible please do disable secure boot option in Windows 10 and try to checkin/checkout code from CleraCase
Note : It works for Snapshot views. That means the issue related to MVFS
I'm seconding #VonC's recommendation to open a ticket with IBM. When you do that, save a step and collect a clearbug2 and a kernel memory dump to send in as soon as the case is opened. It will save the turn-around time of us asking you for it. If the installed programs list doesn't list installed security software (DLP, Privilege management sw like Avecto, other endpoint security tools), please list those separately as well.
I would also love to know who # IBM told you there are "limitations" with Win10-1803.
There are a few issues with Windows 10 "version upgrades" breaking things, but they generally don't cause system crashes. Windows 10 upgrades are actually full OS installs that then (imperfectly) migrate application settings. Anything that uses custom network providers (ClearCase is one example) will find that the network providers will be broken or partially broken. Reinstalling is usually required. Again, that has not yet been reported as a cause of a BSOD.
If the upgrade/reinstall didn't fix view creation, please post a separate question on the view creation issue. There may be things we can do to the SMB 2 caches to allow view creation to work in cases where the view storage is not on the client host.
I noticed that the screen shot you posted is a Terminal Services disconnect screenshot. Does the issue only occur over a Terminal Services client connection or does it also happen on a local connection?
Windows 8.1 Pro, Visual Studio 2012 Update 4, MVC4 Umbraco site using SQL Azure (have also tried with a local SQL 2008 R2 db). Running through IIS.
Site runs perfectly while not debugging. However, when debugging the site is extremely slow. The default page takes nearly a minute and a half to execute. Subsequent requests take the same amount of time.
I thought this may be environmental (Surface Pro 3, i5), so went over to a MacBook Pro (i7)...issue still occurs on that PC as well.
At my wits end trying to figure out what could be causing it.
Thank you so much!
There are several thing that could be happening here. Using an Azure SQL db would cause slower initial loading of pages (compared to a local db) because of the data transfer time. However, subsequent page loads should be quick because everything would be loaded into the site cache.
If subsequent page loads are still extremely slow then this could be because the XML cache isn't being generated. Check that the settings are correct in the web.config in debug configuration.
Also, check where you are writing your debug logging to. Umbraco will write log messages to a log file in App_Data/Logs/ and also separate logs to the database. Using a remote database would make these writes slower.
Without knowing what else is happening in your project it's difficult to know what other factors may be playing a part. But you need to step through the application in debug mode in VS and you can check the event viewer for swallowed errors like timeouts. Finally, you can use a profiler to pin point exactly where your issue is.
Annoyingly, when developing in MSVC2010, my EXE will not link (ie cannot emit output file) because the application experience service in Windows 7 has stopped.
I've no idea how these two things can be related, but i've been "fixing" it my manually restarting the process in the Windows service manager. Then i can link. At a random time later it will happen again. the process is set to automatic by default.
i've had enough of this madness. does anyone have any ideas? thanks.
Please try this: http://gauravpandey.com/wordpress/?p=291 it should work. it has atleast worked for me though I have not really understood the relationship between the two issues.
We have noticed that with the 2012 NetSuite Web services (and perhaps all other versions), when we make a call from a .NET 2.0 64-bit application, if the response does not come back quickly, then intermittently our application will hang however in the NetSuite application logs it appears the SOAP call was successful. The hang eventually times out (timeout) after 5 minutes (!) because NetSuite (or something) keeps the socket open, it just stops sending packets.
We ran a Network Trace and noticed packets coming out of order, being dropped, inexplicable duplicate acks - etc. Essentially, it "freaks out". Microsoft techs have never seen anything like it - least the ones I talked too.
We ran a simple test app that does nothing more than passport in, then do a query for Accounting Periods. It's the search method that hangs as it's parsing the SOAP response - always gets about 10s in.
As soon as we target a 32-bit environment, everything works like a charm, even though the 32-bit binary is running on a 64 bit OS. Clearly, running as a 64-bit app sets some network protocol configuration that NetSuite really doesn't like.
We tested on Azure, Amazon and on a local (to our corporate network) Windows 2008 R2 SP1 64 bit servers - physical and VM's.
We don't have hard evidence of the "why" this is happening, but after a month of pulling our hair out (we're all bald now) we think we've stumbled upon an issue. This one is so weird, however, I'm not willing to go out and claim that it's still not something we're doing. So, if you don't believe:
Open Visual Studio 2010 and create an .NET 2.0 console application targeting "Any CPU".
Do a "Add Web reference..." and add the NetSuite WSDL.
Create a simple passport login and do a search that returns something with some volume.
Run the EXE on a 64-bit OS, several times (this bug is intermittent), during peak working hours (i.e. appears around 7am - 2pm PST).
That's exactly what we did. If you go back and create a new x86 target and rebuild the project, it works fine.