Develop Reference

javascript canceled request after 50 seconds

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

Monitor Chrome Network traffic (XHR packets)

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.

express.js 4.12 connect-timeout upper limit?

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

Socket.IO - How to change timeout value option on client side?

I use Socket.IO 0.9.16 to establish a connection:
io.connect(url)
However, when the server dies, it takes 2 minutes timeout to detect error with the server.
I already tried to reduce timeout to 5s by setting:
io.connect(url, {'timeout': 5000, 'connect_timeout': 5000})
But no success... How can I do this?

The challenge here is that there are a bunch of different settings that interact with each other and some retry logic that all make a socket.io timeout not what you would normally expect. I should add that I am familiar with socket.io 1.0+, not 0.9 though this probably applies to both.
Lets review how a socket.io connection works.
It attempts to make the initial connection.
If that succeeds, then you're done with the connection.
If that connection attempt does not return immediately, it will wait the timeout value that you pass in the initial options for a connection result.
If your server is down, the connection attempt will likely fail quickly. This will result in a connect_error and if you register for that message on the socket with socket.on('connect_error', function() {...});, you will see that connect_error event.
This connect_error is not a timeout. So, if the connection fails quickly (which it usually does when the server is just down), then you never get the regular timeout and the timeout argument you pass to io({timeout: 5000}) really doesn't come into effect. That only comes into effect when a connection to a server is just taking a long time (like an overly busy server or a server that accepted the TCP connection, but is really slow at responding). This is not usually what happens when a server is just down or unreachable.
So, after socket.io gets a connect_error it marks this socket.io connection for retry.
The delay before retrying is based on a whole bunch of things. Presumably, the reconnectionDelay option is part of the formula, but in looking at the code, there is also a backoff algorithm that lengthens the time between retries the more times it has retried. So, suffice it to say, there's some algorithm that calculates a given delay before retrying that varies for each retry.
Then, after that calculated delay, it tries to connect again. This essentially repeats the process starting at step 1 again.
As best I can tell, by default it keeps retrying forever. There is an option you can pass reconnectionAttempts that specifies the maximum number of reconnection attempts. This default to infinity if you don't pass it. But, if you pass 10, then it will give up after 10 successive connection failures.
If you specify reconnectionAttempts, then after that many unsuccessful connection attempts, you will get a reconnect_failed event on the socket and it will give up.
As best I can tell, there is no traditional timeout in the way that you are looking for where it would connect, attempt some retries, then give up after x amount of time. The timeout option applies only to a single reconnect attempt and not to the total amount of time it keeps trying to connect.
In a sample test page I've been experimenting with, I was able to implement my own traditional connection timeout like this:
var socket = io(...);
// set connect timer to 5 seconds
socket._connectTimer = setTimeout(function() {
socket.close();
}, 5000);
socket.on('connect', function() {
// socket connected successfully, clear the timer
clearTimeout(socket._connectTimer);
});
This will wait a maximum of 5 seconds for a successful connection, regardless of how long a connection attempt takes or many reconnect attempts occur in that span of time. After 5 seconds without a successful connection, it shuts down the socket.
In my test app, I can see socket.io happily retrying the connection over and over again until after 5 seconds, my timer fires, I get notified of the "timeout" and I close the socket and it stops trying to retry any more.

I think it is connect timeout
io.connect(url, {'timeout':5000, 'connect timeout': 5000})

atmosphere-javascript long-polling not "refreshing" every minute

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.