I'm having a bit of a problem where in the HttpContext.Current.Session object appears to be being destroyed between page requests and posts. I'm a bit confused as in my development environment this isn't a problem yet in a stg environment it happens.
Now I have checked all of the common problems and so far nothing seems to resolve the problem. Both dev and stg environments are the same (same iis, same versions of .net, same os and configs, all patches upto date). The web.config also matches up in both environments and the sessionState is set as follows:
<sessionState mode="InProc" timeout="15"/>
On top of this all pages that require the session context all inherit from
IRequiresSessionContext
To be sure I've also checked the IIS setup and have confimred that SessionState is enabled on the application as well.
At a loss, and no more hair to pull out.
I've run into this issue before, check the Windows Event Log to ensure that the Worker Process is not being forced to recycle.
There may be something in your code that causes the Worker Process to force itself to recycle or crash in which case when the session is stored inProc it will loose all session values it's holding.
Related
So, I have recently acquired a new project: meaning I cannot answer any design decisions. I'm supposed to put some finishing touches on this app. Before I get with my BA to discuss time estimations I thought it would be prudent to familiarize myself with some code and walk through some breakpoints to give better estimates for the new release.
The problem? I can't run the app.
I get
"An invalid or incomplete configuration was used while creating a SessionFactory. Check PotentialReasons collection, and InnerException for more detail."
Inner exception is {"Login failed for user 'domain\computername$'."}
This app seems to require being hosted on a local IIS to run locally, so I added the windows feature and enabled windows security. I confirmed to make sure that this is not an intentional part of the design.
<add name=name connectionString="Data Source=localhost;Initial Catalog=dbName;Integrated Security=SSPI;"/>
Obviously the database I'm pointed at has changed due to the localhost, but still shouldn''t be trying to hit anything with the computer name.
Integrated Security should pick up on your Windows identity (ie, your user name). Check the application pool of the web app. Under Advanced Settings you can change the identity that the application runs under (normally ApplicationPoolIdentity). Maybe that is set to your computer name. That is the only thing that makes even remote sense.
We have scaled-out some portions of our ASP.NET app to run on one server, and other portions to run on another server (& under a subdomain).
The two servers share (SQL Server) Session. We used this MS article to create a tiny HTTP Module to sync app domain name between the two servers (sans the cookie domain code, which can be configured in the web.config. I later found this CodeProject article which is essentially the same.)
Everything's working well, except for a small issue: deployment changes or web.config tweaks require a manual app pool recycle (the auto-recycle no longer works - instead we get the "web server is currently unavailable / hit refresh" error).
I tried moving the app domain naming code from the HTTP Module into the Application_Start section of the Global.asax (maybe this is a better place for it?) - but received the same problem.
I know that one solution is to hard-code the app name in one of the SQL Server Session stored procedures; but am a bit hesitant to do this.
Edit: The app is ASP.NET 3.5 under IIS 6.0 (thanks #Chris & #bzlm)
You should check if proper Recycling Events are turned on in IIS, maybe this can help http://support.microsoft.com/kb/332088
Update. We opened a tech support case with Microsoft about this. After a week or so of back & forth, they said they had reproduced the issue in their environment and understand the cause (a timing issue deep inside the ASP.NET internals) - but that there is no resolution that they're aware of. I complained that the HTTP module is Microsoft code, but they said that this code is under "FAST PUBLISH" terms - intended to help & advise customers; yet not warranted.
Ah well. We now just manually recycle the app pool after making a web.config change.
I'm not sure if something odd is happening or if this is normal, but since framework 4 when I create a new site on our IISv6 install I used to get a message saying that changing to framework 4 would cause IIS to restart (but this has gone away since a few updates ago), I think it still restarts the server when I change the framework, just no warning any more. So I did a bit of investigation and wrote a script that allowed me to switch the framework version without doing that.
#Echo Off
set /p id=Enter Site Instance:
echo %id%
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis -norestart -s W3SVC/%id%
pause
The problem I now have occurs when I change the app pool on any given web app; it appears to cause the other app pools (including the one I add to) to refresh.
I have sometimes had instances of a switch causing every app pool to stop, and then I have to restart them all again which can cause a bit of downtime. I have taken to only release new sites early in the morning or at the end of my work day, so as to avoid as much disruption as possible, but I dont see why something like this should be happening.
The setup I have is one app pool for test, one for live and one for the admin site, but when I change a site from test to live, it will causes all the app pools to become affected.
Can anyone tell me if this is something that always happened with previous versions of the framework and if there is a possible work around, for example can I script the app pool switch without affecting any of the other app pools
Edit 2011-08-01
found this article: http://msdn.microsoft.com/en-us/library/k6h9cz8h%28VS.80%29.aspx,
which mentions a script called iisapp and looks like it might do the job, will investigate more.
Found the answer on this site: http://forums.iis.net/t/1152572.aspx
using a vbs in adminscripts called adsutil (not the iisapp as I thought...) you can write the following in a batch file.
#Echo Off
set /p id=Enter Site Name:
echo %id%
CD /D C:\inetpub\AdminScripts
Cscript.exe /nologo adsutil.vbs set W3SVC/%id%/root/apppoolid [APP POOL NAME]
I am currently experiencing some instability in my session variables and believe the app pool is where the error is coming from. What I cannot find is a list of possible culprits for the issue. What can cause the app pool to recycle on its own, other than a scheduled recycle?
Common reasons why your application pool may unexpectedly recycle
EDIT: Full Text in the event that the link goes 404:
If your application crashes, hangs and deadlocks it will cause/require the application pool to recycle in order to be resolved, but sometimes your application pool inexplicably recycles for no obvious reason. This is usually a configuration issue or due to the fact that you're performing file system operations in the application directory.
For the sake of elimination I thought I'd list the most common reasons.
Application pool settings
If you check the properties for the application pool you'll see a number of settings for recycling the application pool. In IIS6 they are:
Recycle worker processes (in minutes)
Recycle worker process (in requests)
Recycle worker processes at the following times
Maximum virtual memory
Maximum used memory
These settings should be pretty self explanatory, but if you want to read more, please take a look at this MSDN article
The processModel element of machine.config
If you're running IIS5 or the IIS5 isolation mode you'll have to look at the processModel element. The Properties you should pay the closest attention to are:
memoryLimit
requestLimit
timeout
memoryLimit
The default value of memoryLimit is 60. This value is only of interest if you have fairly little memory on a 32 bit machine. 60 stands for 60% of total system memory. So if you have 1 GB of memory the worker process will automatically restart once it reaches a memory usage of 600 MB. If you have 8 GB, on the other hand, the process would theoretically restart when it reaches 4,8 GB, but since it is a 32 bit process it will never grow that big. See my post on 32 bit processes for more information why.
requestLimit
This setting is "infinite" by default, but if it is set to 5000 for example, then ASP.NET will launch a new worker process once it's served 5000 requests.
timeout
The default timeout is "infinite", but here you can set the lifetime of the worker process. Once the timeout is reached ASP.NET will launch a new worker process, so setting this to "00:05:00" would recycle the application every five minutes.
Other properties
There are other properties within the processModel element that will cause your application pool to recycle, like responseDeadlockInterval. But these other settings usually depend on something going wrong or being out of the ordinary to trigger. If you have a deadlock then that's your main concern. Changing the responseDeadlockInterval setting wouldn't do much to resolve the situation. You'd need to deal with the deadlock itself.
Editing and updating
ASP.NET 2.0 depends on File Change Notifications (FCN) to see if the application has been updated. Depending on the change the application pool will recycle. If you or your application is adding and removing directories to the application folder, then you will be restarting your application pool every time, so be careful with those temporary files.
Altering the following files will also trigger an immediate restart of the application pool:
web.config
machine.config
global.asax
Anything in the bin directory or it's sub-directories
Updating the .aspx files, etc. causing a recompile will eventually trigger a restart of the application pool as well. There is a property of the compilation element under system.web that is called numRecompilesBeforeAppRestart. The default value is 20. This means that after 20 recompiles the application pool will recycle.
A workaround to the sub-directory issue
If your application really depends on adding and removing sub-directories you can use linkd to create a directory junction. Here's how:
Create a directory you'd like to exclude from the FCN, E.g. c:\inetpub\wwwroot\WebApp\MyDir
Create a separate folder somewhere outside the wwwroot. E.g. c:\MyExcludedDir
use linkd to link the two: linkd c:\inetpub\wwwroot\WebApp\MyDir c:\MyExcludedDir
Any changes made in the c:\inetpub\wwwroot\WebApp\MyDir will actually occur in c:\MyExcludedDir so they will go unnoticed by the FCN.
Is recycling the application pool really that bad?
You really shouldn't have to recycle the application pool, but if you're dealing with a memory leak in your application and need to buy time to fix it, then by all means recycling the application pool could be a good idea.
What about session state?
Well, if you're running in-process session state, then obviously it's going to be reset each and every time the application pool is recycled. If you need to brush up on your state server options, then I recommend taking a look at this entry.
I have a client-server application, in which the client communicates with the server using WCF (WCF is used both in the client and the server).
My problem is, that instantiating the auto-generated proxy in the client, in the following way:
new Service1Client() takes constantly 15.xxx seconds.
I tried to solve this problem, and came to the following results:
1) Compiling and running the same code on other computers, ends up in the same way (always 15.xxx seconds).
2) Instantiating the proxy using ChannelFactory.CreateChannel< IService1 >()
doesn't help (it gives the same result).
My guess, is that whenever the channel factory creates a channel, it tries to do something with a 15 seconds timeout, and when it fails, it continues with creation.
By the way, I use .Net 3.5 without SP1, and cannot upgrade to SP1 :(
Thanks ahead
Even though it is already outdated, it may be useful for somebody else searching for the same. Problem could be with DNS resolution problem, that might be solved in SP1. So you can check if it happens only when you use host name or also with specified IP address.
I've seen this before, where the time was being taken in looking for a proxy server. Check your WinINET (Internet Explorer) proxy settings.
My specific reason for thinking "proxy server" is that it takes 15s. 15s sounds like a nice round number for a network timeout.
Even though this is very old information I just found this issue too although I was experiencing a 7second delay on the First call to a method on the Service Client, I tracked it (in my environment) to Internet Explorer settings as stated above, but in my circumstances it wasn't a Proxy enabled, but the Automatically Detect Settings.
Connections -> Lan Settings and Automatically Detect settings was enabled.
I played with the machine.config and app.config and set
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
Which also made no difference.
I found this answer here and thought I'd contribute a little more information in case someone else in the future experiences something like this.
(This with a .Net 4 WCF service)