I created an python api on openshift online with python image. If you request all the data, it takes more than 30 seconds to respond. The server gives a 504 gateway timeout http response. How do you configure the length a response can take? > I created an annotation on the route, this seems to set proxy timeout.
haproxy.router.openshift.io/timeout: 600s
Problem remains, I now got logging. It looks like the message comes from mod_wsgi.
I want to try alter the configuration of the httpd (mod_wsgi-express process) from request-timeout 60 to request-timeout 600. Where doe you configure this. I am using base image https://github.com/sclorg/s2i-python-container/tree/master/2.7
Logging:
Timeout when reading response headers from daemon process 'localhost:8080':/tmp/mod_wsgi-localhost:8080:1000430000/htdocs
Does someone know how to fix this error on openshift online
Next to alter timeout of haproxy of the route of my app
haproxy.router.openshift.io/timeout: 600s
I altered the request-timeout and socket-timeout in app.sh of my python application. So the mod_wsgi-express server is configured with a higher timeout
ARGS="$ARGS --request-timeout 600"
ARGS="$ARGS --socket-timeout 600"
My application now wait 10 minutes before cancelling a request
GF5 build1, Java EE7 + Primefaces 6.1, trying to upload photo ~ 2MB in p:textEditor componnent I always get error:
Severe: java.lang.IllegalStateException: GRIZZLY0205: Post too large
Setting "Max Post Size" to -1 or any >1mljn value in Configurations - server config - Network Config - Network Listeners - http-listener-1 doesn't help. The same on GF 4.1
This is a x-www-form-url encoded content so we need set parameter: max-form-post-size. This isn't exposed via the UI, but you can configure it using cmd:
asadmin set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.max-form-post-size-bytes=-1
Apache benchmark is failing when using lengthy custom authorization header -
ab.exe -n 1 -c 1 -S -H "Authorization: SAML PHRyaWJ1dGUgQXR0cmlidXRlTmFtZT0iaGFzX3NlbGVjdCIgQXR0cmlidXRlTmFtZXNwYWNlPSJodHRwOi8vc2NoZW1hcy5iZW50bGV5LmNvbS93cy8yMDExLzAzL2lkZW50aXR5L2NsYWltcyI+PHNhbWw6QXR0cmlidXRlVmFsdWU+dHJ1ZTwvc2FtbDpBdHRyaWJ1dGVWYWx1ZT48L3NhbWw6QXR0cmlidXRlPjwvc2FtbDpBdHRyaWJ1dGVTdGF0ZW1lbnQ+PGRzOlNpZ25hdHVyZSB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+PGRzOlNpZ25lZEluZm8+PGRzOkNhbm9uaWNhbGl6YXRpb25NZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzEwL3htbC1leGMtYzE0biMiIC8+PGRzOlNpZ25hdHVyZU1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNpZy1tb3JlI3JzYS1zaGEyNTYiIC8+PGRzOlJlZmVyZW5jZSBVUkk9IiNfZDA4MTc0NWItOTU2ZC00NmE4LTg4MzItMTQ5MjBmNmY4ZTZmIj48ZHM6VHJhbnNmb3Jtcz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3BlZC1zaWduYXR1cmUiIC8+PGRzOlRyYW5zZm9ybSBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMTAveG1sLWV4Yy1jMTRuIyIgLz48L2RzOlRyYW5zZm9ybXM+PGRzOkRpZ2VzdE1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI3NoYTI1NiIgLz48ZHM6RGlnZXN0VmFsdWU+Q1hISDVsWCtZTTROVDhFUU1tVHIyN2lBdEk1dE9XajhuQ0pSTFEzYnFQbz08L2RzOkRpZ2VzdFZhbHVlPjwvZHM6UmVmZXJlbmNlPjwvZHM6U2lnbmVkSW5mbz48ZHM6U2lnbmF0dXJlVmFsdWU+alhVNG5Ud1lQYVZWazJhcUhjNW1DMk5FWWRSdXBPV1A2Nis4bmNlbndFQmlseG81S0RmdldBNldUaDdHSGlVNUpSdCtzbWsyY1dWajRPTElnUEhIWFlFZjNkaVNYNkd2ejBqVGh4VDBzVDNmSDNob081dkt6S2dITVdNWGM5cEswU2xrQVRSenhPZmxCTHFkclQ3bnBBd3lrbEtlTFhhaTRIVlJ6MU5aN3pFNXFVaHArVmJ3Y3FCZXpkZ1pPMWlCMHkyRHdzWFRJSFhmN2hOUmFLVUYzenF2bm5IYlBNZG95cGZNbzhxU0hwcFhWNzRuN0lLQ3hHakhlYzdJak1JMWlrZVNFaTE2ODJUN0Y0cHRESXNjYmcxWW5LTTRhdHZxMWZMSi83QWx0ck90SGFMSkZBSU1jeG43TXhCckNuNXhSR2I2ZDN2c0U0VzVHN2E3MmY2OUpBPT08L2RzOlNpZ25hdHVyZVZhbHVlPjxLZXlJbmZvIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj48WDUwOURhdGE+PFg1MDlDZXJ0aWZpY2F0ZT5NSUlHampDQ0JYYWdBd0lCQWdJUUFxQzZUbmZlVFJQeUQrN0Q2YlE4RERBTkJna3Foa2lHOXcwQkFRVUZBREJJTVFzd0NRWURWUVFHRXdKVlV6RVZNQk1HQTFVRUNoTU1SR2xuYVVObGNuUWdTVzVqTVNJd0lBWURWUVFERXhsRWFXZHBRMlZ5ZENCVFpXTjFjbVVnVTJWeWRtVnlJRU5CTUI0WERURXpNVEF4TlRBd01EQXdNRm9YRFRFME1UQXlNREV5TURBd01Gb3dkekVMTUFrR0ExVUVCaE1DVlZNeEZUQVRCZ05WQkFnVERGQmxibTV6ZVd4MllXNXBZVEVPTUF3R0ExVUVCeE1GUlhoMGIyNHhKakFrQmdOVkJBb1RIVUpsYm5Sc1pYa2dVM2x6ZEdWdGN5d2dTVzVqYjNKd2IzSmhkR1ZrTVJrd0Z3WURWUVFERXhCaGRYUm9MbUpsYm5Sc1pYa3VZMjl0TUlJQklqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUFwemdYV29tVlpObS81NnBiUnlaeThWYlhyVUNsUWpPWU13N3dGYUZUTE9XRU9iOWhncUVWWnZOVUxLNFBmV2dmTUo4cUxxZkhodnFXbG8xSkFxRFdiUUpybFJIQVNLdUNjOWVPa3JQMzdpMW1WenNtNWxQUlBWb242R1RhUkE5SVRBRitiNW5OMDB5MHczOThNWnFJZ2xJdDRQRmNlM1NXd3lYQkdOSUpyWURNYndmRjFFQU5hU1V4Skh3eUd0eVVLVWlxeFB3SllFZ3JacHJoZHlMQnRRdXJaZGJwNkViSEduQVZJWHpKR2Y0TC9WN2tpdWExNWFmeW9Ycm5tZ2d0SGJBMEFOVkY5eXFBcG5oc0FxR2pDdHpSSGpvWG9FMFNnZFY1U3hvUm1lb3hXZWowOEZYdW96bHRLc2d5Z25ZbXZoZFB5VGl4SjVqYSttZlVxUjZCeXdJREFRQUJvNElEUXpDQ0F6OHdId1lEVlIwakJCZ3dGb0FVa0hIYk4rdHp5Ty9jMVI0U3RqUzZLMXFncHBJd0hRWURWUjBPQkJZRUZKaHM1L1d2bkYwbHFSdGhMYklwOUlLTUVwMXRNQnNHQTFVZEVRUVVNQktDRUdGMWRHZ3VZbVZ1ZEd4bGVTNWpiMjB3RGdZRFZSMFBBUUgvQkFRREFnV2dNQjBHQTFVZEpRUVdNQlFHQ0NzR0FRVUZCd01CQmdnckJnRUZCUWNEQWpCaEJnTlZIUjhFV2pCWU1DcWdLS0FtaGlSb2RIUndPaTh2WTNKc015NWthV2RwWTJWeWRDNWpiMjB2YzNOallTMW5OQzVqY213d0txQW9vQ2FHSkdoMGRIQTZMeTlqY213MExtUnBaMmxqWlhKMExtTnZiUzl6YzJOaExXYzBMbU55YkRDQ0FjUUdBMVVkSUFTQ0Fic3dnZ0czTUlJQnN3WUpZSVpJQVliOWJBRUJNSUlCcERBNkJnZ3JCZ0VGQlFjQ0FSWXVhSFIwY0RvdkwzZDNkeTVrYVdkcFkyVnlkQzVqYjIwdmMzTnNMV053Y3kxeVpYQnZjMmwwYjNKNUxtaDBiVENDQVdRR0NDc0dBUVVGQndJQ01JSUJWaDZDQVZJQVFRQnVBSGtBSUFCMUFITUFaUUFnQUc4QVpnQWdBSFFBYUFCcEFITUFJQUJEQUdVQWNnQjBBR2tBWmdCcEFHTUFZUUIwQUdVQUlBQmpBRzhBYmdCekFIUUFhUUIwQUhVQWRBQmxBSE1BSUFCaEFHTUFZd0JsQUhBQWRBQmhBRzRBWXdCbEFDQUFid0JtQUNBQWRBQm9BR1VBSUFCRUFHa0Fad0JwQUVNQVpRQnlBSFFBSUFCREFGQUFMd0JEQUZBQVV3QWdBR0VBYmdCa0FDQUFkQUJvQUdVQUlBQlNBR1VBYkFCNUFHa0FiZ0JuQUNBQVVBQmhBSElBZEFCNUFDQUFRUUJuQUhJQVpRQmxBRzBBWlFCdUFIUUFJQUIzQUdnQWFRQmpBR2dBSUFCc0FHa0FiUUJwQUhRQUlBQnNBR2tBWVFCaUFHa0FiQUJwQUhRQWVRQWdBR0VBYmdCa0FDQUFZUUJ5QUdVQUlBQnBBRzRBWXdCdkFISUFjQUJ2QUhJQVlRQjBBR1VBWkFBZ0FHZ0FaUUJ5QUdVQWFRQnVBQ0FBWWdCNUFDQUFjZ0JsQUdZQVpRQnlBR1VBYmdCakFHVUFMakI0QmdnckJnRUZCUWNCQVFSc01Hb3dKQVlJS3dZQkJRVUhNQUdHR0doMGRIQTZMeTl2WTNOd0xtUnBaMmxqWlhKMExtTnZiVEJDQmdnckJnRUZCUWN3QW9ZMmFIUjBjRG92TDJOaFkyVnlkSE11WkdsbmFXTmxjblF1WTI5dEwwUnBaMmxEWlhKMFUyVmpkWEpsVTJWeWRtVnlRMEV1WTNKME1Bd0dBMVVkRXdFQi93UUNNQUF3RFFZSktvWklodmNOQVFFRkJRQURnZ0VCQUtQQUhQcGNnd0FiSXNjT2JKYm1jbVA4RzJRWkI4VVVzeVIxOFd3OTdIWUlxRXM3MExScXFyVGpza1BsZnBYanRKSm1pVjgydzZOYWZrQ3dBbWxycy94TTJFako3UkVacDZ2YmVJZHlGTjIwM3dlQkViRm9RYjg0Wk9COWRHQmR4MktZdzBuUHJSM0F1YkRQVTZJNjlhWTBFNGJIRUM2Y09nOGxjeUhkWXFyZDNSRlByUjJiN1hGWVdyaXRXeElXbHFNRUVzNVU3dkRsYjkrby9HRlZqbE1QSW4xcG0yNDBUYW41WkR0Si9NcXZZRTYrQzh1ZUtEZW1lcndiR0ZCNzFJTVI3TUU1SHYzayt3N0hFMm1ETjF0RnVjb1ZyQVVFZndYVUNzTUdzMkJJbzJsVVNGL3FIYUY3akhHdnJPUmloVFlKQnBtQzRpWmJRTGpLQmZBRXBTVT08L1g1MDlDZXJ0aWZpY2F0ZT48L1g1MDlEYXRhPjwvS2V5SW5mbz48L2RzOlNpZ25hdHVyZT48L3NhbWw6QXNzZXJ0aW9uPg==" -v 2 http://localhost:55495/rest/1
Please note that I am testing .net rest api which needs lengthy user token in authorization header to proceed.
Apache Benchmark has a maximum request size of 2048 characters. Your header alone is more than 4KB in size, so that's why your test is failing. The maximum size of the request is given in ab.c. Look for char _request[2048]; in that file and try increasing it. Note that the passed-in headers are also parsed into a header structure that may have limits as well.
You can install the ab from httpd source code, which now sets char _request[8192];.
The code can be found in httpd-2.4.53/support/ab.c
I am running an app on http apache 2.4 through which I am trying to connect to a kaazing gateway. I have followed the
instructions that are found in kaazing site at "setup-guide.html#webserver_integrate" section, but the connection keeps failing: the Mozilla console prints:
TypeError: this._socket is undefined, 4146 XmppClient.js
I changed the <allow origin> with an *. I would like to ask whether I should make any changes on the configuration file of apache.
Finally, I managed it to work. I made a new install of kaazing gateway. In gateway-config.xml at the GATEWAY_HOME/conf/ I changed the value of the gateway.hostname with my internal ip and set the
*
at
<cross-site-constraint>
<allow-origin>*</allow-origin>
</cross-site-constraint>
in service with type: xmpp.proxy and this time worked! Also I changed '
*
with the
http://localhost:80
(http apache) and also worked. I don't know why didn 't it work before.
Thanks for trying to help!
I have a PHP script that keeps stopping at the same place every time and my browser reports:
The connection to the server was reset
while the page was loading.
I have tested this on Firefox and IE, same thing happens. So, I am guessing this is an Apache/PHP config problem. Here are few things I have set.
PHP.ini
max_execution_time = 300000
max_input_time = 300000
memory_limit = 256M
Apache (httpd.conf)
Timeout 300000
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 0
Are the above correct? What can be causing this and what can I set?
I am running PHP (5.2.12.12) as a
module on Apache (2.2) on a Windows
Server 2003.
It is very likely this is an Apache or PHP issue as all browsers do the same thing. I think the script runs for exactly 10 mins (600 seconds).
I had a similar issue - turns out apache2 was segfaulting. Cause of the segfault was php5-xdebug for 5.3.2-1ubuntu4.14 on Ubuntu 10.04 LTS. Removing xdebug fixed the problem.
I also had this problem today, it turned out to be a stray break; statement in the PHP code (outside of any switch or any loop), in a function with a try...catch...finally block.
Looks like PHP crashes in this situation:
<?php
function a ()
{
break;
try
{
}
catch (Exception $e)
{
}
finally
{
}
}
This was with PHP version 5.5.5.
Differences between 2 PHP configs were indeed the root cause of the issue on my end. My app is based on the NuSOAP library.
On config 1 with PHP 5.2, it was running fine as PHP's SOAP extension was off.
On config 2 with PHP 5.3, it was giving "Connection Reset" errors as PHP's SOAP extension was on.
Switching the extension off allowed to get my app running on PHP 5.3 without having to rewrite everything.
I had an issue where in certain cases PHP 5.4 + eAccelerator = connection reset. There was no error output in any log files, and it only happened on certain URLs, which made it difficult to diagnose. Turns out it only happened for certain PHP code / certain PHP files, and was due to some incompatibilities with specific PHP code and eAccelerator. Easiest solution was to disable eAccelerator for that specific site, by adding the following to .htaccess file
php_flag eaccelerator.enable 0
php_flag eaccelerator.optimizer 0
(or equivalent lines in php.ini):
eaccelerator.enable="0"
eaccelerator.optimizer="0"
It's an old post, I know, but since I couldn't find the solution to my problem anywhere and I've fixed it, I'll share my experience.
The main cause of my problem was a file_exists() function call.
The file actually existed, but for some reason an extra forward slash on the file location ("//") that normally works on a regular browser, seems not to work in PHP. Maybe your problem is related to something similar. Hope this helps someone!
I'd try setting all of the error reporting options
-b on error batch abort
-V severitylevel
-m error_level
and sending all the output to the client
<?php
echo "<div>starting sql batch</div>\n<pre>"; flush();
passthru('sqlcmd -b -m -1 -V 11 -l 3 -E -S TYHSY-01 -d newtest201 -i "E:\PHP_N\M_Create_Log_SP.sql"');
echo '</pre>done.'; flush();
My PHP was segfaulting without any additional information as to the cause of it as well. It turned out to be two classes calling each other's magic __call() method because both of them didn't have the method being called. PHP just loops until it's out of memory. But it didn't report the usual "Allowed memory size of * bytes exhausted" message, probably because the methods are "magic".
I thought I would add my own experience as well.
I was getting the same error message, which in my case was caused by a PHP error in an exception.
The culprit was a custom exception class that did some logging internally, and a fatal error occurred in that logging mechanism. This caused the exception to not be triggered as expected, and no meaningful message to be displayed either.