I've created an MVC application and deployed it to our three load-balanced production servers. I initially had some problems with pages not always being displayed but solved that by adding the machineKey to the web.config.
I have now extended my application by adding an Area and deployed that to the production servers and I'm now seeing 404 errors every so often. My previous experience suggests to me that there is an issue with the load-balanced servers. I note that there is a web.config for the Area I created but adding the machineKey to that resulted in an error.
The rest of the site outside of this Area still works fine so I'm wondering if there is something I'm missing with regards to the set up.
The only thing I've found so far is this question but here the issue was due to an upgrade from MVC 3 to MVC 4. I'm using MVC 3. I don't think the issue is with routes since every third or so attempt results in a page being loaded.
EDIT
The Areas works fine on one web server but does not work on the other two. MVC is not installed on any of the three servers so when I push the code I deploy the dependant assemblies.
I asked a related question to this problem. The fix that solved that one, also solved this.
The solution was to remove this file MVC-AreaRegistrationTypeCache.xml from within the Temporary ASP.NET Files directory.
Related
I have an ASP.NET Core 6 Web API project.
When I'm running the project, my project takes about 2 GB of memory!
I found this problem in the dotMemory application:
There seems to be a problem with this part (Routing)
My project has some routes.
For example for every action, It has four routes.
They are defined like this:
Where do you think the problem is, where did this memory problem come from and how should I solve it?
currently I am a bit lost or maybe have just a mental blockade.
The topic for my question is a 1.7.3.3 Prestashop currently hosted at shared hosting. Due to slow performance and long TTFB I am currently moving it to a VPS running Plesk, hosted on DigitalOcean.
Now comes the Part where I am a bit lost: I copied the files via WGET, dumped the Database and applied permissions (to my knowledge) correct. Shop comes up at the new Plesk-Host under new domain without issues.
As soon as I am trying to enable MySQL-caching I am able to edit the pages with Apollo Pagebuilder, but not save them anymore. At least the changes don't show up at front office. If I switch back to filecache, changes are propagated as intended, but the modules-page in the backend doesn't work anymore (e.g. error 500, can be fixed by removing /app/cache/prod and app/cache/dev)
So, to summarize my issue: If I enable filecache, everything except the module-page works, if I enable MySQL-cache, everything except Apollo Pagebuilder-propagation works.
What I already tried:
I have reinstalled Apollo Pagebuilder, but this rather completely breaks my Front Office (means I'd have to rebuild everything from scratch, as the current status doesn't seem to be read properly).
Exported, reimported and "update and fixed" Apollo, not successful :(
Only thing that comes to my mind as a fix would be sacrificing something to the gods, but I'd rather not do that.
Environment:
Ubuntu 16.04 LTS; Plesk Onyx 17.8.11; Prestashop 1.7.3.3; PHP 7.1.26
If no one had this problem before, maybe someone has an idea on what to delete to just enable the modules in the backoffice. I'd be willing to take MySQL caching as non-available.
Thank you in advance for your help.
Ok, I think I found the answer. As the server including cache was migrated, it cached the database-connection as well. (Fortunately it wasn't able to write on the previous DB).
So if ever someone faces the same issue:
prestaroot/app/cache/prod/appProdProjectContainer.php stores the connectionstrings at 2 positions.
Once in: protected function getDoctrine_Dbal_DefaultConnectionService() //**around line 670
and once around line 5000. Easiest would be to just search for your previous connection-credentials.
Also you need to make sure that in prestaroot/app/cache/prod/appParameters.php the same, valid, credentials are existant.
Hope it will help someone one day.
I have an application using enhydra 5 framework running on a resin 2 server.
Moving this application to a tomcat 7 server is giving me issues.
I was able to get the application deployed on tomcat server, but the session data is lost between requests. I compared the values by debugging the application on tomcat and resin and found that the session values are available in resin.
Does anyone have any idea or provide me the link to get Enhydra source code.
It is a very old framework and was written in 2000.
I did a little digging and the best I could come up with was http://www.together.at/download which appears to be where this code migrated to but there is no sign of an accessible source repository or src bundles for old versions.
It sounds like there may be a configuration problem at work here. Something as simple as looking at the HTTP headers may shed some light on what is going wrong.
Another option I sometimes use when the source code isn't immediately to hand is JAD. The decompiled code isn't always the most readable but it is usually good enough to figure out what is going wrong.
We have a very strange issue that we're dealing with.
We have an MVC 3 application that we are still developing, and Monday we started running into an issue with four specific routes (methods) in one of our controllers. All four of these routes are used in the management of roles and deal with either creating or editing a role. We have two different tiers of roles in the application, so there are two routes for creating a role for each tier, and two routes for editing a role for each tier. Both methods for the corresponding create routes call the same view, as well as the two methods for the corresponding edit routes. Both views call a shared partial view that contains the form fields that correspond to the properties of the role being created or edited.
Here's the issue.
If I attempt to hit these routes without running the debugger first, IIS will hang. It will not error out, throw an error, or even register the request in the IIS log.
HOWEVER, if I attempt to access those routes in the debugger, regardless of whether I have a breakpoint set up or not, the routes function as they should.
To make life a little more interesting, if I attempt to access those same routes AFTER I've run and shut down the debugger, the routes STILL function as they should.
We can reproduce this behavior on EVERY machine on our development team AND our staging server (except the debugging part on staging).
The methods that correspond to all of these routes themselves rely on a couple of methods in the same web service in our middle tier. Those methods work properly outside of the debugger in our integration tests.
We've checked for endless loops in the code, but can't find anything that would create an endless loop under these conditions. In fact, there's only one loop in the shared view, but it's a for each loop which shouldn't ever result in an endless loop.
Lastly, when I attempt to hit any of these four routes without running under the debugger or at least running it on a previous request, IIS essentially hangs. It will not time out. It will not throw an error. It will not log an error to the IIS log. Finally, it will eat up system resources the the point that you have to either restart IIS or reboot the entire machine.
Has anyone ever seen this behaviour before? Any ideas on how to get around it? I've NEVER seen this behavior before, and the only thing that anyone in our development group could come up with was some sort of permissions issue on a file, but we're not accessing the file system (outside of the view files themselves, and they have proper permissions) at any point during the processing of these methods.
I'm open to any and all suggestions.
UPDATE #1:
I have also posted this question on the ASP.NET forums and I had someone ask a question for more information. Here's my response to their questions.
What IIS are we talking about?
IIS 7.5. We're using the full-fledged IIS, not IIS Express.
What error?
That's just it. There is no error. No error is being reported. In fact, the request itself isn't being recorded in the IIS log for the site IF we're attempting to access these routes without the debugger running. If the debugger is running, everything works as you would expect it to.
VS Cassini?
Nope. IIS 7.5 that comes with Windows 7.
If you deploy on IIS a default WebForm project , does it works?
Yes. Without an issue. I actually have a number of WebForms applications that I maintain for customers running on my development box. They all work without any issue whatsoever.
If you deploy on IIS a default MVC project , does it works?
Yes. I have a number of sites running on this box. All of these sites are running without a hitch. IN FACT, the vast majority of routes on this site can be accessed without any issue. The vast majority of routes WITHIN THIS VERY CONTROLLER can be accessed without any issue!!!
To reiterate, this controller allows a user to manage users, roles, and permissions within the application. We have methods in there for listing, creating, and updating users, roles, and permissions. The routes that hit the methods for managing users and permissions work regardless of whether the debugger is running or not. The ONLY routes giving us issues are the four routes that I described above.
We currently have 19 controllers in this application, each with a varying number of defined route methods. EVERY OTHER route defined for the application is working properly and is not exhibiting this behavior. These are the only four methods (routes) in this one particular controller where we are seeing this.
UPDATE #2:
I've narrowed this down to a REST call (to a service that we control) within the controller. Here's the weird part - if I go into the REST service and immediately return a value (don't process anything), it still hangs outside of the debugger. If I'm running inside of the debugger or immediately after running the debugger, everything works as it should.
If I attempt to hit that REST service in fiddler directly, it works like a charm.
I'm going to try changing the URL in the service contract for the web service I'm calling and see if that works. Maybe it's something to do with the REST URL on the web service.
UPDATE #3:
Just to add further confusion, I set up Fiddler to act as a proxy between my MVC application and the REST middle tier. For EVERY other REST call within the application, the proxy gets the request. For this particular REST call, the proxy NEVER gets the request.
Now here's the annoying part. The WebChannelFactory that we use to call all of the methods in the middle tier through REST is created using a utility class in our MVC application. This code is used to generate every channel, so there's no difference between the requests that populate the list of users and the one that populates the list of permissions (the one that's hanging).
This is a GET request that's hanging, so I was able to call it directly in the browser. It works without an issue. The issues doesn't appear to be on the service end, but somewhere in the MVC application.
Make sure that you don't pass in ViewBag.Variable.ToString(), since it's dynamic, it will not work!
Seems that lot of people already know that issue but I can not find solution.
We transferred our web app from IIS6 to IIS7. For authentication purposes and some other functions we using session variables.
While on IIS6 we did not had any problem but now all users losing their time and patience because app variables are being lost somewhere between pages being submitted and as a result users get kicked out of the app.
Server is 2008 R2 with 64 bit OS.
Default installation by Dell so it should be running on 64 bit mode.
We do not have any third party elements or modules. All developed in-house.
Database obviously MS SQL 2008 as well, on the same server (I know it is bad but we limited in resources and money).
So does anyone know what is going on and how to fix this?
Resolution of that problem is simple: do not use any other port except 80.
As soon as I moved site to separate IP with port 80 (use of header on the same IP was not tested) -- all problem gone....
Have you deployed your application as a new website or a virtual directory on the IIS ?
Remember that for the methods in the global.asa to be executed by the server you need to deploy your application as a new website not just a virtual directory under an existing web site.
I think the best way is to add logging code to trace when exactly a session variable is lost; after a post back to the server, redirection, etc... to try to narrow down the causes.
good luck.
Look here for a solution...
the intrinsic checkbox fixed my problem