I have developed an mobile application with J2ME(LWUIT), in that I have to update an value in my mobile RMS after receiving a response from server with a completion of updation in server side, in that case when I hit call end button- red button in my mobile after hitting server and before receiving a response the mobile application get closed and the server side value is updated but mobile RMS value is not yet updated kindly let me know is any body have a idea about this.
The red button usually kills the application instantly and doesn't really leave you a chance to fix that. You can potentially require a callback to the server to actually commit the data there.
#arun Well what you can do is.
1)Update changes at server.
2)Send the data that you wish to push to the RMS to the MIDlet along with a uniqueID. Unique id identifies every transaction uniquely.
3)At this point, the server keeps waiting for a confirmation from the MIDlet whether the MIDlet has received the data or not (lets say it waits for 20 secs)
4)Once the MIDlet receives the data, it stores it in the memory and immediately sends a confirmation to the server along with the uniqueID received (and waits for ..say.25 secs). The MIDlet also stores a count of the number of times the server has sent data with a particular unique id. So the count is initially 0 and incremented every time the server sends data with same unique id.
5)If the server receives the confirmation within 20 secs, it does nothing. After 25 secs elapse, the MIDlet will write the data to the RMS. your job is done!
5.1)If server DOES NOT receive the confirmation,it will again send the data with the same unique id (at the 21st second). The MIDlet recognizes the unique id and increments the counter which keeps track of the number of times the server has sent the same data. It again sends a confirmation and waits for 25 secs.
Now...this process can go on and on.
What you need to do is...decide when you decide to call quits on this process.
6)Ultimately,if the confirmation is not received by the server ,it rolls back the changes and sends message to the MIDlet "roll back data for unique id so and so"
7)if the midlet has not committed the data for that unique id, it ignores the messages and also the changes associated with that unique id . If already committed, it just rolls back the data for that unique id. if the request for rollback is repeated for same unique id, ignore and send a message to the server that changes have been rolled back.
8)Note: you need to send a message to the server saying that changes to RMS have been rolled back else the server will keep sending a message to rollback the changes.
Yes, this is quite complex. Check out the book. Communication Network or some thing similar by the author Behrouz Forouzan. He explains this fab.
Related
I'm using google's latest python libraries to send/receive e-mails to self (i.e., to and from fields are the same as the user account being used to send) to collect network performance metrics.
When I send a message, a 'msgId' is created which can be used to track the message that was sent. I can then subsequently delete (or trash) that 'msgId'. However, from time to time, AFTER I delete the msgId, the same message seems to "arrive" but is given a different msgId. If I wait sufficiently long enough period (10-15seconds) between sending and deleting, I only ever see the same msgId as returned by the user.message.create(), the delete is successful and only ever see the single msgId.
I believe there may be some kind of race condition whereby when sending within GMAIL (or perhaps only when sending to self), it uses the same message instance for both the sent and received message...and if the sent message is deleted before it is actually received, a new msgId is created for the received msg.
Question: Is there a way to determine whether a sent message (to self) has been received and can be deleted without risk of the message being received later and a new msgId generated?
I've tried moving the sent message to TRASH and then poll the message to receive the label for 'INBOX' without avail.
I'm writing a bot for myself, which could, on request, find torrents and download them to my home media center.
I receive an error with my webhook: request lives only ~ 5 seconds.
Parsers work 1-10 seconds + home server on hackberry is very slow.
With this, my requests die at 50%.
How can I query and receive an answer after more then 5 seconds?
An action is expected to respond within 5 seconds. This does not necessarily have to be the exact answer, but you'll need to have something to let the user know that your action is still processing.
This could be as simple as giving an intermediary state like, "Okay, I'm going to start. Do you want anything else?", or playing a short MediaResponse as "hold music". Then you can store the state in a short-term and quick to access database which is easy to poll and give as a status update when the user asks.
This can be simply done through followUpEvents. You can call any intent through web hook's followUpEvent. So, to solve your problem, you have to maintain states in your web application like "searching", "found", "downloading" and "downloaded", it's completely upto you.
Now, once an initial intent is called, you initiate the process on your server then hold for 3-3.5 seconds and send a followUpEvent to call other intent which will do nothing but wait another 3-3.5 seconds and keep polling your server each second for updated status. You can keep calling next follow up intents till you get your desired status from server.
So if your request die at 50% on a single intent then it should work fine with two follow up intents.
It´s weird and I´m not sure but sometime ago I remember I do something like this
SubscriptionClient Client = SubscriptionClient.CreateFromConnectionString(this._connectionString, topicName, subscription);
BrokeredMessage message = Cient.Receive(TimeSpan.MaxValue);
And the call that days returns in max a minute the null or a message
But the specific question is, I want to know which is the maxtime by default a server response can wait (service bus), until it returns a message even if it is null
Also I know Timespan.MaxValue is the value to wait that I´m indicating, but I really need to know if i put maxvalue (a lot of time not to wait until it finish and discover it), when does Azure will get the return of the message
From an API perspective you can pass in any TimeSpan value and it will be accepted. The reasons for it to return sooner than you have specified even when there is no message could be network glitches, service side updates etc.
The time you decide to put there should be based on how often you expect messages and also when you want control back to be able to cleanly shutdown your client process. Say you expect messages every minute then setting a timeout of 5 minutes and getting a null back could indicate that the system is not healthy. Also say you are shutting down the service, you want to not call the next receive and want all the pending ones to complete and that way you can limit the timeout to a couple minutes.
Flurry says that The rate limit for the API is 1 request per second. In other words, you may call the API once every second. I could not understand this.it means whenever the event occurs in mobile Application the request sends to server not as whole thing.Am I right? any help please?
When registering events you don't need to worry about API Limits. All events you fire are stored locally and when your session finishes the whole event package is sent to flurry server.
You could create a queue in your application with the events you want to register with the API, and continuously try to send all items in that queue, with a one second interval.
I'm building a REST web service that receives a request and must return "Ok" if the operation was done correctly. How could I deal with the possibility of the loose of the connection while returning this "Ok" message?
For example, a system like Amazon SimpleDB.
1) It receives a request.
2) Process the request (store and replicates the content).
3) Return a confirmation message.
If the connection was lost between phases 2 and 3, the client thinks the operation was not successful then submits again.
Thanks!
A system I reviewed earlier this year had a process similar to this. The solution they implemented was to have the client reply to the commit message, and clear a flag on the record at that point. There was a periodic process that checked every N minutes, and if an entry existed that was completed, but that the client hadn't acknowledged, that transaction was rolled back. This allowed a client to repost the transaction, but not have 2 'real' records committed on the server side.
In the event of the timeout scenario, you could do the following:
Send a client generated unique id with the initial request in a header.
If the client doesn't get a response, then it can resend the request with the same id.
The server can keep a list of ids successfully processed and return an OK, rather than repeating the action.
The only issue with this is that the server will need to eventually remove the client ids. So there would need to be a time window for the server to keep the ids before purging them.
Depends on the type of web service. The whole nature of HTTP and REST is that it's basically stateless.
e.g. In the SimpleDB case, if you're simply requesting a value for a given key. If in the process of returning it the client connection is dropped then the client can simply re-request the data at a later time. That data is likely to have been cached by the db engine or the operating system disk cache anyway.
If you're storing or updating a value and the data is identical then quite often the database engines know the data hasn't changed and so the update won't take very long at all.
Even complex queries can run quicker the second time on some database engines.
In short, I wouldn't worry about it unless you can prove there is a performance problem. In which case, start caching the results of some recent queries yourself. Some REST based frameworks will do this for you. I suspect you won't even find it to be an issue in practice though.