Describing of context: java app (running under wildfly) works under high workload and heap is almost filled. Because of that full GC runs often and this leads to frequent long Stop The World phases.
While these phases I try to make login request.
So, if I make this request via front-end side (I just open login page, fill fields and click login button) I see this:
It is interesting that I get canceled request ALWAYS after 50 seconds and front-end even canot make tcp handhaske.
But if I make the same direct request just using console devtools of chrome (alternative is using postman, for example), I see this:
In that case browser establish tcp handshake, send reqiest and wait 2,6 mint for first byte from the server etc,.
Why I see that difference behavioral ? What is root cause of that ?
I've been investigating similar issue, where something killed the request between BE and FE after exactly 50 seconds and I ran into this question. So I am posting here in case it helps someone in future.
In our case, it was the k8s Openstack loadbalancer timeout that did not wait for backend's response:
https://docs.openstack.org/octavia/latest/configuration/configref.html
Specifically timeout_client_data and timeout_member_data.
We updated the IstioOperator settings in spec.components.ingressGateways.k8s.serviceAnnotations with following annotations:
loadbalancer.openstack.org/timeout-client-data: "180000"
loadbalancer.openstack.org/timeout-member-data: "180000"
to increase the timeout limit and then we were able to receive response successfully.
You can find more details on loadbalancer annotation possibilities here:
https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/openstack-cloud-controller-manager/expose-applications-using-loadbalancer-type-service.md
Related
I have a webapp to test. I got a test working with protractorJS that is clicking different buttons.
Some buttons do trigger a POST request, and the webapp is waiting for an answer from that point on. The answer can take up to 30 or 40 seconds to come in. If I look into the Chrome Developer tools, I see that the webapp sends GET packets to get the status every 2 seconds. The status can be waiting, failed or successful.
My Question is now:
How can I watch the network traffic and filter them that I know at which point the successful or failed status packet comes in?
I found PhantomJS Network Monitoring.
Basically I want to call a function after I clicked the button automatically with protractor, and this function should look into every packet that is coming in and should stop when it reads that the status is successful. If it takes more than 60 or 70 seconds the function should time out.
After clicking the button which triggers POST method you should start listening in a loop another endpoint (GET) every n seconds (you wrote that app does it every 2 seconds).
If status is waiting - keep going, if it's failed - raise an exception and fail the test, if it successful - pass the test or do whatever you want.
The loop will prevent you from timeout.
You need to consider whether you need to protect yourself from the infinite loop if e.g. worker which processes the task stops working. Then GET method may return waiting, the loop won't finish and the test won't stop.
I am using "connect-timeout": "^1.7.0" as a top-level middleware in my express.js 4.12 ("express": "^4.12.3") app. I have no problem in using it as such. I can set the timeout to 50 seconds, 5 seconds, 1 second, all of which function perfectly fine. HOWEVER, I'm noticing that if I set the connect-timeout timeout value to anything greater than 110 seconds, the app will still timeout after 110 seconds with the following message:
"HTTP request was terminated because the script did not produce output for 110 seconds"
Is there some other setting that needs to be adjusted? I can't find any reference of such a setting. Any help or insight would be very much obliged! Let me know if you need any more info from me. Thanks!
Best,
Chris
(Do not worry that the process itself is taking more than 110 seconds, this is intended behavior)
It might be possible but I doubt it. Only your own custom client would wait that long though. And if its your client you might still need to output something to keep the connection open. You could output a newline or . every 30 seconds.
Interested to hear if there is a way. I have found that people really don't want to leave idle HTTP connections open so you are swimming upstream.
Are you sure your client didn't disconnect?
Other options are things like RPC, TCP server, polling an HTTP endpoint for status.
The node.js app is hosted on an Apigee Private Cloud VM cluster, and the timeout is occuring due to a timeout property on the Router/Message Proc. VM.
Within the nodejs.properties file, the property http.request.timeout.seconds is set to 110 seconds by default. One could augment this value to the desired value or set it to 0 (which effectively disables the timeout).
Best,
Chris
Hi I'm new user to atmosphere, and set up a simple test that worked fine. We used long-polling, and the behavior was that my client would send the server a GET that would stay open until:
data was returned by the server
a minute elapsed
in both cases, the client would immediately send another GET for the server to hold open. Most of the time no data was sent, so every minute the GET would be "refreshed." I assumed this was the default behavior because maybe certain browsers or networks would shut off a GET that exceeded a certain time limit, so this was a way to avoid that.
Question:
Is this refresh controlled by the client or the browser? I poked around and couldn't figure out if the client was closing the connection on its own and sending a new request, or if it was the server.
The reason I ask is that the server got deployed, and now that refresh is no longer occurring. My client GET now stays open to the full 5 minute (default) timeout and then throws the timeout event, then reconnects for another 5 minutes.
Server team claims "nothing changed," ha-ha. So did I do something or what? Please let me know! Thank you!
request object:
var request = {
url: 'xyz',
transport: 'long-polling',
reconnectInterval: 5000,
maxReconnectOnClose: 20,
enableXDR: true
};
Edit: the atmosphere server was changed from 2.1.3 (working) to 2.0.7 (not working) when the deploy occurred. When changed back, the 1 minute refresh behavior re-appeared. The problem is that 2.1.3 is not compatible with the server they are using, thus the down-grade.
Question: what is this feature called, is this the heartbeat or something else? Can someone tell me what change was made that would cause this. I've looked through the release notes and nothing jumped out at me.
we have an application where button click in flex side restarts the server and makes the client logged out. once after logout, If user logs in it gives error since the server is not up by the time. In our scenario the server takes time to restart because of the stuff(like back up). I want the user to be notified of the webserver status if he tries to log in.
is there any way to monitor the status of server in Flex side. or Will javascript help in finding whether the server is up or not?.
Also I tried redirecting to html page using external interface but I am not sure how to automatically redirect it again to the swf file when the server becomes active.the server downtime is not known(may be 2 or 5 or 10 minutes.)
So what would be the best approach.Any help would be of greatly appreciated.
Using URLLoader you can try to download a file on the server and listen to ioError or httpStatus.
private var testLoader:URLLoader;
private var testRequest:URLRequest;
...
testRequest = new URLRequest("http://server/testFile");
testLoader = new URLLoader(request);
testLoader.addEventListener(HTTPStatusEvent.HTTP_STATUS, onStatus);
private function onStatus(HTTPStatusEvent:event):void
{
//test the status, if the server is up, reconnect, else...
testLoader.load(testRequest);
}
Interesting problem. When you mean restart, do you mean just a specific service like Apache or like an actual reboot of the server? I ask because it would mean different scenarios. I'm not exactly sure what you're doing, but I'll assume that you're rebooting the server.
One of the problems here is that the client logs out, which is something we do not want. What I would do is have a second server which it's sole purpose would be authentication and giving status on the other server. This is a 'man in the middle' approach where this server doesn't log you out, but all calls are redirected to the other server.
From the Flex side, you can have it calls the 'man in the middle' to see what's the status. Depending on the technology you're using (polling vs pushing), you can get the data needed and show the user the status.
I have a web application and use ajax to call back to my webserver to fetch data.
Sometimes(at rather unpredictable moments, but it can be reproduced) IE hangs completely for 5 minutes(the window says Not Responding) and then comes back and the xmlhttprequest object responds with error 12002.
The way I can reproduce it is as follows.
Open window(B) from main window(A) using button
Window A calls synchronous ajax(PROC1) when button is clicked to open window B. PROC1 Runs file.
New window(B) has ajax code(PROC2) and calls server asynchronous. Runs fine
User closes Window B after PROC2 completed but before data is returned.
In Main Window(a) user clicks button again. PROC1 runs again but now the send() call blocks for 5 minutes.
Please help. I've been looking for 3 days.
Please note:
* I can't test it in firefox (the app is not firefox compatible)
* I have to use synchronous calls (that's the way the app is constructed and it would take too much developer effort to rewrite it)
Why does this happen and how to I fix this?
You're right Jaap, this is related to Internet Explorer's connection limit of 2. For some reason, IE doesn't release connections to AJAX requests performed in closed windows.
I have a very similar situation, only slightly simpler:
User clicks in Window A to open Window B
Window B performs an Ajax call that takes awhile
Before the Ajax call returns, user closes Window B. The connection to this call "leaks".
Repeat 1 more time until both available connections are "leaked"
Browser becomes unresponsive
One technique you can try (mentioned in the article you found) that does seem to work is to abort the XmlHttp request in the unload event of the page.
So something like:
var xhr = null;
function unloadPage() {
if( xhr !== null ) {
xhr.abort();
}
}
Another option is to use synchronous AJAX calls, which will block until the call returns, essentially locking the browser. This may or may not be acceptable given your particular situation.
// the 3rd param is whether the call is asynchronous
xhr.open( 'get', 'url', false );
Finally, as mentioned elsewhere, you can adjust the maximum number of connections IE uses in the registry. Expecting visitors to your site to do this however isn't realistic, and it won't actually solve the problem -- just delay it from happening. As a side-note, IE8 is going to allow 6 concurrent connections.
Thanks for answering Martijn.
It didn't solve my issues. I think what I'm seeing is best described on this website:
http://bytes.com/groups/javascript/643080-ajax-crashes-ie-close-window
In my situation I have an unstable connection or a slow webserver and when the connection is too slow and the browser and the webserver still have a connection then freezes.
By default Internet Explorer only allows two concurrent connections to the same website for download purposes. If you try and fire up more than this, I.E. stalls until one of the previous requests finishes at which point the next request will complete. I believe (although I could be wrong) this was put in place to prevent overloading websites with many concurrent downloads at a time. There is a registry hack to circumvent this lock.
I found these instructions kicking around the internet which alleviated my problems - I can't promise it will work for your situation, but the multi-connection limit you're facing appears related:
Click on the Start button and select Run.
On the Run line type Regedt32.exe and hit Enter. This will launch the Registry Editor
Locate the following key in the registry:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
Click on the Internet Settings Key.
Now go to the Edit menu, point to NEW
click DWORD Value
Type MaxConnectionsPer1_0Server for the name of this DWORD Value.
Double-click on the MaxConnectionsPer1_0Server key you just created and enter the following information: Value data: 10. Base: Decimal.
When finished press OK.
Repeat steps 4 through 9. This time naming the key MaxConnectionsPerServer and assigning it the same values as indicated in Steps 8.
When finished press OK
Close the Registry Editor.
Of course, I would use these in conjunction with the abort() call previously mentioned. In tandem, they should fix the issue.
IE5 and IE6, indeed, do hang when attempting to receive data from a PHP script. The reason is that these browsers can not decide when has all of the data been received and the connection can be closed. So they wait until connection expires (thus the 5 or 10 minute hang). A way to solve this is to tell to the browser how much data it will receive. In PHP you can do that using output buffering, for example as follows:
ob_start();
echo $html_content;
header( 'Connection: close' );
header( 'Content-Length: '.ob_get_length() );
flush();
ob_end_flush();
This is a solution when one is just loading a normal web page. When one is using
AJAX GET via Microsoft.XMLHTTP object it is enough to
send the "Connection: close" header with the GET request, like
r.request.open( "GET", url, true );
r.request.setRequestHeader( "Connection", "close" );
r.request.send();
Winsock Error 12002 means the following according to msdn
ERROR_INTERNET_TIMEOUT
12002
The request has timed out.
Winsock is the underlying socket transfer object for XMLHTTP in IE so any error thats not in the HTTP error range (300,400,500 etc) is almost always a winsock error.
What wasnt clear from your question is wheter the same resource is being queried the 2nd time round. You could force a new uncached resource by appending:
'?uid=+'Math.random()
To the URL which might solve the issue.
another solution might be to attach a function to the "onbeforeunload" event on the window object to call abort() an any active XMLHTTP request just before the window B is closed.
Hope these 2 pointers solve your bug.
All these posts - Disable PDF reader.. and that stuff... will not resolve your problem...
But sure shot is - RUN WINDOWS UPDATE .. keep uptodate.. This issue gets resolved by itself..
Experience speaks ;)
HydTechie