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.
Related
I'm currenty using postgres as my database engine, which i've hooked up to a web application.
I'm have noticed on some occasions that there are locks that get accumlated in the database, mainly AccessSharedLocks (when running the query: select * from pg_locks).
One thing I have noticed is that to cancel a process that is acquiring a lock you can use pg_cancel_backend(pid), but sometime i realise that this doesnt always work!! And i'm curious to know why. Is it that this function sends a SIGINT to the database to shut it down gracefully? meaning that it wont shut it down immediately?
There is pg_terminate_backend, but i prefer to not use this.
Any advice on why pg_cancel_backend intermittently works (or at least some explanation) would be grateful).
thanks.
pg_cancel_backend and pg_terminate_backend send signals to the process.
The backend checks ever so often for pending interrupts, but it can happen that execution is in a place where it takes a while until that happens.
Canceling a query won't get rid of the locks until the transaction is closed.
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.
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!
Database is locked: Is this only comes due to not finalised or close Db statements missing?.
Actually I am using db access in background as well so my some other methods can be access db at same time.
Can anyone please let me know when Database is locked and when database is busy issues comes.?
My prepared statements is execute and not an error in database but still unable to get data?
Any Help?
Database is Locked error comes when you are using the same database in some place else maybe another application by getting the lock on it and the application is still not released the lock on database.
I dont know about database is busy error. this link might answer your question SQLite Exception: SQLite Busy
Hope it somehow helps you.
The sqlite_busy can come in these cases
1. When one thread has locked a database using BEGIN and another thread is trying to write to the same database.
2. When a particular row is being updated by one thread and the same row is being read by another thread.
In both the cases install a busy handler to the database. The busy handler should attempt the execution of the statement after few milliseconds.
After I close my application fbclient.dll remains in memory for about 3 seconds. So it locks the database file and prevents my application from unloading. I'm using Firebird embedded.
The problem is related to events. I signup to events using isc_que_events. If I don't signup to events dll unloads instantly.
I faced this problem in previous FB versions and now in 2.1.3 it's still the same.
The same issue is described here http://tracker.firebirdsql.org/browse/CORE-15, but it's resolved as "Cannot Reproduce".
Is anybody facing this problem or there's something wrong with my code?
Are you using the .NET Provider? This one keeps connections open in a pool, maybe this is the problem. Try clearing the connection pool before exiting your application:
FbConnection.ClearAllPools();
I've rewritten my logic and now I don't need to subscribe to local events. So it's not a problem for me anymore. But the issue still remains.