I have an ASP.NET application that is using Entity Framework 6 to access data stored in an Azure SQL database. I've run into a bit of a problem connecting to the database as a whole.
If I spawn a new database instance on Azure, start my app in the debugger and step through it, I'll see that it connects without a problem, can access the seed data and all is well (inserts work without a problem, but this occurs whether I change the data or not).
However, if I restart the debugger and at all points after that attempt to connect to the database when my app restarts, the connection will fail. If I set a breakpoint and look at the Context value in the Locals window, I have the following error as the value for all DbSets:
Function evaluation disabled because a previous function evaluation
timed out. You must continue execution to reenable function
evaluation.
Despite having a try/catch around the logic, no exception will be thrown. If I step into/out of/over this, the application will just run indefinitely and never complete.
If I do a rollback to the $InitialDatabase and then re-apply the automatic migration (via update-database), I still cannot connect to the database, however if I delete the database in Azure, spin up a new one, set up the new connection information in the Web.config file and execute all over again, it'll work like a charm one time. After that, it'll fail to work again, despite no other changes to the application.
What's going on here and why is this behavior occurring? If there's an underlying problem here, how could I tell what it is and how can I resolve it?
Thanks!
After making no headway, I rolled-back to a previous version of my code from when it was working fine about three weeks back. I've updated all the logic to match what was in the latest build, I just haven't updated any of the assemblies yet. It's working perfectly fine and connecting every time now, so apparently this is the fault of one of the as-of-yet unidentified dependencies.
If I ever determine which one, I'll update this answer accordingly.
Related
I have a Spring Boot application with Mongo DB, which is deployed on Azure.
Now if I do not call the API for a long time, maybe some hours and call it my first call always fails with the exception attached. But then it starts to work fine. It seems that the database goes into an idle mode and then whenever the query is made for the first time it is still sleeping hence the error. Is this understanding correct? How to fix it?
Yes, your understanding is correct i.e, the database goes into an idle mode and whenever the query is made for the first time it is still sleeping hence the error occurring.
The above exception is due to the connection timeout.
It closes the connection because of passing the maximum connection idle time.
You will need to set this property according to your requirement.
maxConnectionIdleTime
This can be set either on your Mongo configuration or application profile.
I have built and started an OPC UA embedded Openmodelica server with the BouncingBall model like so:
$ omc +s path/to/model
$ ./BouncingBall -embeddedServer=opc-ua -rt=1
Now I'm trying to interact with it using an OPCUA client. However, I don't understand how I'm supposed to interact with the server properly. As far as I know this is undocumented.
The most promising approach seems to be to set enableStopTime to false and run to true. Then the simulation seems to run indefinitely and the values seem to make sense. It seems I'm only able to extract the values in real time however. While running, when I set run to false it seems that the server enters an erroneous state and it refuses to give any values back.
If I restart the executable and instead set step to true nothing seems to change and after trying to set step to true a second time the server becomes unresponsive. The -rt=1 option doesn't seem to matter. Seems like it enters the same state as above (1).
(After restart) If I leave enableStopTime to be true and set run to true the simulation runs to stop and then the server quits with message The simulation finished successfully. Maybe this is intended. Kind of seems odd. Would make sense to be able to restart the simulation or trigger it with new options.
What I would hope to be able to do: Start and stop simulation as well as rewind to a certain point to check the value at that point. It seems to me that the API "affords" this functionality and it could probably be provided by hackingly wrapping the executable and API. Are the above bugs or intended? What is the intended way to interact with an OPC UA server in these cases?
The OpenModelica compiler version is 1.16.0~1-g84b4a71
Please try the latest nightly build
It includes the following commit.
That might solve it. I believe things worked without subscriptions before, since I could never reproduce this without them.
(By the way, do people go on our git commit feed and try to reproduce bugs fixed in the last 24 hours; we quite often get questions that were just recently fixed)
I have an app that checks for an sqflite db file in the app storage directory and if it is present, blows away the file and creates a new one and then opens it for the remainder of the app life. What I have noticed is that hot restart fails with sql exceptions because it still sees the database as open somewhere in memory even though all my references are blown away due to the restart. This seems like a bug because I have no way to control the closing of that database unless I try to make sure it is closed if the application is killed. Is this by design? Is there a standard way to approach it?
I noticed this related post
Your assumption and investigation are correct. With bad words, what happens during hot restart is that the dart environment is restarted while the native world is still running and for sqlite that means that open databases remain opened with no easy way to know that from the dart side.
The hot-restart hack in place in sqflite is meant mainly to handle hotrestart even if you are in a sqlite transaction. Without this hack, it should happen what you describe in your scenario. That is said deleteDatabase should be used instead of removing manually the file.
In theory, this should be handled in openDatabase and deleteDatabase.
Can you confirm that you are indeed using deleteDatabase? If yes, in the mean time your workaround is safe and reporting an issue on sqflite for investigation would be great. Thanks!
After further testing it looks like 1 way to handle this is to check for the existence of the file. If the file exists, go ahead and open it using sqflite's openDatabase method. Then immediately close it. Then delete the file using io file delete method. Then you can create a new database file using the openDatabase method. This solution is maybe a little more expensive than I had hoped but it is working.
I have a WCF Windows Workflow (4.5) Workflow Service hosted under IIS and using AppFabric 1.1. The workflow instances are long-running (up to about a week), but much of the time is spent in Delay activities.
This seemed to work fine at first, but when running multiple instances of the workflow at the same time (2+ instances causes this), some of them just never wake up once they've unloaded from memory during the Delay step. When I look at the logs, the errors I find all look like this:
System.OperationCanceledException: The execution of InstancePersistenceCommands has been canceled because the InstanceHandle was freed.
at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Activities.Dispatcher.DurableInstanceManager.WaitAndHandleStoreEventsCallback(IAsyncResult result)
Unfortunately, I'm not finding any useful information on that error message.
The SuspensionExceptionName and SuspensionReason fields in the AppFabric Persisted Instances Table show System.NullReferenceException: Object reference not set to an instance of an object. But this doesn't happen inside my workflow, only outside.
Additional Info:
I'm running the activity as a Fire & Forget (receive activity, no send)
My workflow calls into other WCF services to fetch data.
I am running this on Server 2012 R2, IIS 8 (not azure)
Workflow Persistence is working. I can reset IIS, reboot... its just when I run 2 instances that it has problems.
I'm definitely not hitting any kind of throttling limits. While the workflow deals with a few MB of data, this issue happens at 2+ instances.
Any idea what might be happening here?
Edit:
I realized I found more information on how the issue operates and never added it to the question. When the delay issue happens, it operates a lot like a static variable getting written by 2 threads.
Here's a visualization:
WF1 Start ---->Do Stuff--->Sleep------------*1----->Cancelled Exception at some point
------WF 2 Start---->Do Stuff------->Sleep->Wake up---------*2------>More Stuff---->End Successfully
*1 - When WF Instance 1 Should Wake up (Same time as WF 2 wakes)
*2 - When WF Instance 2 Should have woken up (Seems to be ignored)
Before anyone asks... I got rid of every static variable, method, class in my code. Nothing is static anymore.
I've been struggling with similar issues for quite a while. I use WFW4 and I find similar errors when a workflow instance is in a long delay.
I don't know what the cause of the problem is, but I have a work around that you might find helpful.
In my case, the errors I get are from Workflow Management Service and say:
Failed to invoke service management endpoint at 'net.pipe://.svc' to activate service '/Alerts/Workflows/.xamlx'. Exception: 'Access is denied.'
These errors start happening sometime between 6 and 30 hours after the instance goes into a long delay.
I have found that if I create a new instance of the workflow when the first instance is in delay and the errors are happening, then Workflow Management Service is able to resume interacting with the first sleeping instance.
So, I made a new workflow whose sole purpose is to periodically launch and then kill instances of the workflow that contains the long delay.
It actually gets a bit more complicated to make this work. I wanted this new workflow to also go to sleep between times when it creates and kills a new instance of the first workflow. But this going to sleep causes the instance of the new workflow to suffer the same problem as the first workflow. So, I modified the new workflow so it does the following:
-- delay for some rather short period, such as 30 minutes
-- create an instance of the first workflow
-- wait a minute
-- kill the just-created instance of the first workflow
-- create a new instance of this new error-preventing workflow
-- terminate
Since having done this, I no longer get the Access is Denied error from Workflow Management Service!
Hope this helps
Turns out my first answer was not correct, but I believe this answer is right, and solves the issue ChrisG is having.
My workaround did not actually work. Took a while for the problem to resurface. 29 hours to be precise - the default time it takes for an app pool to recycle.
So for me, the solution was to make my app pool not recycle. When an app pool recycles while a workflow instance is in a delay activity, the workflowManagementService is not able to wake up the instance and throws Access is Denied errors. If you create a new instance of the workflow after the app pool has recycled, the first instance will pick up where it left off, but sometimes still has problems, which is what I believe is happening to ChrisG.
ChrisG, looking at your visualization, is it possible that an appPool is recycling during the time wf1 is sleeping? I believe that is the cause the exception. If you then launch a new wf instance after *2 has passed (and if an app pool recycle happened prior to *1), that will wake up both wf1 and wf2, but wf1 won't work properly (at least in my experience)
Also, this happens after iisresets and server reboots. To handle those, you need to use IIS7 which allows the web application (as well as the web site) which is hosting the xamlx files to autostart after an iisreset or server reboot. This option is not available in IIS6. See http://www.postseek.com/meta/991815402b369e71ce925cde47ac907d for details
Hope this helps!
I recently upgraded an application from .net 3.5 to 4.0. Since I did that, with debug settings to break on all exceptions enabled, I've been getting a few of these exceptions each time I start a section of the application that connects to a database using the EF. The exact number is variable; sometimes I only get one, others several in rapid succession.
ReleaseHandleFailed was detected Message: A SafeHandle or
CriticalHandle of type
'Microsoft.Win32.SafeHandles.SafeCapiHashHandle' failed to properly
release the handle with value 0x06AD3D08. This usually indicates that
the handle was released incorrectly via another means (such as
extracting the handle using DangerousGetHandle and closing it directly
or building another SafeHandle around it.)
I never got exceptions like this when targeting 3.5. These exceptions don't have any meaningful call stack attached, all I get is [External Code], denying any easy way to localize where they're coming from. The reason I suspect EntityFramework is somehow involved is that one section of the app uses nHiberate instead doesn't generate any of these messages.
To run down other dependencies that might be involved: In all cases, the ORM is talking to an Sql Compact database MS Sync Framework 2.1 is being used to update the local DB from SqlServer. The Entity framework models have been regenerated with the 4.0 framework, and I upgraded the cache DB to v4.0 as well.
Since there's no call stack I'm not sure if these messages fall into the category of "harmless" errors automatically cleaned up internal to the framework; or if there's an exception eater catching them elsewhere in the application.
This is not an exception, it is a Managed Debugging Assistant warning. You might have gone over-board a bit when you changed the settings to "break on all exceptions enabled". Debug + Exceptions, Managed Debugging Assistants node, untick the "ReleaseHandleFailed" warning. It is off by default.
The MDA catches an old bug that's gone undetected for a while in the AesCryptoServiceProvider class. Backgrounder is here.
Judging from your comment, you are about to make a drastic mistake. You do not solve this by avoiding encryption or compromising your dbase connection security. You accidentally turned on an MDA that's normally off. MDAs in general tend to produce false warnings and many of them are turned off by default. The warning is in fact bogus, releasing the handle failed because it was already released. This happens in the finalizer thread, that's why you don't get a stack trace. And thus can't easily find out what code uses the class in the first place.
The proper way to fix it is to use the Debug + Exceptions dialog properly. Fix the problem you created by clicking the Reset All button. Then click only the Thrown checkbox for Common Language Runtime exceptions. That's what you are trying to debug.