I've been working on an app that uses the LBAPI to gather all the leaf work items within our workspace when the app is first ran. This is expected to take some time, seeing as there are over 25,000 and I'm pulling several fields for each item. However, recently the requests seem to be timing out at around the 30 second mark. I would assume this is a setting within the SDK, however I found no way to change the timeout anywhere in the documentation. To make matters worse, rather than returning to the callback function an "unsuccessful" response, there is no response at all, which makes exception handling much more difficult on my end.
I was wondering, is there in fact a way to increase this timeout? And if not, is there are more elegant way to catch that event, rather than simply setting a timer on my end as well, and assuming once it gets to zero without a request there was an error?
Thanks!
30 second default is probably low for 20K page size. Changing pagesize to 10k with limit set to infinity may help. Also, given a Rally.data.WsapiDataStore or Rally.data.lookback.SnapshotStore try
store.getProxy().timeout = 60000;
Related
I've been trying to solve this issue for a few weeks now. The issue revolves around a Cordova plugin called cordova-plugin-playlist that utilizes AVQueuePlayer.
The issue is that when a large number of tracks (30+) are added, several of the tracks time out when attempting to buffer. Because of this, AVQueuePlayer is only able to play some of the tracks that I'm attempting to load (it just skips the error tracks when attempting to play them). The tracks that time out are always random. Attempting to add only the first 15 or so tracks from the same list succeeds, so it appears to be directly related to the number of tracks being added.
What I've figured out by logging the requests to my server is that AVQueuePlayer is attempting to buffer all of the tracks all at once, rather than buffering only the current and maybe the next track. When there are 20 or fewer tracks, all of the tracks load and play fine, but when there are 30 or more, the request seems to be too much to handle, and the requests begin to time out before some of the tracks are able to load.
All of the tracks are added via AVQueuePlayer's insertItem method. Is there something about this method that causes a track to immediately begin buffering as soon as it is added? Is there a way to prevent this behavior? I would like only the current and next tracks to buffer. Or am I fundamentally misunderstanding something? Thanks in advance for all your help!
I've solved the issue. In case it helps anyone, it wasn't an issue with AVQueuePlayer itself, but rather with the subclass AVBidirectionalQueuePlayer included with the cordova-plugin-playlist plugin. The issue lies within the overridden insertItem method in AVBidirectionQueuePlayer.m (line 217 in my case).
if (CMTIME_IS_NUMERIC(item.duration)) {
NSLog(#"duration: %5.2f", (double) CMTimeGetSeconds(item.duration));
if (CMTimeCompare(_estimatedDuration, kCMTimeZero) == 0)
_estimatedDuration = item.duration;
else
_estimatedDuration = CMTimeAdd(_estimatedDuration, item.duration);
}
The item.duration call triggers the track to load (and it's called each time a track is added, so it triggers ALL of the tracks to load), which is fine for a smaller number of tracks, but with 30+ tracks, some an hour or longer, my server was overloaded and the requests were timing out.
In my particular instance, it seems that item.duration is never NUMERIC here anyway, so my solution was to comment out the IF statement entirely.
I've build an iOS app that uses the iOS SquarePointOfSaleSDK which returns me a transaction Id and nothing more. Since I need more information about the payment (e.g: method, how many tenders, etc.) I'm calling the RetrieveTransaction Connect API v2 service immediately when I receive the transaction id from the Square POS app and this normally works, but sometimes I get the error described below.
{"errors":[{"category":"INVALID_REQUEST_ERROR","code":"NOT_FOUND","detail":"Location `XXXXXXXX` does not have a transaction with ID `YYYYYYYYYYYYYYYYYYYY`.","field":"transaction_id"}]}
When this transaction actually exists in this location.
I'm guessing the transaction, sometimes, is not available for API actions that fast, but I couldn't find anything in the documentation about this, I'd really appreciate any help or guidance in this, thank you in advance.
Yes, there can sometimes be a small delay between Charge and the transaction actually being retrievable. Unfortunately I'm not sure on how long the delay can be but I'll make sure this gets added to our documentation.
For now, I would suggest that if the error occurs, just to have the code attempt the RetrieveTransaction call again, perhaps looping until it's available. You should probably also include a way to get out of it (after X time or something), just to prevent the rare possibility of an endless loop.
I have encountered a problem, that Google notifications quite often do not arrive without any apparent reason. This makes them almost unusable for me, since it seems like they appear just in 60% of cases.
Is this common? Should I stop relying on them and set up a one minute scheduler for syncing event insted?
Thanks for your opinion
AFAIK, notification is not 100% reliable also stated in the document. As an alternative you could use Incremental sync:
Incremental sync allows you to retrieve all the resources that have been modified since the last sync request. To do this, you need to perform a list request with your most recent sync token specified in the syncToken field. Keep in mind that the result will always contain deleted entries, so that the clients get the chance to remove them from storage.
Hope this helps.
Let's say that I need to get a NSURLRequest that will return a HTML page.But I need to read only part of the information, because the page is too huge: about 55 KB and I am doing it in the main thread (my bad, I should have done this in another thread, but now it's too complicated, I should rewrite too many lines), so it makes the views responses very slow.
The point is that I need only a small part of the page, composed by few bytes.So I would like to receive just the part of the HTML page included in some tag.How do I do this with a NSURLRequest?
You could make a HEAD request of te information you need is in the response headers. If you need a fragment of the body then I think you are out of luck.
In either case you will probably still need to get that request off the main thread. Downloading less data is not going to reduce the latency of your connection and this request will continue to block the UI thread. Mobile connection round trip times can be seconds long and you can't control that.
Edit: as an example, I'm posting this answer from a device which is averaging 369kbps down but with an 1124ms latency. Every time an app makes a synchro is request on the main thread I'm going to watch the UI freeze for over a second no matter what you do to try to optimize the downloaded data.
Using ThreadPoolRuntime, I could get a throughput attiribute that means "The mean number of requests completed per second". It's not what I want. I want to get realtime figure that is not the mean number.
Requests per second is by it's nature an average, so I'm not too sure what you mean by a realtime figure - do you want the number of requests completed in the last second?
The ApplicationRuntimes/[appname]/WorkManagerRuntimes/default/CompletedRequests gives the total number of requests completed for one application, you can use this to calculate an RPS figure over whatever timeframe you want.
Unless this is a custom work manager's thread pool, the number you're going to get back isn't going to be terribly meaningful. And even in the case of a custom thread pool assigned to your particular application component (EJB, WAR file, etc) then the number still isn't likely to mean what you're looking for.
The thread pool is used to perform all work for that component (or in the case of the default thread pool, all work for the server, both internal and client-driven. This means that requests of wildly different 'cost' in terms of CPU and execution time go through the same pool.
What is the problem that you're trying to solve? Is it an understanding of how many requests per second are occurring for particular application components? You might want to look at WLDF as an alternative source for this kind of data, although in either case you'll need to post-process information to get something useful.