in my application i have 20 icons(bitmap fields) on the home screen
When i click on any icon an HTTP request is made in a separate thread.
I have used invoke later method wherever necessary to take care of multi-threading problems.
But still the number of threads goes beyond 16 and an error pops up indicating too many threads error and applications needs to be restarted!!
can anybody tell me how to destroy these threads when they are no longer in use.
I don't understand why they don't destroy on their own as usually they do.
I tried to go ahead with active count of thread
If that count exceeds beyond the limit set by me then i queue up the request
and then send them later on after sometime.
but this delays the response.
I had no other option other than this
Thanks for help!!!!!!!
Related
What is the difference between rate limiting and back pressure? Is it mainly that rate limiting is the client slowing down on its own and back pressure is the service dropping requests to slow down?
Rate limiting detects that some action is happening too much in some time frame, and prevents it from happening again until that time frame is over.
For instance, say I have an application that sends an email every time an error is generated. The application talks to a queue that gets polled multiple times a second. So if there is a misconfiguration of the queue then the application can generate thousands of emails in an hour. Adding rate limiting can keep track of the number of error emails sent within a time frame and stop sending emails when the count gets high enough. Or the application could back off polling the queue for some time interval.
Back pressure means that the system refuses to take more work. Unlike rate limiting there is no set time where the application resumes taking on work, it depends on the application detecting it has capacity.
If I have an application that receives work through a fixed size blocking queue, then, once the queue fills up, anything that tries to put a new entry in the queue will wait until the queue can make room for it. That way the application doesn’t take more work than it can manage, causing it to run out of memory or otherwise getting into a bad state.
I want to create SQS using code whenever it is required to send messages and delete it after all messages are consumed.
I just wanted to know if there is some delay required between creating an SQS using Java code and then sending messages to it.
Thanks.
Virendra Agarwal
You'll have to try it and make observations. SQS is a dostributed system, so there is a possibility that a queue might not immediately be usable, though I did not find a direct documentation reference for this.
Note the following:
If you delete a queue, you must wait at least 60 seconds before creating a queue with the same name.
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html
This means your names will always need to be different, but it also implies something about the internals of SQS -- deleting a queue is not an instantaneous process. The same might be true of creation, though that is not necessarily the case.
Also, there is no way to know with absolute certainty that a queue is truly empty. A long poll that returns no messages is a strong indication that there are no messages remaining, as long as there are also no messages in flight (consumed but not deleted -- these will return to visibility if the consumer resets their visibility or improperly handles an exception and does not explicitly reset their visibility before the visibility timeout expires).
However, GetQueueAttributes does not provide a fail-safe way of assuring a queue is truly empty, because many of the counter attributes are the approximate number of messages (visible, in-flight, etc.). Again, this is related to the distributed architecture of SQS. Certain rare, internal failures could potentially cause messages to be stranded internally, only to appear later. The significance of this depends on the importance of the messages and the life cycle of the queue, and the risks of any such an issue seem -- to me -- increased when a queue does not have an indefinite lifetime (i.e. when the plan for a queue is to delete it when it is "empty"). This is not to imply that SQS is unreliable, only to make the point that any and all systems do eventually behave unexpectedly, however rare or unlikely.
In the comments of this answer I was having a discussion about backgroundTasks which eventually led to:
Use backgroundTasks for anything that isn't related to download/upload. For upload/download use NSURLSessions's backgroundSessions. Then I made another comment asking why not use background Sessions for all types of requests and was told:
For regular REST calls, background sessions are much less convenient,
and generally not what you'd want. They're not a general purpose tool
for every request; they're for performing uploads and downloads.
What makes background sessions less convenient for REST calls? Sometimes you may have slow internet with a huge chunk of data. Wouldn't it be a convenience to make sure all your data submissions go through?
I'm not sure but if you're doing something like a bank transaction, you wouldn't want to use a backgroundSession. Because you want the user to know of the decision before they leave. User should never the assumption that they could leave app and app would continue to work as should. Nor they should be under the impression that they can resume (by a downloadTaskWithUrl).
What happens if for some reason the user makes a $2000 transaction and hits the button expecting the transaction to go through but it doesn't. The next time the user comes back to the screen they could either be logged out due to security reasons and never know about it or stay logged in but they see an alert that the transaction failed. And now they're like "Oh no my daughter needed $2000 urgently. She must be still waiting for the money!".
You don't want to allow users to have bad expectations*. Rather you want users to take FULL responsibility themselves and not hit home screen and wait for the success/failure. So once the user clicks on submit transfer he'd wait for it to either get success and move on or see failure and wait and investigate the reason his transaction didn't go through.
You usually convey the possibility of failure through an spinner/animation and the actual outcome (failure or success) through an alert.
*Bad expectation is: Every time I hit the the submit transfer button it will go through and there's 0 chance of failure and no need for you to wait and see it go through.
We are working on a billing invoice system. As a part of processing our request, we need to make an asynchronous call by placing a message in a queue. We work at 20TPS and have SLA for entire transaction of 12 sec. Occasionally, we have observed that when MQ server becomes very slow but still operational it's taking a lot of time just to write the message in the queue. We want to handle this scenario and have a system that throws an exception when it exceeds a predefined limit for writing the message in the queue.
In simple words, we want to implement a write timeout when there is a delay in writing a message in the queue. Any help is appreciated.
We are aware of mentioning timeout for receiving the response but we are unable to find any fix for mentioning timeout while writing the message in the queue.
We have found some suggestions on revalidating the destination. But in our case, we already know the destination is operational and our system becomes slow only during the response.
Here is the problem that I got. I have several tasks to complete in background when application is running. When I run these tasks in background by pushing them to concurrent dispatch queue it takes more then 10 seconds to complete all of them. They basically load data from disk and parse it and represent the result to the user. That is they are just cached results and hugely improve the user experience.
This cached results are used in a particular functionality inside the app, and when that functionality is not used immediately after opening the application, it is not a problem that it takes 10 seconds to load the data that supports that functionality, because when user decides to use it, that data will already be loaded.
But when user immediately enters that function in the app after opening it, it takes considerable time (from the point of view of the user) to load the data. Also the whole data is not needed at the same moment, but rather the piece of it at a given moment.
That's why we need concurrently load the data, and if possible bring the results as soon as possible. That's why I decided to break the data into chunks, and when user requests the data, we should load the corresponding chunk by background thread and give that thread the highest priority. I'll explain what I mean.
Imagine there are 100 pieces of data and it takes more than 10 seconds to load them all. Whenever user queries the data first time, the app determines which chunk of the data user needs and starts loading that chunk. After that part is loaded the remaining data will also be loaded in the background, in order to make later queries faster (without the lag of loading the cache). But here a problem occurs, when user decides to change the query immediately after he has already entered one, and that change occurs for instance on the 2nd second of data loading process (remember it takes more than 10 seconds to load the data and we still have more than 8 seconds to complete the loading process), then in the extreme case user will receive his data waiting until all data will be loaded. That's way I need somehow manage the execution of the background tasks. That is, when user changes the input, I should change the priorities of execution, and give the thread that loads the corresponding chunk the highest priority without stopping it, so it will receive more processor time, and will finish sooner, and deliver results to the user faster, than it would if I have left the priorities the same. I know I can assign priorities to queues. But is there a way that I can change them dynamically while they are still executing?
Or do I need to implement custom thread management, in order to implement these behaviour? I really don't want to dive into thread management, and will be glad if it is possible to implement using only dispatch or operation queues.
I hope I've described the problem well. If not please comment bellow what is unclear, I'll explain.
Thank you so much for reading so far :) And special thanks to one who will provide an answer. And very special thanks to one, who will give me solution using dispatch or operation queues :)))
I think you need to move away from thinking about the priority at which the queues are running (which actually doesn't sound very important for the scenario you are describing) and more towards how you can use Dispatch I/O or an even simpler Dispatch source to control how the data is being read in. As you say, it takes 10 seconds the load the data and if the user suddenly changes their query immediately after asking, you need to essentially stop reading the data for the previous request and do whatever needs to be done to fulfill the most recent query. Using Dispatch I/O to chunk the data (asynchronously) and update the UI also asynchronously will allow you to change your mind mid-stream (using some sort of semaphore or cancellation flag) and either continue to trickle the data in (you don't say whether or not that data will remain useful if the user changes their mind or not), suspend the reading process, or cancel it altogether and start a new operation. Eithe way, being able to suspend/resume a source and also have it fire callbacks for reasonably small chunks of data will certainly enable you to make decisions on a much more granular chunk of time than 8 seconds!
I'm afraid the only way to do that is to cancel running operation before starting new one.
You cannot remove it from queue until it's done or canceled.
As an improvement for your problem I would suggest to load things even user doesn't need them in background - so you can load them from cache after it's there.
You can create 2 NSOperationQueue with 2 different priorities and download things in background whenever user is idle on LowPriorityQueue. For important operations you can have high priority queue - which you will cancel each time search term changes.
On top of that you just need to cache results from both of those queues.