I searched a lot but couldn't found any description on properties of responses that are being sent by REST API (http://dev.iron.io/mq/reference/api/#responses) Almost all properties of responses are self explanatory but some properties needs to be described. Let me mention some of them;
In response of GET /projects/{Project ID}/queues/{Queue
Name}/messages/{Message ID}/subscribers request, what is property
ID? (this is not message ID as I have checked it. In case of uni-cast
push queue it is the same number as message_id+1)
In response of GET /projects/{Project ID}/queues/{Queue
Name}/messages/{Message ID} request, what is property
reserved_count?
In response of GET /projects/{Project ID}/queues/{Queue Name}
request, what is property size? (It looks to be queue size from its
value but again what is queue size? Queue Size on my Dashboard always
displays zero)
As per my understanding if a message is retrying 2nd or 3rd time its
retries_remaining should be equal to retries_total - number of
retries attempts. But this is not case. Every time I have seen that
retries_remaining is not changing. What are the cases in which
retries_remaining will change?
After the message is tried retries_total number of times, message
status should be changed to error but it remains retrying. why?
Is there any log of message routing? means, if a message is first
send to subscriber 1 but not received 200 in response. The same
message will be then send to other subscriber say subscriber 2.
In response of GET /projects/{Project ID}/queues/{Queue
Name}/messages/{Message ID}/subscribers request, the property ID is the subscriber ID
In response of GET /projects/{Project ID}/queues/{Queue
Name}/messages/{Message ID} request, the property reserved_count shows how many times the message have been reserved. After reservation if the timeout had been expired, the message would be placed back onto queue and the reserved_count would be increased.
In push queues (in contrast to pull queues) the messages are not stored in the queue. That's why the size of any push queue is always zero.
After the message is tried retries_total number of times the message status always changes to error. I think you had checked the status before the message was tried retries_total number of times. There is also the retries_delay between retries, default value is 60 seconds.
Unfortunately now the routing log is not available, maybe in future will. You can use an errorqueue. It is the name of another queue where information about messages that can't be delivered after retrying retries number of times will be placed. For detailed information navigate to
http://dev.iron.io/mq/reference/push_queues/#error_queues
Related
I am having trouble retrieving all messages through the Gmail API PHP Library. I use listUsersThreads to retrieve all threads to do either a full or partial mailbox sync on a user's account. The initial full sync processes and returns the message ids I need, which I then use to store mail meta headers (from, to, date, subject). A subsequent call using listUserHistory from the last history id, allows me to do a partial sync to only retrieve the latest messages. From the data I have stored, I then display a full message conversation log between two parties, ordered by date to show the conversation. Clicking the message will then query the API to retrieve email body, which I then display.
The issue is that based on the messages I have saved, looking at the MIME content, there are messages in the MIME body, that I do not have on my database. I then also tried to query the API using a search query, and still there are missing messages, not returned by the API.
A previous developer used mimecast to get the messages, and querying that database does in fact return the messages that I'm missing.
How is the Google Gmail API not giving me all messages between sender and receiver? The MIME body clearly shows messages that are not available when querying the API, and I don't understand why, or how to find the missing messages.
Any assistance would be appreciated.
So, for in case this issue comes up for anyone else, I believe that it has something to do with expired history items. I stand to be corrected, as this can only be proved after I've had my implementation running for more than two weeks.
If you're considering running a mailbox sync, there's a good chance that you'll be missing messages, especially if those messages were sent from a client other than Inbox or Gmail. History items are kept for two weeks on average, so by syncing a mailbox, you'll be syncing everything from when the account was activated, but expired history items will not be available.
In theory, this means that you should have the full email conversation while a partial sync is executed. You should have all the MIME headers that you need as and when the communication takes place, provided that, like me, you have push notifications enabled through the Google Cloud Services console to alert your systems to run a partial sync process on any given account.
If your partial sync is executed manually, or possibly through CRON on an interval, rather than through push notifications, you'll need to make sure that the interval is configured to sync while all history items are still available and accessible.
The downside of this, though, is that even if you do have trace of all communication with their message IDs, a lookup on an expired message to retrieve email body will fail with a 404 status code, and you will not be able to retrieve email body contents for some messages.
Thus, if your processes relies heavily on what's in the body of the email, you should also store body content locally during a partial sync I really only need the MIME headers, although I do lookup message contents when needed, but it won't cause major problems for me if I was unable to retrieve the body of any given message.
I should be able to confirm this theory within a month from now, so if you think my theory is incorrect, please feel free to make me the wiser. :)
Does anyone have any documentation on this "TooManyMessages" error.
After I call the GoogleCloudMessaging send method I am getting an intent from com.google.android.c2dm.intent.RECEIVE with the following key/value pairs in the extras bundle.
Send error:
Bundle[{error=TooManyMessages,
message_type=send_error,
google.message_id=1,
android.support.content.wakelockid=1}
This means that too many messages were stored in the GCM server for a single device without being delivered (which might happen if your device was offline while many messages were sent by your server).
Once the number of such messages reaches the limit, which is 100 if you don't use a collapse key, they are deleted from the GCM server, and you get that error message, which informes you your device should sync with your server in order to get the lost messages.
I'm attempting to use the iron.mq push queue, but am having difficulty figuring out how to properly respond to the queue after receiving a message. I realize that I might also not fully understand how the queue system behaves, but my understanding is that it is something like this:
Message sent to queue
Message pushed from queue to my endpoint
Message is 'reserved' until my endpoint responds or times out
Endpoint responds with either a 2xx (success) and it is deleted or 4xx/5xx failure, in which case the queue will attempt to resend the message to the endpoint.
For example, my script (using FuelPHP) has something like this:
$headers = Input::headers(); //gets array of headers sent from ironmq
$data = #file_get_contents('php://input'); //get the body
Now that I have received the message, I want to do one of two things:
Process message and return response to ironmq servers that it was successful
Delay the process (by sending a 4xx/5xx?) and have it be resent after a defined period of time.
But... how do you respond to a push message? Using the PHP SDK's deleteMessage method causes an exception as the message appears to no longer exist.
Version 1. Endpoint responded with status 202. http://dev.iron.io/mq/reference/push_queues/#how_the_endpoint_should_handle_push_messages
You should explicitly delete a message after processing via deleteMessagePushStatus()
Version 2. Endpoint responded with status 200. Message will be deleted automatically, no actions required
so - two ways:
202 -> do long work -> deleteMessagePushStatus()
4xx or 5xx -> 4xx or 5xx (many times) -> 200
I don't really know how to ask these but hopefully I can make myself clear enough for you to understand my questions
The message limit is 256. But which is the message I need to impose this limit on?
At first I thought it was referring to json size. But after looking through the code zend use, and others who use push notification, additional information is sent through payload (the json is 256 but the payload sent is 270). Should I limit the json to 240 or less?
What happens if more than one message has the same Id (I'm not talking about device id)
How fast can I send a second message to the same device? I have some problems that only one message arrives.
I use timestamp for Id, so I was wondering if this is the cause of my problem or maybe I can't send 5 messages in the same seccond to a single device.
From Apple Developer site:
The Notification Payload
Each push notification includes a payload. The payload contains
information about how the system should alert the user as well as any
custom data you provide. The maximum size allowed for a notification
payload is 256 bytes; Apple Push Notification Service refuses any
notification that exceeds this limit.
The limit is on complete payload which mean JSON + Your Message. So your message should be limited to 236 characters and then add the character count of following JSON: {"aps":{"alert":""}}.
how fast can i send a second message to the same device? I have some problems that only 1 message arrives.
There is no restriction on sending messages to one device. However, Apple does not guarantee delivery of all of your messages and APNS may deliver only the latest push notification message of the device in case multiple messages have been received from one app which are destined on the same device.
From iOS Developer Library:
Some Notifications Received, but Not All
If you are sending multiple notifications to the same device or computer within a short
period of time, the push service will send only the last one.
Here's why. The device or computer acknowledges receipt of each
notification. Until the push service receives that acknowledgment, it
can only assume that the device or computer has gone off-line for some
reason and stores the notification in the quality of service (QoS)
queue for future redelivery. The round-trip network latency here is of
course a major factor.
As described in the Local and Push Notification Programming Guide, the
QoS queue holds a single notification per app per device or computer.
If the service receives another notification before the one in the
queue is sent, the new notification overwrites the previous one.
Thanks to Joachim Isaksson for providing the above link.
Well, the 256 bytes limit is on the binary representation of the JSON payload (the device token as well as the other headers are not included in this count). That means you can send a 256 character JSON string if you only use characters which require a single byte in UTF-8 encoding. If you send text in languages whose characters require more than one byte, you will have room for less characters in your payload. I tested it, and that's how it behaves.
As for sending more than one message with the same id, that would defeat the purpose of the message id. When Apple encounter some error in your message (such as invalid device token), it sends back an error response containing the message id you supplied. If you send multiple messages with the same id, you won't be able to know which message causes the error response.
I just moved my server to a new host, and obviously changed the DNS for my paypal ipn page.
For some reason paypal keeps hitting my page about every 30 seconds with the same transactions over and over again.
So of course its verified then stored in the database as duplicate records.
Has anyone had this problem? Or know how to fix?
Make sure that your browser is returning 200 OK status to paypal.
Either way, you should store IPN tracking IDs (ipn_track_id) in your database and check for duplicates. This is the only guaranteed way to solve your problem.
According to PayPal's IPN documntation:
Your listener must respond to each message, whether or not you intend
to do anything with it. If you do not respond, PayPal assumes that the
message was not received and resends the message. PayPal continues to
resend the message periodically until your listener sends the
correct message back, although the interval between resent
messages increases each time. The message can be resent for up to four
days.
This resend algorithm can lead to situations in which PayPal
resends the IPN message while you are sending back the original
message. In this case, you should send your response again, to cover
the possibility that PayPal did not actually receive your response the
first time. You should also ensure that you do not process the
transaction associated with the message twice.
IMPORTANT: PayPal
expects to receive a response to an IPN message within 30 seconds.
Your listener should not perform time-consuming operations, such as
creating a process, before responding to the IPN message.
So a) is your script properly responding and b) is the notify_url parameter from your transaction different with your DNS change?