I am getting weird issue when i change deployment environment to my old ASP.net application . I migrated my ASP.net application from IIS 7 (windows server 2008 ) to IIS 8 (windows server 2012) ,application is running very well on old server but on new server i sometime get weird timeout issue . i have searched for my problem but i think i am the first one who is getting this issue :( . I even cant figure out, is this issue related to IIS timeout /session timeout or SQL timeout .
Time-out has expired. The time-out period has expired before a connection was obtained from the group. A possible cause is that all connections in the group have been in use and the maximum group was reached.
It looks like you have an application that isn't properly closing or disposing of the SqlConnection objects. By default, SqlConnection has a max pool size of 100.
The fix here would be to work with the application to find out why connections aren't being cleaned up, as they are still "active" in the particular connection pool, which is why you are unable to grab another one, because there are no inactive connections in the pool to use.
The application should be making a call to SqlConnection.Close() or SqlConnection.Dispose() in order to release the connection and mark it as "inactive".
Related
InvalidOperationException: Timeout expired. The timeout period elapsed
prior to obtaining a connection from the pool. This may have occurred
because all pooled connections were in use and max pool size was
reached.
For some reason i usually get this error message once in awhile when testing locally
"DefaultConnection": "Server=(localdb)\\mssqllocaldb;Database=myDatabase;Trusted_Connection=True;"
Just when i pressed log in and where it does the check in database, it just takes forever until it gives me the exception with the error i just posted. Why does this happen? I think this hasn't happened on the production server yet or i just missed it, but would be nice to know why this happens.
I have an X-code app integrated with Mobile first platform 7.0. I want to implement idle session timeout for the app. I have tried two scenarios to resolve this issue.
First I have added below line in server.xml
<httpSession invalidationTimeout="10m" />
Second I have added below line in worklight.properties
serverSessionTimeout=10
I am still not getting time out after being idle for more than 10 mins.
What am I missing?
The serverSessionTimeout property is a server property. Meaning that the session expires in the server and if the client attempts to connect to the server after the set expiration time, then the client will act accordingly.
If you have a security challenge in place, then once the expiration took place, the challenge would've been invoked (once the client attempts to connect the server). Otherwise, you cannot detect this through this property.
What you can do, is set a "timer" on the client side that runs and counts until the session time has met, and do some logic based on it. This of course solely depends on what your required scenario is.
I have added the serverSessionTimeout=3 in the worklight properties file, I have edited this in the WAS server and restarted the application, but when i test the app and keep it idle for 3 mins, i cant see the server session time out automatically, is there anything we need to call on the mobile client to check if the server session time out is done or not. please help
Thanks
djrecker
Please look at the following documentation to get a better understanding of how the serverSessionTimeout and heartbeat property effect eachother as well as other tuning mechanisms:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fadmin%2Fc_optimizing_and_tuning_of_ibm_wl_server.html
Specifically the "Worklight Server internal configuration" section:
"Consider the following factors:
A session is an object that is stored in server memory for each connecting device. Among other things, it stores authentication information. The number of active sessions is the difference between the number of opened sessions and the number of sessions that are timing out because of inactivity. The serverSessionTimeout property configures the session timeout and affects the server memory consumption. The default session timeout is 10 minutes.
The mobile client "heartbeat" property causes the mobile client to ping the server while the app is in the foreground. This feature prevents the server session from timing out.
When a mobile app runs in the background, it no longer interacts with the server or sends a “heartbeat”. The server session drops after the specified server session timeout period.
For example, suppose every minute 1,000 users start a session against the server. Even if they exit the application after 3 minutes, their sessions remain active on the server for 10 minutes, leaving 10 x 1,000 = 10,000 active sessions.
"
You could try disabling the heartbeat using
WL.Client.setHeartBeatInterval(-1)
Maybe during the initialization of your app
Documentation at:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fapiref%2Fr_wl_client_setheartbeatinterval.html
With that the session timeout may work with the app in foreground too.
If the app is in the foreground, a heartbeat message will be sent
to the server and the session will not time out.
So the app should be placed in the background for the timeout to occur.
If that does not help, please try the test for a period of 10 minutes,
as this is the default session timeout value.
Normally the value of the serverSessionTimeout is greater than the
heartbeat interval so that the session is kept alive when idle and
as long as the application is in the foreground.
So as long as the app is in the foregraound,
by design it will never invalidate the session.
But on the other hand, if it is backgrounded then there are no heartbeats
and then past the default 10 min in the background state, the session
is invalidated. This is the intention here.
I have a web service application which connects to databases through odbc sql native client and SQL Server drivers. all of a sudden the application stopped connecting to the database throwing the error 08001. But when i did the application pool recycle it started working. Now it is happening intermittently and became a headache for me. It cant be a memory problem as it happened immediately after app pool reclycle once. but agian got corrected after one more app pool recycle. i dont know what is happening as none of the error logs give any clue:(. Please help me...
the first step is to be able to diagnose what is going on. You cannot fix what you cannot measure. To do this I would enable pooling in the data source console for the driver, then add the counters to the performance monitor to see what the connection pool is doing.
I'm not sure what the realtionship between IIS applocation pool processes and odbc connections is but we are seeing some unexpected behaviour in this area. Also the odbc connection performance counters are visible if I connect to the driver through a locally installed console application but I cannot see any performance counter activity for connections made via the web service app pool in IIS? ODD!?
The setup is as follows:
A C++ client connects via OLEDB/SQL Native Client to a SQL Server 2005 database located on another machine. The server is setup with mirroring (automatic failover) with a synchronized server located on yet another server and a witness server on another server.
Occassionally (once every couple of days), our application seizes up in that it appears to attempt to establish a database connection to the database and rather than simply failing and OLEDB throwing a database connection failure it just gets "stuck" (we have a timeout for the connection but it's never timing out). 24 to 36 hours later we'll get an error:
TCP Provider: An existing connection was forcibly closed by the remote host.
And things will continue you on with lots of these errors and our app will eventually need to be restarted. We can't really figure out what condition could be causing this behavior and what we can do about it?
In preliminary research, I've seen some related problems that were solved by setting the Connection Lifetime connection string property to something non-zero.
Does anyone have any thoughts on what might be going on here?