I have a client app which listens for added and removed messages from some mailboxes and folders.
There is the possibility to delete a message, I mean marking it as DELETED and expunging it.
Sometimes a user may enter in its web mail client and delete a message (I mean moving it in trash, I'm not talking about GMail which behaves differently)
When such an event happens, the first expunge called by code, returns an array of expunged messages, which contains those messages deleted from web client too, why?
If it is correct, the expected result shouldn't be that expunged messages were permanently removed from trash too? After the expunge messages removed by user via web client, exist yet in trash.
Is it normal? I am a bit confused about expunction...
Thanks
Related
I have a Cloud Pub/Sub Push subscription that pushes multiple instances of the same messages to a processing end-point i GAE. I can track the message ID and it’s the same message that gets PUSH multiple times.
I have set the ack-timeout to 600 seconds but still it pushes multiple instances of some of the messages. Outside of the message doesn’t get “acked”, what can trigger this behavior? Anyone had the same problem?
The issue seems to be bigger the more instances I run, but even when using basic_scaling and with max_instances: 1 problem still remains.
I can see a bunch of 503 errors in GAE but if I understand it correct, that is not an issue since these messages automatically gets "re-tried" but Pub/Sub.
As it turns out this is a well known issue with Pub/Sub. Pub/Sub is "At least Once Delivery", and duplicates are to be expected. To resolve this, read here for some inspiration, https://cloud.google.com/blog/products/serverless/cloud-functions-pro-tips-building-idempotent-functions
I am posting this as an answer, because i dont have enough reputation to put as comment. :)
As you have already figured out, once Pub/Sub sends a message to a subscriber, the subscriber should acknowledge the message. Any message that has not been acknowledged, Cloud Pub/Sub will repeatedly attempt to deliver (Check here). This means that occasional duplicates are to be expected. However, a high rate of duplicates may indicate that the client is not acknowledging messages within the configured ack_deadline_seconds, and Cloud Pub/Sub is retrying the message delivery.
You could use Stackdriver, to monitor if the Pub/Sub System is successful and your messages are being acknowledged (Check here & here), or if there are too many duplicates (Check here & here).
It was working fine till last day and suddenly stopped pushing to endpoint. Checked all settings including endpoint URL and found everything remains unchanged. Can you guys suggest possible causes.
Not receiving a message on a push endpoint could happen for many reasons. The first thing to do would be to go to Stackdriver and create a graph for the subscription/push_request_count metric. You can break this down by response_code to see how many requests Cloud Pub/Sub is sending to your push endpoint and what response codes it is returning. If there are requests being delivered that are returning errors, this graph will show that.
It might also be worth checking the publish side to ensure messages are still being published as expected. You can look at the topic/send_message_operation_count metric, which can also be broken down by response_code, to make sure the publish requests are all returning success.
You should also check to ensure the subscription still exists using the Pub/Sub Subscriptions page in the Cloud console. After 30 days of inactivity (including inability to successfully deliver a message to a push endpoint), subscriptions are potentially deleted.
If the issue still unsolved after those steps, it is best to contact Google Cloud support with your project ID and subscription name so that things can be investigated for your specific case.
Steps to reproduce:
Send a message from Inbox
Create a 2nd message in that same thread using Gmail API's "insert" method
Delete the first message either from the API or from Gmail (but really delete it, not just put it into trash)
Result: the 2nd message seems to get somehow disconnected from the thread and Inbox acts weirdly on it (see video if curious -- the weird behaviour itself starts at 2:10).
Bug or feature?
How to avoid it?
I created a web service and a mobile application that communicate between each other. When everything is working, it works great. When the server doesn't respond, it starts to break down.
The mobile device sends a message to the server with a bunch of records. Getting the records on the server never seems to be a problem. It gets the records and then sends a response back to the mobile device that the update was received. The PROBLEM is that the mobile device doesn't always get the response, so it doesn't know it shouldn't send those records again for updating.
Next time it sends the records again and now I have duplicate records. How can I solve this?
Idea 1) Create a transaction number unique on the mobile device that I can compare against the server to see if the record was already uploaded. Then just don't write that record and attempt to send back the response that it was written.
Idea 2) Send the records to the server, but before writing them respond to the mobile device that they were received. This way the mobile device can tag them and then send another response to the server telling it to write them. At the point the mobile device almost doesn't care if it gets a response. Only thing, you don't know if the server ever got the message.
Looking for ideas on how to handle this that either confirm one of these ideas or has a completely different one.
I ended up creating logs that the device attempts to resolve when it gets back successful responses from the server.
I tag items as a batch of lines and send them up to the server. Once they are up there, I create a log about the success or failure of each line item in a batch of items and then save the log to the file system.
When the mobile device is unsuccessful in hearing back a response from the server, in rare cases, it asks the server about a batch number. If the server doesn't respond with a status of that batch, it assumes the server never received it and remarks those items for another upload attempt. If it hears back, it processes the success and failure line by line and then marks the items on the mobile device accordingly. If the mobile device doesn't ask about the log in the next upload, the server assumes the batch's lifecycle is complete and it no longer needs to maintain that log. It is then deleted.
The server doesn't delete a log until it has a successful request from the specific device no longer asking to hear about the log. So if I have log 1 on the server and the device doesn't ask in the next upload to hear back about that log, the server then removes that log assuming the device got the response it wanted or doesn't care about it anymore.
Ever since the latest release a few days ago, our users are constantly being disconnected due to channel tokens going stale with minutes of being created. Our tokens are set to last for 5 hours, but we're lucky if they last for 5-10 minutes and we cannot even reconnect with a new channel token when the channel closes until the user refreshes.
A Javascript error triggers the beginning of it. It looks like this:
NetworkError: 400 Unknown SID - http://89.talkgadget.google.com/talkgadget/dch/bind?VER=8&clid=C9C2EFC06C7C5163&gsessionid&prop=data&token=AHRlWrrWl611ZMMDw8Apgi5vdYuS9UslofxEiJI47-2n4rkPgmuu1z0AN-UNQcyNEvhck-AYAMSLPru8Aumooz62hYNNbLTbi1a3lTSAzGEyj6TsXZirJYE&RID=rpc&SID=BEBDEFDA92C6A9F7&CI=0&AID=54&TYPE=xmlhttp&zx=gsjg8mb1i987&t=1
Then, in Firefox Firebug, the console gets spammed infinitely with
channel name mismatch; message ignored
Until a refresh occurs.
Our site is a real-time interactive site with chat. Our users are sending us emails upset that they keep getting disconnected. They're leaving the site. This is costing us not only goodwill with our user base, but also money and we are powerless to do anything because the bug is with Google App Engine.
Please fix this or rollback to the previous build immediately until you figure this out. The latest build is broken.
I haven't been able to reproduce this but I'm still looking at it. In the meantime: if you explicitly call socket.close() after receiving the error, can you then create a new Channel object and reconnect? If that doesn't work, you could even try manually removing the element with id "wcs-iframe" itself from the DOM. You should be able to use the original token when doing this instead of fetching a new token.