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.
Related
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
I have an app that I want to apply the cordova "pause" and "resume" functionality to. I have the "pause" implemented. Inside the "Pause" listener, I log the user out. What I need is to only log the user out if the "pause" is for longer than 5 seconds. So if the user leaves the app, then in under 5 seconds returns to the app, I do not want to log them out, but allow them to continue to use the app.
I have used the following, but it just waits 5 seconds and then logs them out even if they return.
$timeout(function(){
myLogoutFunction(); //I want to cancel this if the user returns before the function fires.
}, 5000);
You need to cancel the $timeout. Try $timeout.cancel(promise) when the app resume event is fired, this will abort the operation. Or with simple javascript:
// on pause
let _timer = setTimeout(function(){
//logout the user
}, 5000);
// on resume
clearTimeout(_timer);
$timeout is just a wrapper for setTimeout.
Hope this provides some insight.
In Ionic 1, the 'pause' event handler will never actually be called on iOS because the web view that the app is running in is immediately halted.
I have used the following, but it just waits 5 seconds and then logs them out even if they return.
The actual 'pause' event handler will be called on the subsequent 'resume' event being fired. The user of timers won't work in this scenario because they will be queued on 'resume'. Instead you could keep track of the last action done by the user, manage session via local db that can be serialized to the file system, or manage the session remotely and destroy the logout remotely and check if the session is still valid on 'resume'. If the session is no longer valid than redirect back to the login screen. However, in these scenarios you'll probably want to increase the timeout period to a time greater than 30 seconds. Maybe 10 minutes would be a better number.
This is a consequence of Cordova using a webview which doesn't have access to the underlying native lifecycle events.
You could try using the ng-idle module however, I haven't actually used it so I can't say whether or not it works but it says it keeps track of touches/scrolls etc. to maintain when a user was last active.
See this question for additional information on ng-idle and potential other approaches to detecting idle users.
Currently, I want to check status of socket when network is down with connected property. But i have an issue when unplug network cable, the connected status still true for 20 seconds or more. How can i get the status immediately ?
You'll have to set the timeout option, which by default is set to 20.000 MS (20 seconds). You can find a lot of information here: http://socket.io/docs/client-api/#
I would disrecommend making it absolutely instant though. Most if not all networks have some instabilities, which are accounted for by the timeout delay. It's there for a good reason. Maybe just make it a bit shorter?
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})
I have an application which uses an open JQuery Ajax connection to do long-polling/comet handling of updates.
Sometimes the browser and the server lose this connection (server crashes, network problems, etc, etc).
I would like the client to detect that the update has crashed and inform the user to refresh the page.
It originally seemed that I had 2 options:
handle the 'error' condition in the JQuery ajax call
handle the 'complete' condition in the JQuery ajax call
On testing, however, it seems that neither of these conditions are triggered when the server aborts the query.
How can I get my client to understand that the server has gone away?
Isn't it possible to add a setInterval() function that runs every few seconds or minutes? That way you can trigger a script that checks whether the server is still up, and if not, reset the comet connection. (I don't know what you use for the long-polling exactly though, so I don't know if it's possible to reset that connection without a page reload. If not, you can still display a message to the user).
So something like this:
var check_server = setInterval(function() {
// run server-check-script...
// if (offline) { // reset }
}, 60000);