I have a strange problem with using ajax post requests. I use the request to run an ImageMagick process directly on the command line by using php function exec(). The process takes about a minute, and then responds with some variables. This is working fine, except from one problem. During the execution time I cannot excess other parts of the website that are installed on the same webserver (as if the server is unreachable). When the process finishes, everything works fine again.
I first thought this to be due to an overloaded server. However, when you access the website via another browser, there are no problems, even during the execution time of the process in the other browser. So it looks like the problems has something to do with browsers blocking other requests during the post request.
Could anyone help me out here? What could be the root problem?
Found the solution! Thanks from the help by kukipei By adding session_write_close(); to the file of the ajax request (after is has read the userid and token), the session file is no longer locked, and all pages are accessible again. Problem was that the session was locked during the whole execution time of the process, which was not necessary, since I only needed the session to read the userid and token. So before calling the ImageMagick operation, I now add session_write_close()
Related
I have a page which will send some ajax request to my Jetty7.6.9 server. All of them containing a COOKIE named JSESSIONID so that the server knows the request is logged in.
But sometimes, the method org.eclipse.jetty.server.Request.getCookies() returns an empty Cookie[]. I set a breakpoint and checked the _connection._requestFields and I found the Cookie right there, but Request.getCookies() cannot fetch it or parse it.
The situation can happen in any one or more ajax request in that page, can happen in any time, can happen in both windows and linux. It seems that it's a random case, and even when I dropped the frame at the breakpoint to the pre line, it would run correctly when it ran to the same place, so I think it's an issue about synchronize/concurrent.
I didn't find the same case in jetty bug list.
Is it a bug? What can I do to verify or repeat it? How to fix it?
(For some reason,maybe I cannot update the Jetty version for our system.)
I am currently working on a Django development. There is a problem, which isn't a true problem but very annoying. Often, when I try to debug my Django app by putting down some break points, I get this error at the server end:
error: [Errno 32] Broken pipe
After reading this other post, Django + WebKit = Broken pipe, I have learned that this has nothing to do with the server but the client browser used. Basically, what happened is that the browser has a http request timeout. If it doesn't receive a response within the timeout, it will close down the connection with the server.
I find this timeout isn't really needed, indeed causing headache, during debugging. Is there any way I can lift this timeout or increase it for my browser (Chrome)? Or maybe a substitute browser that doesn't have this constraint?
Note: Although I am using Django and have mentioned about it, this isn't a Django-related question. It's more like a question on how to make my debugging process more effective.
I prefer using linux/unix curl command for debugging web applications. It's good approach, especially if you want to focus on some specific request, for example: POST does not work fine for some set of parameters, or cookies are not set as expected.
Of course it may take some time at the beginning to find out how to use it, but then, you will have a total control about every single piece of request: timeouts, cookies, headers and so on. It's very helpful, because you can be sure that what you wanted to send is actually sent (no additional data is added by the web browser).
There are plenty of examples of similar problems littered around the web but none of their solutions seem to fix this particular variation. Any suggestions would be appreciated.
Usually this problem occurs because a rogue link is causing a request for a resources like a favicon or css file to hit the dispatcher more than once, thus causing multiple dispatch processes and therefore multiple rows in your database.
I have checked that all the links on this very simple example page do actually resolve to the resource to which they point.
The session handler is setup as follows:
Zend_Db_Table_Abstract::setDefaultAdapter($db);
Zend_Session::setSaveHandler(new
Zend_Session_SaveHandler_DbTable($config->session->toArray()));
The db logging is setup as follows:
$writer = new Zend_Log_Writer_Db($db, $config->log->tableName,
$config->log->columnMap->toArray());
$logger = new Zend_Log($writer);
Both objects are correctly setup and can read and write to and from the database. Only everything happens twice. If I put a test log message anywhere in the application it is written into the database twice. If I increment three variables with every call to the index action - one stored in the session, one passed around via a Zend_Registry object and another local to the indexAction - only the session variable is incremented by 2. The Apache access log shows the correct amount of requests being fired from the page load and all have good response codes of either 200 or 304 (unchanged).
I have tried disabling all head links.
I have tried disabling the layout entirely.
I have localised everything to the dispatcher and exited before dispatch is run.
In all cases the extra write/increment takes place.
Any thoughts?
Thanks in advance for any help.
I seem to have found and fixed the issue. Chrome (and possibly all Webkit browsers) issues an additional HEAD request on top of the GET which means the application is hit twice and anything session based will be triggered as a result of both requests. My temporary solution is to put the following code near the start of my index.php file.
if ("HEAD" == $_SERVER['REQUEST_METHOD']) {
exit;
}
I hope that helps anyone with the same issue.
Google Chrome always asks for the favicon.ico by making annoying requests to the server. Take care about this in Chrome.
For more information:
http://framework.zend.com/issues/browse/ZF-11502?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#issue-tabs
Thanks to the Sebastian Galenski contribution.
I recently recorded a test script in Jmeter intended for use as a load test script (using this handy set of instructions. The recording itself worked great and I even figured out how to grab and parametrize the session ids and timestamps. However, if I run the recorded steps just as they were recorded some of them don't work -- they generate "500--Server encountered and internal error ...nested exception is java.lang.NullPointerException" The failing steps are all Ajax calls that populate sidebar elements. If I copy the request GET call (Request tab, ViewResultsTree) and paste it into a browser I get the exact same error. Do I need to record my script differently, or hand-code the ajax calls? Other, earlier steps work correctly and send the expected POST data, so it isn't the application under test or forgotten proxy settings. Currently running against Firefox 3.6.10
Any suggestions on how I can debug this would be greatly appreciated.
The first thing I'd do is determine if the java.lang.NullPointerException is happening on the client side (JMeter) or on your server. If it is happening in JMeter, than something is terribly wrong with either your script or with JMeter.
But assuming that the error is encountered on your server, then looking into the cause of the exception may shed light on what is wrong with the request issued by JMeter. Do you have access to the code where the exception is thrown?
I would also recommend comparing the request in the recording with the request that generated the error. You may need to determine which parts of the request are session-specific and ensure those fields are populated correctly.
It sounds like Jmeter isn't executing the AJAX calls, and this can be fine depending on your site. Can you simply do an HTTP request to get the pages the AJAX calls populate?
I would recommend reading this post, as it looks pretty good.
I've seen that situation caused by a few things:
a page is required to load and be cached BEFORE making the failing request;
the failing page needs to automatically redirected to work properly;
the failing page has sub-requests JMeter failed to record. Devs can help with this.
Hope this helps.
I have multiple xmlHttpRequest on my page, and I am attempting to call the abort() method on them all. Works great in FF. IE, on the other hand does not do a darn thing. The connections do not close, and I am unable to navigate to another page until the requests complete. What is this? Why doesn't IE close the connections when abort() is called?
I've almost never gotten abort to work in IE. I'm tired and can't remember why - something about not being able to abort until you're in readyState 4 (or maybe that it changed to readyState 4 when it aborts?). Either way, Ajaxian has a work around in the depths of its' archives:
http://ajaxian.com/archives/reusing-xmlhttprequest-without-abort
Parallel-Ajax requests vs Apache-Session locking
Session data is usually stored after your script terminated, but as session data is locked to prevent concurrent writes only one script may operate on a session at any time.
When e.g. using framesets together with sessions you will experience the frames loading one by one due to this locking. You can reduce the time needed to load all the frames by ending the session as soon as possible.
So you can use sessions in ajax scripts with
session_start(); (maybe handled automatically) followed immediately (soon as possible) by session_write_close();
session_write_close(); will "end" the current session and store the session data.
But: session_id() will still deliver the correct (current) PHPSESSID so you're able to re obtain write access to the current session by simply doing session_start() again at any time you need it.
I use it this way in all my ajax scripts to implement session handling and allowing parallel request (with aborting) in all browsers