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
Related
Stripe documentation points out that:
Because properly acknowledging receipt of the webhook
notification is so important, your endpoint should return
a 2xx HTTP status code prior to any complex logic could
cause a timeout.
In the web hook I'm developing with PHP this is exactly the
case — there is some complex logic involved after the event
is received.
Currently I'm returning the response code with a simple call
to http_response_code(). But how can I send the response
headers (with the code) before proceeding? Would a flush()
call force the headers to be sent?
i have a backend system using PHP to handle transaction.
in this case, there is three environment involved.
A = client, B = my system, C = payment gateway
the scenario is :
client (A) send request over HTTP post request,then
my system (B) receive that request and then
send request to payment gateway (C) using cUrl.
what happen now is :
every request from client proceed by my system partially, which mean next process will be process when previous request to C has response.
what i want is :
even the prevoius request not yet responded by C, my system can receive next request from A and send another request to C.
I was wondering if someone could help me figure out where this could be coming from.
Here is a successfull transaction:
Response received: HttpResponse{body='Status=OK
RedirectURL=https://www.furnitureclinic.co.uk/orderSuccessful?VendorTxCode=fclinic-170720105629-212955392
', statusCode=200, statusMessage='OK'}
And here a failed transaction:
Response received: HttpResponse{body='email sentStatus=OK
RedirectURL=https://www.handbagclinic.co.uk/Checkout?VendorTxCode=fclinic-170720105715-107422623
', statusCode=200, statusMessage='OK'}
As you can see in the failed transaction, after body=, it says email sentStatus=OK rather than just Status=OK.
This causing payments to Sage to fail.
I would just like to know, at which point in the payment process does this response get sent, and what could possibly be causing this to happen.
I have looked through the entire Notification URL file and no mention of "email sent" ever shows up.
This is the last step of a Server transaction - Sage Pay will call back to you with the Notification post, which it looks like you are getting, and you respond with the 'OK' message and a redirect URL (to send the consumer's browser off to wherever).
However, if you are sending all that through, it's as if you are telling Sage Pay to reject the transaction.
I recommend setting up a simple script on your NotificationURL, which just replies (to the notification POST) with:
Status=OK
statusMessage=Fine
RedirectURL=<wherever>
And then re-introduce the complexity of signature checking etc. afterwards...
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
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.