I'm implementing a download manager in cocoa. The user can add several download requests, and the request manager will show the progress of the requests in a panel. I came into problem about the pause/resume of the request in the queue.
For simplicity, supposing the max concurrent operation count is 1, I add several requests with order:1, 2, 3,4,5. If it is not interrupted, the request is downloaded from 1 to 5 in sequence. Supposing I pause the request 1, the request 2 should continue to download. During that time, I resume the request 1. Hence, after the request 2 is finished, I hope the request 1 can be continued before request 3.
The problem here is that: For the single request when I paused it, the request in fact was cancelled. when I resumed the request, a new request was initialed and then started. In an operation queue, now I sent [self cancel] if the request was paused so that the next request could be started. However, I don't know how to do if it is resumed. The canceled request cannot be added to the queue again. If I created a new one and add it to the queue, how can I promise the priority like the before?
Please give tips on how to do it.
thanks
Currently I make a solution myself using:
make a custom request inherited from ASIHttpRequest;
make a NAMutableArray to contain all the requests;
If one request is added, enumerating the array to see if the maximum requests are executing.
If not, start the request in its own queue. If exceeding the maximum, just add the request to the array, and set its status to waiting;
If one request is finishing or failing, enumerating the array to see the request which is in the first position by adding time with a status waiting;
Related
I try to use cache mediator. But when cache dont contain response and I make two same requests, they both throw. But I want the second request wait until first will be cached. How it csn be done in WSO2 ?
There are several ways to implements this. First use queue, second use property to mark that request is going on right now.
Second solution is kind of tricky if request will fail, then faulty sequence will start, and need to reset property in that sequence.
Second what does it mean wait for first request? Hold connection and do not respond while first request will not populate cache or just respond quickly "server is too busy" (also legal).
I've got an odd problem here with Prototype 1.7.0 and an AJAX form submission using form.request().
The response status is either 202 or 200 depending on whether the server expects to be polled again with the same form submission after a timeout. 200 indicates that the response contents are done and are to be displayed to the user (backend uses WebWork's execAndWait-interceptor to execute a long-running job).
The problem is that most of the time, everything works just fine. However, occasionally, the response comes back as status code 0 and XMLHTTPRequest readyState 1. Firebug indicates correct response codes are coming from the backend, and that the actual response contents are fine, it's just that Prototype's on200 and on202 handlers do not fire (on0 does).
It appears there are similar issues reported over the Internet, but there is no conclusive solution. Is this some well known problem?
A response code 0 from prototype means that it can't communicate with the server. You can remedy this by adding an "on0: function() {}" event handler in your request.
How you handle it is up to you...either alert the user that something went wrong, and redisplay their form, or silently try and re-submit your request to the backend in a loop. If you choose the second option, set a wait timeout and each time you can't talk to the server multiply it by some factor so you don't infinite loop their browser.
You might also want to look into queuing these requests on the client-side so you're only firing one at a time, in order.
Hope that helps.
What is the best way deal with out-of-sequence Ajax requests (preferably using a jQuery)?
For example, an Ajax request is sent from the user's browser anytime a field changes. A user may change dog_name to "Fluffy", but a moment later, she changes it to "Spot". The first request is delayed for whatever reason, so it arrives at the server after the second, and her dog ends up being called "Fluffy" instead of "Spot".
I could pass along a client-side timestamp along with each request, and have the server track it as part of each Dog record and disregard earlier requests to change the same field (but only if there is a difference of less than 5 minutes, in case the user changes the time on her machine).
Is this approach sufficiently robust, or is there a better, more standardized approach?
EDIT:
Matt made a great point in his comment. It's much better to serialize requests to change the same field, so is there a standard way of implementing Ajax request queues?
EDIT #2
In response to #cherouvim's comment, I don't think I'd have to lock the form. The field changes to reflect the user's change, a change request is placed into the queue. If a request to change the same field is waiting in the queue, delete that old request. 2 things I still would have to address:
Placing a request into the queue is an asynchronous task. I could have the callback handler from the previous Ajax request send the next request in the queue. Javascript code isn't multi-threaded (or... is it?)
If a request fails, I would need the user interface to reflect the state of the last successful request. So, if the user changes the dog's name to "Spot" and the Ajax request fails, the field would have to be set back to "Fluffy" (the last value successfully committed).
What issues am I missing?
First of all you need to serialize server side processing for each client. If you are programming in Java then synchronizing execution on the http session object is sufficient. Serializing will help in case the second update comes while the first is being processed.
A second enhancement you can implement in your entity updating is http://en.wikipedia.org/wiki/Optimistic_concurrency_control. You add a version property (and column) for your entity. Each time an update happens this is incremented once. In fact the update statement looks like:
update ... set version=6 ... where id=? and version=5;
If affected rows from above pseudoquery query are 0 then someone else has managed to update the entity first. What you do then is up to you. Note that you need to be rendering the version on the html update form of the entity as a hidden parameter and sending it back to the server each time you update. On return you have to write back the updated version.
Generally the first enhancement would be enough. The second one will improve the system in case many people are editing the same entities at the same time. It solves the "lost update" problem.
I would implement a queue on the client side with chaining of successful requests or rollbacks on unsuccessful requests.
You need to define "unsuccessful", be it a timeout or a returned value.
I am using a standard LRU queue as defined by the ZeroMQ guide figure 41, and I am wondering how to add in protection so that I don't send messages to end points that have disappeared (server crash, OOM killer, anything along those lines).
From the documentation I read that XREP will just drop the message if it is going to a non-existant end-point, and there is no way I get notified about that. Is there a way to get such a notification? Should I just send out a "ping" first and if I don't get a response then that "worker" is dead meat to me? How will I know that it is the same client that I just sent the ping to that I am getting the message back from?
Or is my use case not a good one for ZeroMQ? I just want to make sure that a message has been received, I don't want it being dropped on the floor without my knowledge...
Pinging a worker to know if it is alive will cause a race condition: the worker might well answer the ping just before it dies.
However, if you assume that a worker will not die during a request processing (you can do little in this case), you can reverse the flow of communication between the workers and the central queue. Let the worker fetch a request from the queue (using a REQ/REP connection) and have it send the answer along with the original envelope when the processing is done (using the same socket as above, or even better through a separate PUSH/PULL connection).
With this scenario, you know that a dead worker will not be sent requests, as it will be unable to fetch them (being dead…). Moreover, your central queue can even ensure that it receives an answer to every request in a given time. If it does not, it can put the request back in the queue so that a new worker will fetch it shortly after. This way, even if a worker dies while processing a request, the request will eventually be served.
(as a side note: be careful if the worker crashes because of a particular request - you do not want to kill your workers one by one, and might want to put a maximum number of tries for a request)
Edit: I wrote some code implementing the other direction to explain what I mean.
I am writing a Message Handler for an ebXML message passing application. The message follow the Request-Response Pattern. The process is straightforward: The Sender sends a message, the Receiver receives the message and sends back a response. So far so good.
On receipt of a message, the Receiver has a set Time To Respond (TTR) to the message. This could be anywhere from seconds to hours/days.
My question is this: How should the Sender deal with the TTR? I need this to be an async process, as the TTR could be quite long (several days). How can I somehow count down the timer, but not tie up system resources for large periods of time. There could be large volumes of messages.
My initial idea is to have a "Waiting" Collection, to which the message Id is added, along with its TTR expiry time. I would then poll the collection on a regular basis. When the timer expires, the message Id would be moved to an "Expired" Collection and the message transaction would be terminated.
When the Sender receives a response, it can check the "Waiting" collection for its matching sent message, and confirm the response was received in time. The message would then be removed from the collection for the next stage of processing.
Does this sound like a robust solution. I am sure this is a solved problem, but there is precious little information about this type of algorithm. I plan to implement it in C#, but the implementation language is kind of irrelevant at this stage I think.
Thanks for your input
Depending on number of clients you can use persistent JMS queues. One queue per client ID. The message will stay in the queue until a client connects to it to retrieve it.
I'm not understanding the purpose of the TTR. Is it more of a client side measure to mean that if the response cannot be returned within certain time then just don't bother sending it? Or is it to be used on the server to schedule the work and do what's required now and push the requests with later response time to be done later?
It's a broad question...