EDIT1: intershop.urlrewrite.CheckSource is turned off already
We are recently having quite big problems with URL rewrite rules not being loaded in test and production multi-node environments.
The problem started happening after introducing another organization and it's related application onto the servers.
From then on we have tried multiple changes and debugging methods to try to figure it out, but without any result.
Also the major problem is that it doesn't happen all the time and server restart can fix it but not always.
Here are the details so far how the problem manifests (this has been going on for more than a month now on our production system):
Most of the time it starts happening after the deploy of new code and starting up the server
Then multiple people from multiple computers and locations try opening the website and some open it and others get either 404 or "URL invalid" page, so its 50/50.
On the PC where someone successfully opens page, if you try again in incognito mode then you may get again 404(probably connects to another node/appserver).
Usually the problem is resolved either by server restart or by restarting a single node(no code or configuration changes) although this is no reliable way and on the last occurrence we tried multiple restarts and it didn't help. After a few days one of the team members restarted only a single node for debugging purposes and then it started working normally again.
After setting up more detailed log messages and turning on debug messages for URL rewrite classes we have come to the conclusion that the rule loading fails. We have come to this conclusion because we have added debug message on the very start of our applyExpand() method and it never gets shown. This can be observed on the image below:
All of this leads to conclusion that iterator on line 149 is empty.
Please advise on possible causes of this problem and how to resolve it.
The rule loading is implemented so that it's possible to edit/add/remove rules on-the-fly without need to restart the web server. This happens when the property intershop.urlrewrite.CheckSource is set to true. For this, the last-modified time of the file is evaluated. Maybe this doesn't work correctly.
I would recommended to set this property to false and test again if the problems still occur.
With the help of IS support, we have managed to figure out that the problem was that the URL rewrite rules were in a cartridge that wasn't part of every possible application on server which would result in undefined behavior when loading them (it would load on one appserver and on another it wouldn't).
The fix was to add a new common cartridge for all possible applications which would then hold urlrewrite rules and which would definitely be loaded on server startup.
Related
Hi guys i have a very strange problem. I am tasked to conduct several performance tests on an old Webpage (2004 - something).
The module that is under test is created with ASP.net forms.
Im using Jmeter for the task.
I have used Chrome extention (Blazemeter) to generate the starting script.
But a very strange problem occurs all other pages of the form are fine and dandy... except a page for file upload where upon trying to proceed(Make a POST request) it loses its session and you are redirected to another screen with generic- Would you like to continue last session type of messages appear.
In order to try to debug the problem i wrote a simple Post request on IntelliJ and everything works fine when executed.
I then returned to Jmeter and punched in everything identical to the script and i still get the same problem.
I then decided to try the Jmeter recording proxy ( in case the blazemeter is faulty and assigns some values incorectly) And while i was manualy browsing the form the problem Appears! - when i click on proceed on that specific upload form with the jmeter proxy turned on, it loses session and it shows the "continue last session screen". And i am baffled as to how a simple proxy that records could mess up the sessions. I tried it with a normal proxy (not the Jmeter one) and everything works. So it seems that the problem is in Jmeter or some settings.
Have you guys ever encountered such a problem , or have some insight as to what might cause such behavior. Additional info:
I have worked on ASP.net form before and i am extracting __VIEWSTATE __EVENTARGUMENT and a couple of other hidden variables from the previous response and passing them to the request.
I am using the Multipart/form-data for the upload file module POST and passing the file properly.
As a standart i am using KeepAlive and Follow Redirects but i have tried Redirect Automatically or all of the above switched off.
There is a Cookie Manager set up on Test Plan level and it is working in HC4 - compatibility(tried all others too) based on the requests its working properly.
Cache Manager to 5000 elements.
Certificates seem to be properly imported (for the Jmeter proxy).
I am at this point baffled as to why Jmeter refuses to act properly and i would be very gratefull if someone could help me.
Hi guys il just post an update since i found a work around. So if i record everything with blazemeter (since jmeter proxy doesnt allow me) and after on the upload step i delete the steps and just write a manual request in the body with multipart/form tick turned off and just write the multipart stuff in the headers it seems to work. I still have no idea why it behaves this way.
The Signal R implementation what I have done works perfectly in localhost with two browsers on the same machine, but when I publish the code it faces some DNS resolution related problem and stops working when I test the published code on two different machines. I'm not sure what stops it from working.
The first thing I should check is if you can access http://SomeDomain.com/signalr/hubs
That should load JS, if that doesn't work, you will need to start tracking things down from there. As "N. Taylor" states in the comments, your path to SignalR/HUBS might differ if you've changed things in development, so you will want to customize the above URL based on any customizations you've made in DEV.
Once you get the proper path to /signalr/hubs and get JS loading when you access that URL, it should be easier to get things tracked down a bit.
I am working with Drupal (7) for the first time. I have installed it multiple times using both an automated Simple Scripts method, and a manual method. I am using the MERCI module to create a reservation system. Every time, over the course of several installations, a seemingly simple action - such as creating a taxonomy term (most recent trigger) or activating a standard module (Views for instance) results in a permanent 500 Server Error, interspersed with a properly loaded home page that will not allow the user to proceed to further links.
Check out the site here: www.browntv.org/mgmt
On first load - you will either get a Server Error, or a properly loaded page. If the page loads properly, clicking to ANY link should result in a blank screen, server error, or some other redirect.
I honestly don't even know where to start diagnosing this. I can't tell where an error (if there was one) would be logged, and nor can I figure out how to manually step my MySQL database backwards to try and remove whatever is causing the issue.
Any leads, suggestions, or ideas would be REALLY helpful. Until now, I've just been creating a new installation, thinking that the issue stems from installation issues. However it has happened so many times now I can't just keep starting from scratch.
I'm not seeing any errors on your site, and in fact it let me register a new account.
Having said that, as should be obvious from the error message, 500 is an internal server error, and no one is going to be able to determine the cause just by going to the public url. It's an error with a configuration file on your server. Generally a syntax error would give you a consistent, not a sporadic 500.
While I have a good deal of experience with MERCI, the way you've described the issue, that wouldn't have anything to do with it.
If the problem persists you should check your Apache error log.
The issue: a content editor saves a new content item and gets a 404 on the proper-looking url for the new object. If they then refresh, the item is there, perfectly normal.
This happens for multiple Archetypes-based content types, and we've seen it on at least two different sites. We've seen it on Plone 3.x and 4.0.3. Here's what these sites have in common:
HAProxy load balancing (with and without session affinity)
Multiple ZEO clients
Using either ZODB 3.9.7 or 3.8.4
The issue happens only some of the time, maybe for 1 out of 4 content items
Has anyone seen anything like this?
I do not have an answer for you; this should not really happen. I certainly have not seen this.
You'll need to gather more information to troubleshoot this, and that perhaps requires interactive access to experts, and SO is not the place for such troubleshooting.
All I can do is advice that you gather as much information as possible, including a full trail of the user interaction from the various logs, including HAProxy and the ZEO server.
It may require additional instrumentation at the server level (when the NotFound error occurs, dump additional information about what is present, etc).
Some recomendations/questions:
Verfy that the content object was, indeed, created.
Check that the content views are correct (the ones that are declared in profiles/default/types/yourtype.xml).
Does it happen when adding content directly to plone instance (Without caching and load balancing?
Does it happen when adding content to direct plone instance with load balancing, but without caching? ---> And so on ...?
Maybe not an elegant one, but you might try inserting print statements or pdb breakpoints in the code so you can track whenever a content object was, indeed, created. Do this only as a desperate method of "instrumentation".
Yes. we have recently started seeing the same issue. We have almost the same setup. Haproxy (no session affinity).
I'm wondering since the pattern seems to be haproxy... perhaps its an issue with a request being redistributed after a timeout?
Updated:
We had this issue. It happens when you have a redirect back to the changed object after a save. This is because the 2nd request hits another zeo client which doesn't realise it's out of date.
The only solution we found was a to add temporary session affinity in haproxy (20s) during any POST. Not ideal but does work. I was just searching for a better solution which is why I found this old post.
We're trying to figure out how to fix a bug found in 3rd party IV&V testing, which we can't recreate in our internal test environment.
We've determined that the bug is caused by a URL value being inadvertently set to an empty string ("") before attempting to redirect to it. Hence, we're trying to execute Response.Redirect("").
In the external test environment, this line of code results in the following error:
Internet Explorer cannot display the webpage
In the internal test environment, the current page is simply reloaded.
The servers are virtually identical - the internal test server has the same physical hardware as the external server, and is even running a copy of a virtual image of the external server. Hence, all Windows and IIS settings should be identical.
Is there a physical networking, load balancing or other environmental issue that could cause this kind of discrepancy?
Thanks for any ideas.
I would use Fiddler to take a look at the HTTP response from the server and make sure they are exactly the same. When you've done that, you know it's a client-side or environment issue. Next...
What is the URL in the address bar for the two browsers? Better yet... in IE right click on the page and look at the Properites. What are you really seeing here? On my local system testing Response.Redirect("") I get something like this: "res://ieframe.dll/dnserror.htm#http://localhost/test.aspx" DNSERROR! Hmmmm... interesting!
Also, consider what happens in the following situation:
http://somelanname
...in an environment where "somelanname" is the name of a resource on your local intranet... and then what happens when you try to access that URL when it doesn't exist. I think you are seeing the same thing here.