We have a very strange problem that we are dealing with.
We have an MVC 3 application that we are still developing, and on Monday we began to encounter a problem with four specific routes (methods) in one of our controllers. All four of these routes are used in role management and deal with creating or editing roles. We have two different levels of roles in the application, so there are two ways to create a role for each level and two routes for editing a role for each level. Both methods for the corresponding creation routes invoke the same view, as well as two methods for the corresponding editing routes. Both views call the general partial view, which contains the form fields corresponding to the properties of the created or edited role.
Here is the problem.
If I try to use these routes without starting the debugger first, IIS will hang. It will not fail, issue an error, or even log the request in the IIS log.
HOWEVER, if I try to access these routes in the debugger, regardless of whether I have a breakpoint or not, the routes work as they should.
To make life more interesting, if I try to access the same routes AFTER I started and turned off the debugger, the STILL routes function as they should.
We can reproduce this behavior on EVERY machine in our development team and our intermediate server (with the exception of the debugging part during production).
The methods matching all of these routes rely on several methods in the same mid-level web service on their own. These methods work correctly outside the debugger in our integration tests.
We checked the infinite loops in the code, but cannot find anything that would create an infinite loop under these conditions. In fact, there is only one cycle in the general representation, but it is for each cycle, which should never lead to an infinite cycle.
Finally, when I try to hit any of these four routes without starting under the debugger, or at least starting it on a previous request, IIS essentially freezes. This will not be a timeout. This will not result in an error. It will not log an error in the IIS log. Finally, it will consume system resources that need to restart IIS or restart the entire machine.
Has anyone ever seen this behavior before? Any ideas on how to get around this? I have NEVER seen this behavior before, and the only thing that anyone in our development team could offer was some kind of file permissions problem, but we do not access the file system (outside the presentation files themselves, and they have corresponding permissions) at any time during the processing of these methods.
I am open to all suggestions.
UPDATE # 1:
I also posted this question on ASP.NET forums, and someone asked me a question for more information. Here is my answer to their questions.
What kind of IIS are we talking about?
IIS 7.5. We use full-fledged IIS, not IIS Express.
What mistake?
That's all. There are no errors. No error messages are reported. In fact, the request itself is not written to the IIS log for the site if we try to access these routes without the debugger working. If the debugger works, everything works as you expected.
VS Cassini?
Nope. IIS 7.5, which ships with Windows 7.
If you deploy the default WebForm project in IIS, does it work?
Yes. No problem. In fact, I have several WebForms applications that I support for clients working in my development window. They all work without any problems.
If you deploy the default MVC project in IIS, does it work?
Yes. There are several sites in this field. All these sites work without failures. At FACT, the vast majority of routes on this site can be obtained without any problems. The vast majority of routes are REALLY VERY CONTROLLER available without any problems !!!
To repeat, this controller allows the user to manage users, roles and permissions in the application. We have methods for publishing, creating and updating users, roles and permissions. Routes that affect user and permission management methods work whether the debugger is working or not. The only routes that give us problems are the four routes that I described above.
Currently we have 19 controllers, each of which has a different number of specific route methods. EVERY OTHER route defined for the application works correctly and does not exhibit this behavior. These are the only four methods (routes) in this particular controller where we see this.
UPDATE # 2:
I narrowed it down to a REST call (to the service we control) inside the controller. Here's the weird part - if I go into the REST service and immediately return the value (don't process anything), it still hangs outside the debugger. If I run inside the debugger or immediately after starting the debugger, everything works as it should.
If I try to press this REST service directly in the violin, it works like a charm.
I will try to change the URL in the web service contract that I call and see if this works. Perhaps this is something related to the REST URL in the web service.
UPDATE # 3:
To add one more confusion, I created Fiddler to act as a proxy between my MVC application and mid-level REST. For EVERY other REST call in the application, the proxy receives a request. For this particular REST call, the NEVER proxy receives the request.
Now here is the annoying part. The WebChannelFactory, which we use to call all middle-level methods through REST, is created using the utility class in our MVC application. This code is used to generate each channel, so there is no difference between the requests that populate the list of users and the one that populates the list of permissions (the one that hangs).
This is a GET request that hangs, so I was able to call it directly in the browser. It works without a problem. The problems do not seem to be at the end of the service, but somewhere in the MVC application.