In our Logic App, if we run two HTTP POST actions in parallel (with separate URI's), they will sometimes call the same URI. We been able to replicate this several times. Has anyone else seen this? Attached is an image to make it more clear: In Designer the URIs differ between the branches, but at run times they are the same, sometimes.
Related
I have a an application that uses Angular for the frontend and communicates with an API running Django RF.
Now, let me try and outline what I'm trying to achieve in hopes of finding an easy solution.
When a user runs a report, a worker version of the API generates the report to prevent the main API from bogging down. The report runs for a couple seconds/minutes. The user refreshes the page and voila, their report is there.
What I'm trying to achieve is the elimination of the whole "user refreshes the page" portion of this process.
My goal is to do this via websockets.
I literally want something as simple as:
WEB: "Hey API, I want this report. I'll wait."
API: "Yo dog, you're reports done."
WEB: "Cool, let me refresh my report list. Thanks bud."
Now, we start to venture into an area I'm unfamiliar with. Websockets can do this, right? I just need to create a connection and wait for the all-clear to be sent by the worker.
Now, here's where it gets hairy.
I've spent the better part of the day going through libraries and just can't find what I need. The closest I've come is this, but it clashes with restframework. I get hit with tons of 404 errors and I think it has to do with the way rf manages urls.
I literally need a simple event listener. There's got to be a better way, right? To clarify, I don't want to do something brute-force like silently ping the API for report status. That gets a tad hinky. I want the API to tell me when it's ready.
In a basic way, can use something like django-websocket-redis and use Django signals to pass the messages around. ws4redis handles alot of the tricky bit. However, websockets are weird and honestly I doubt you need them. You could just poll some route that has the job state. If you need to get it done fast, I would go that route.
I'm writing Protractor tests to verify the successful creation of reports in our application. A report is created via a series of complex UI interactions within a dialog and saved via an AJAX POST request to a REST API.
I've written tests for the complex UI interactions within the modal, but I'm at a loss for how to test the POST request within the same Protractor tests. Ideally, I'd like to be able to make assertions against the payload of the POST request to verify that the UI is sending the correct data to the API.
It's important to note that I do not want to mock the HTTP call--I need it to go through, since subsequent protractor tests navigate to the report and perform additional checks. My first thought was to somehow hook into the $httpBackend.passThrough() method, but I haven't had any success with that.
Any ideas how to accomplish this?
since subsequent protractor tests navigate to the report and perform additional checks
If you check that the report contains data to that matches which was submitted, you are, albeit indirectly, testing that the POST went through successfully. There is a reasonable argument that this is enough for the E2E test: it tests that the application behaves as he user would want. The user doesn't care how it's achieved: POST, websockets, carrier pigeon ;-)
Keep in mind that the usual aim of such tests is for them to fail if something is broken. If the POST isn't done correctly, then the subsequent tests that verify the displayed report would fail.
The downside is that you would have a bit less information about what has gone wrong than if you managed to test the POST as well. However, unit tests can help. If you have a failing unit test that localises the issue, you write a fix that makes it pass. If you don't have a failing unit test, you can investigate the issue by debugging, add a failing test that highlights the issue, and fix the code so it passes.
I had the idea to make a SPA application using angularJS and then just sending AJAX updates to the server when I need.
My initial idea would be make the client application fly, but if I have to do an AJAX round trip to the server, I think the time would be approximately the same as to request a single web page.
Requesting a page just has more bytes of data, is not like I'm requesting 20 resources like in this article: https://community.compuwareapm.com/community/display/PUB/Best+Practices+on+Network+Requests+and+Roundtrips
I would be requesting a page or resource per request.
So in the end even if I create my client side application as a SPA using angularJS, these requests (would have to be synchronous and show a please wait message while they don't return, as I don't want to user to take more actions before I make sure his request passes validation and is processed correctly) would take some time and make user wait, just about the same time as requesting a full page.
I think SPA pages would be very useful if I have like a wizard on my app with multiple pages/steps and at the end, submit the results of wizard, to the server, which I don't.
Also found this article:
https://help.optimizely.com/hc/en-us/articles/203326524-AngularJS-Backbone-js-and-other-Single-Page-Applications
One of the biggest advantages of Single Page Apps is that they reduce
data transfer. As a result, pages after the initial loading usually
can be displayed faster and seem more interactive.
But I don't believe this last quote is really true.
Am I right, or is there a way that I'm not seeing to build an application that would look like it's executing locally?
I know how guys will start saying "depends on what you want", but lets focus on this scenario where there's no wizards.
What ever you said is right. But most of the frameworks(Angular,BackBone) you take they are going to cache the templates of html on the browser so the rendering would be pretty fast compared to the normal applications. Traditional apps will have to fetch the html from the server for each request which is a time consuming one.
Hope this helps you!!!
If you are wanting to go through that syncronous server side validation step for each page request, then there is probably no big advantage to using AngularJS.
If you are requesting a page and then manipulating that page's contents once it's loaded you might want to consider AngularJS. A good example would be requesting a page that displays a list of items. Now let's say we want to search that list or order it in different ways. Rather than using AJAX to call the server to filter the list and then re-render it, it could be much faster to user AngularJS to filter and re-render the list without making any further requests to the server.
I'm having an issue where a long synchronous request will freeze Internet Explorer.
Let me explain the context : this is a web application which only supports IE8 and which can only use Synchronous*.
We have a Silverlight component with a save button. When the user presses the button, some information is sent to the server using a synchronous XMLHttpRequest, then some other actions are done client-side in the Silverlight component.
The server-side part includes calculations that will sometime take a while (several minutes).
In short, here is the code (c# silverlight part)
ScriptObject _XMLHttpRequest;
_XMLHttpRequest.Invoke("open", "POST", url, false);
_XMLHttpRequest.Invoke("send", data);
checkResponse(XMLHttpRequest);
doOtherThings();
I know that the server does its work properly because I can see in the verbose logs, the end of the page rendering for the "url" called from Silverlight.
However, in debug mode I can see that I never reach the "checkresponse" line. After calling the "send" line, IE will freeze forever, not unfreezing once the server log shows that "url" has been processed.
Also, I tried to add "_XMLHttpRequest.SetParameter("timeout", 5000)" between the "open" and the "send" lines. IE freezes for 5 seconds, then "checkresponse" and "dootherthings" are executed. Then IE freezes again while server-side calculations are processed and doesn't unfreeze once the server is done with its work.
IE timeout is supposed to be 3 hours (registry key ReceiveTimeout set to 10800000), and I also got rid of IE 2-connexions limit (MaxConnectionsPer1_0Server and MaxConnectionsPerServer set to 20).
Last important information : there is no issue when the server-side part only takes a few seconds instead of several minutes.
Do you know where the freeze could come from (IE bug, XMLHttpRequest bug, something I have done wrong) and how I can avoid this ?
Thank you !
Kévin B
*(while trying to solve my issue with the help of Google I found an incredible amount of "use asynch" and "synch is bad" posts; but I can't do this change in my app. Switching the application, ajax loads, and all server side calculations to asynchronous is a huge work which has been quoted for our client and is a long-term objective. I need a short-term fix for now)
Silverlight virtually requires that everything be done asynchronously. Any long running synchronous process will hang the browser if run on the UI thread. If you never reach the 'checkResponse' line of code it is possible that an unhandled exception was thrown on the previous line, and it is being swallowed. You can check in the dev tools of your browser to see if there are any javascript errors. I am surprised that calling XMLHttpRequest synchronously works at all since I would expect it to lock up the UI thread. But, the solution depends on your definition of async.
You can try:
calling the sync XHR request on a background thread and then marshalling to the UI thread (eg with Dispatcher.BeginInvoke) when you are ready
setting up an XMLHttpRequest wrapper that makes the call in async mode and raises a callback in Silverlight on completion
using HttpClient or WebClient
While these options are async, they don't require your server code to be written any differently (it can stay synchronous). I have seen a web server process a call for over an hour before finally returning a response, at which time the Silverlight app raised a callback. You could even use tools like the TPL await/async, or co-routines available in many mvvm frameworks to make the code appear very procedural/synchronous while still performing its actions asynchronously.
I hope you already solved your issue, but maybe this will be helpful to whomever may come across this post.
I am using the JW Embedder with JWPlayer to embed 3 videos on a page. (I'm pretty sure the sitatuion would be the same if using SWFObject to do the embedding.
To my horror (!) when looking in Fiddler I saw 3 downloads (HTTP Status 200) for jwplayer.swf which is an unnecessary 200kb.
Obviously what's happening is that the javascript for the embedder just spews out the code to instantiate the flash object and then the browser initiates 3 requests for the 100kb jwplayer.swf file.
It isn't clever enough to wait for jwplayer.swf to load and then use it for the 2 other players.
How can I make sure that jwplayer.swf is only loaded once.
It is up to the browser to decide how to deal with multiple requests for the same objects. Most browsers will save the assets in a cache and either skip the subsequent requests and serve directly from the cache, or they send a different type of request which checks to see if the content has changed on the server.
Either way, there's no way for the player itself to control this behavior. That said....
If you're down with HTML5, you can try making a cache manifest for the swf.
This script looks promising: http://blog.sebastian-martens.de/2010/05/preload-assets-with-javascript-load-complete-callback-for-single-assets-include-swfflash/ You can preload the first player and then the next two as a post-load callback (See comment 9).