I have an MVC4 application hosted on IIS in my local system. The application provides the search capabilities by using various Searchblox API. I have stored the host server value in my web.config. Now while my application is running and I change my host value say from "https://xyz" to "https://abc" in my config then for some places the correct value is fetched but for one call the old "https://xyz" is fetched.
I perform the below steps in sequence:-
Hit my application page from IE.
App executes successfully.
Open Web.config in VS to switch the host value.
Save the config file. (Now as per my knowledge this should have restarted the appdomian consisting my app and should have brought the new value)
Hit my application again in IE.
Watch the internal calls in Fiddler. All API calls are now made to new "https://abc" but one call is made to "https://xyz".
This behavior works fine if I recycle the Apppool containing my application.
Someone, please explain why this might be happening and how can I make sure that my application always pick the new values for every call?
This was happening because we were caching the previous host value in order to use it if the new changed host API fails to establish a connection. This was completely app specific.
Related
First of all, we have a MVC web application which uses NHibernate (version 3) and an Oracle 11g database.
The application is working, but when we publish in the production server a curious scenario happens:
The user access the application and perform a task, for example, select a link into the Menu.
The user waits a couple of minutes (2-3 minutes).
The user perform another task, for example, reload the same page or select another link into the Menu.
The application fails with a ORA-12571: TNS:packet writer failure exception.
The user just refresh the error page, the application works.
The first thing we tried to do was to isolate the problem, so we published the application into another server with the exactly same configuration:
Same binaries, of course.
Same Oracle x64 client version, even the minor version.
Same Windows Server 2008 version with IIS 7.5.
Same IIS configuration (we compared the windows/system32/inetsrv/config files using WinMerge).
Accessing the same production database.
And for our surprise we couldn't reproduce the problem.
Please, someone have a clue of what is going on?
The problem is related to the connection pool of the server's oracle client. It seems that it is delivering invalid connections to the web application, while in the other servers it does not happens.
The solution is not very interesting, but putting the Validate Connection = True inside the connection string resolved the issue. I am aware of the performance penalty of this, but I am out of options.
PS: using this flag, each connection is validated by the connection pool service before delivering it for the client application. This is not very nice, since a database round-trip will happen for every connection request.
I have an asp.net web application running on an IIS 7.5/.NET Framework 4.0 server. Whenever I navigate to any webpage running on this server, it takes about 12 seconds to initially load. After that, navigation is quick (about 0.5 seconds, even on heavy hitting pages). If you leave it idle for two minutes, it slows again for the next request. I can tell that this is because the connection time-out is set to 120 seconds...I am guessing that after that limit, the site must reload everything when the next page is requesting. This site does call two different databases, however, default page should not do so and suffers the long initial load time. I have tried setting up Application Initialization for IIS 7.5, but noticed very marginal change at best after this was done. From what I've been reading, there seems to be very mixed success with this module in IIS 7.5. Is there any other means of circumventing this load time without having to rely solely on a high connection timeout value, since that would not resolve initial load time anyway?
When a WebApp is idle for along time IIS will close the application to save resources. This might have happened in your case.
Its also said that the application would turn off if the last user session timed out. I hope this article will guide you properly.
Look at what happens when the request gets to the runtime.
When ASP.NET receives the first request for any resource in an
application, a class named ApplicationManager creates an application
domain. (Application domains provide isolation between applications
for global variables, and allow each application to be unloaded
separately.)
Within an application domain, an instance of the class named Hosting
Environment is created, which provides access to information about
the application such as the name of the folder where the application
is stored.
After the application domain has been created and the Hosting
Environment object instantiated, ASP.NET creates and initializes
core objects such as HttpContext, HttpRequest, and HttpResponse.
After all core application objects have been initialized, the
application is started by creating an instance of the
HttpApplication class.
If the application has a Global.asax file, ASP.NET instead creates
an instance of the Global.asax class that is derived from the
HttpApplication class and uses the derived class to represent the
application.
See How it happens
Was not related the connection timeout as I thought it was, but rather another timeout and necessary files missing. Per Zerkey's question in the comments above, I got a little curious and looked around for ways to see what was loading, as debugging it from my PC was still slow, but considerably faster (about 4-6 seconds). In IIS on the server this is published to, I went to Worker Processes, selected the process and clicked current requests on the right. This showed me that it gets hung up on a 3rd party mobile redirection service I am using called 51degrees.mobi. It was taking about 10 of those 12 seconds for those file to load. What was happening is that the logging capabilities were set to log in an App_Data folder, and that directory was missing. It evidently wasn't giving me a visible error, it was just trying it and failing. Once I added this directory and log file, and reactivated Application Initialization, everything is quick.
We have a .net web application that is running in IIS7.5 on an application pool that is set to run with a domain level AD account instead of the default account.
It has been configured according to these instructions:
http://support.microsoft.com/kb/813834
to use
myProxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
so that the credentials the pool is running on are passed to the web service.
This works in my test VM (which may have had other settings modified in the past)
Deployed on our Dev Server, the same code does not work.
I know the Web Service isn't the culprit because the IIS log shows no Account info passed to the webservice call, but if I point my test VM to the webservice on the server it works and does.
Is there a configuration/permission thing I'm missing somewhere?
Any pointers?
Edit: Learned some more. Event Viewer is showing audit failures with NULL SID for this account, even though from the VM the SID comes through correctly.
Thanks!
Got it! So the NULL SID led me to the right place:
This is because of a "working as designed" feature with windows.
read was MS has to say about it here:
http://support.microsoft.com/kb/896861
Registry change option #1 fixed it.
I have a asp.net website that is deployed on two servers. In front of the servers there's a load balancer that distribute requests to the two servers. To store the session we use SQL Server.
My problem is that if the user go to the page, press a button and then by the load balancer happens to be routed to the other server that request wont be recognized as a postback? Why is that, shouldn't it work just fine even with postbacks as long as the servers share the same machine keys?
Details:
Both servers have the same machine key configured, and I verified that the actual session is the same on both servers by a small debug page I made that sets and prints out a session object.
To further verify the keys and Id I printed out the values of HttpRuntime.AppDomainAppId and a hashed machinekey (MachineKeySection)ConfigurationManager.GetSection("system.web/machineKey") and the sessionId Session.SessionID and got the same output on both servers. I used Session Debug page as a base for this. Its output looks something like this (I replaced my actual machinkey hash and session id with dummy values):
Current DataTime: 2012-07-20 10:52:58
Current Session Mode: SQLServer
HttpRuntime.AppDomainAppId: /LM/W3SVC/5/ROOT
Hashed with the MachineKey: HjtOPW5dfoihdlkd+SdsfkEWfs0=
Local Machine Name: 127.0.0.1
Current Session ID: 2alsudhsdkjlhcmnsdfkhsdf
The ID for the site, found in IISMgr under Advanced Settings on the site is the same on all servers.
As long as I stay on the same server everything works as expected.
When I run the page locally (first request to web farm, then route second button click to localhost by fiddler), I get the same behaviour
Stepping through the code and reading up on the IsPostBack property it seems my problem is that this._fPageLayoutChanged on the Page is true. However, if I understand things correctly it should be false when a postback happens? SO Question on its implementation
Both servers run IIS 7.
Both servers run Windows Server Web with SP2 and the same windows update updates installed. My local dev machine on the other hand runs Windows 7.
Turns out that adding a manual entry of the Machinekey in the web.config fixed the problem. Very strange as I checked its global value and also the hash as detailed in the question but now it works.
I take that back. After our last release the problem is back, so the machinekey addition did not help at all.
I am seeing a very strange problem on one of my production boxes. We have an application hosted in IIS 6 on a single machine with an apache web server in front of it. My application is using ASP.NET Membership for authentication and relies on session state. I am seeing a problem right now where some server requests will hit a null exception when trying to access any session variables, but if the request is retried, the page hits no exceptions and behaves properly.
I believe this has something to do with the Session ID cookie either getting corrupted or lost on the request, but I have no idea what could cause that. The reason I believe this is because it seems like ASP.NET is not seeing the cookie and creating a new session, which would explain why the variables are null. When it gets the exception, it cannot write the new SessionID cookie back to the client, so the client still maintains the original SessionID. Then when the next request is sent, the original SessionID cookie is used, which now ASP.NET finds and is able to retrieve the session state. This is pure speculation, but seems to fit the symptoms.
Also this site is using no other cookies other then the ones required by ASP.NET Membership and ASP.NET Session, so I am well under the cookie limit for IE. The site has been functioning properly for about 8 months and this issue just popped up recently. I have tried IIS resets and actually rebooting the machine, but nothing has seemed to help the problem.
Updates:
Here are some clarifications that were asked for.
1.)Our Apache server is the only thing exposed to the internet. All requests occur over HTTPS to this box. The Apache box then forwards all request past over HTTP to our application server. This is being done for security reasons. We have looked to see if Apache might have been the issue, but there seems to be no error in the Apache logs.
2.)The null exception is occurring when trying to access an object stored in session that the application expects to be there as opposed to the exception happening with the actual session object itself.
We have found the root of the issue. It looks like the IIS meta-base got corrupted on our app server. The best way to fix this issue is to do a clean install of IIS, but because of business constraints, this is not an option for us. So another solution is to actually just create a new App Pool for the application to run under. According to some people with more IIS expertise than myself, this will fix the problem in the short term, but it is very likely that the same thing will happen to this App Pool. So we are required to create new App Pools if this starts occurring again.