Erlang SNS amazon erlcloud publish fails with timeout error - amazon-web-services
I am trying to use erlcloud to send push notification to mobile based on endpointArn which received from client. I am able to successfully push notification with Java application. But same stuff if I try with erlang, it is giving timeout error. Below are code samples.
Config = erlcloud_sns:new(<<"Access Key">>,<<"secret Key">>,<<"sns.us-west-2.amazonaws.com">>).
erlcloud_sns:publish(target,<<"arn:aws:sns:us-west-2:2315XXXXXX:endpoint/GCM/testapp/XXXXXXX-fe9a-304e-aa52-XXXXXXXX">>,<<"ok">>,undefined,[],Config).
Last statement is showing below error.
** exception error: {sns_error,{socket_error,timeout}}
in function erlcloud_sns:sns_xml_request/3 (src/erlcloud_sns.erl, line 670)
in call from erlcloud_sns:publish/6 (src/erlcloud_sns.erl, line 471)
Same value of access_key, secret_key, Host and endpointArn works from Java program.
Short answer
Change your parameters to strings and it will work. i.e:
Config = erlcloud_sns:new("Access Key","secret Key","sns.us-west-2.amazonaws.com").
erlcloud_sns:publish(target,"arn:aws:sns:us-west-2:2315XXXXXX:endpoint/GCM/testapp/XXXXXXX-fe9a-304e-aa52-XXXXXXXX","ok",undefined,[],Config).
Long answer
erlcloud expects strings for all parameters. Unfortunately, instead of validating config values before storing them, it stores whatever you provide then fails on trying to use it. In this case, it can't recognise the credentials here (because the guard function is_list returns false). In the end, it falls back to getting credentials from ECS (here), hitting a timeout there and resulting in the error you see.
Related
Kinesis put records not returned in response from get records request
I have a Scala app using the aws-java-sdk-kinesis to issue a series of putRecord requests to a local kinesis stream. The response returned after each putRecord request indicates its successfully putting the records into the stream. The scala code making the putRecordRquest: def putRecord(kinesisClient: AmazonKinesis, value: Array[Byte], streamName: String): Try[PutRecordResult] = Try { val putRecordRequest = new PutRecordRequest() putRecordRequest.setStreamName(streamName) putRecordRequest.setData(ByteBuffer.wrap(value)) putRecordRequest.setPartitionKey("integrationKey") kinesisClient.putRecord(putRecordRequest) } To confirm this I have a small python app that basically consumes from the stream (initialStreamPosition: LATEST). And prints the records it finds by iterating through the shard-iterators. But unexpectedly however it returns an empty set of records for each obtained shardIterator. Trying this using the aws cli tool, I do however get records returned for the same shardIterator. I am confused? How can that be? Running the python consumer (with LATEST), returns: Shard-iterators: ['AAAAAAAAAAH9AUYVAkOcqkYNhtibrC9l68FcAQKbWfBMyNGko1ypHvXlPEuQe97Ixb67xu4CKzTFFGoLVoo8KMy+Zpd+gpr9Mn4wS+PoX0VxTItLZXxalmEfufOqnFbz2PV5h+Wg5V41tST0c4X0LYRpoPmEnnKwwtqwnD0/VW3h0/zxs7Jq+YJmDvh7XYLf91H/FscDzFGiFk6aNAVjyp+FNB3WHY0d'] Records: [] If doing the "same" with the aws cli tool however I get: > aws kinesis get-records --shard-iterator AAAAAAAAAAH9AUYVAkOcqkYNhtibrC9l68FcAQKbWfBMyNGko1ypHvXlPEuQe97Ixb67xu4CKzTFFGoLVoo8KMy+Zpd+gpr9Mn4wS+PoX0VxTItLZXxalmEfufOqnFbz2PV5h+Wg5V41tST0c4X0LYRpoPmEnnKwwtqwnD0/VW3h0/zxs7Jq+YJmDvh7XYLf91H/FscDzFGiFk6aNAVjyp+FNB3WHY0d --endpoint-url http://localhost:4567 Returns: {"Records":[{"SequenceNumber":"49625122979782922897342908653629584879579547704307482626","ApproximateArrivalTimestamp":1640263797.328,"Data":{"type":"Buffer","data":[123,34,116,105,109,101,115,116,97,109,112,34,58,49,54,52,48,50,54,51,55,57,55,44,34,100,116,109,34,58,49,54,52,48,50,54,51,55,57,55,44,34,101,34,58,34,101,34,44,34,116,114,97,99,107,101,114,95,118,101,114,115,105,111,110,34,58,34,118,101,114,115,105,111,110,34,44,34,117,114,108,34,58,34,104,116,116,112,115,58,47,47,116,101,115,116,46,99,111,109,34,44,34,104,99,99,34,58,102,97,108,115,101,44,34,115,99,34,58,49,44,34,99,111,110,116,101,120,116,34,58,123,34,101,116,34,58,34,101,116,34,44,34,100,101,118,34,58,34,100,101,118,34,44,34,100,119,101,108,108,34,58,49,44,34,111,105,100,34,58,49,44,34,119,105,100,34,58,49,44,34,115,116,97,116,101,34,58,123,34,108,99,34,58,123,34,99,111,100,101,34,58,34,115,111,109,101,45,99,111,100,101,34,44,34,105,100,34,58,34,115,111,109,101,45,105,100,34,125,125,125,44,34,121,117,105,100,34,58,34,102,53,101,52,57,53,98,102,45,100,98,102,100,45,52,102,53,102,45,56,99,56,98,45,53,97,56,98,50,56,57,98,52,48,49,97,34,125]},"PartitionKey":"integrationKey"},{"SequenceNumber":"49625122979782922897342908653630793805399163707871723522","ApproximateArrivalTimestamp":1640263817.338,"Data":{"type":"Buffer","data":[123,34,116,105,109,101,115,116,97,109,112,34,58,49,54,52,48,50,54,51,56,49,55,44,34,100,116,109,34,58,49,54,52,48,50,54,51,56,49,55,44,34,101,34,58,34,101,34,44,34,116,114,97,99,107,101,114,95,118,101,114,115,105,111,110,34,58,34,118,101,114,115,105,111,110,34,44,34,117,114,108,34,58,34,104,116,116,112,115,58,47,47,116,101,115,116,46,99,111,109,34,44,34,104,99,99,34,58,102,97,108,115,101,44,34,115,99,34,58,49,44,34,99,111,110,116,101,120,116,34,58,123,34,101,116,34,58,34,101,116,34,44,34,100,101,118,34,58,34,100,101,118,34,44,34,100,119,101,108,108,34,58,49,44,34,111,105,100,34,58,49,44,34,119,105,100,34,58,49,44,34,115,116,97,116,101,34,58,123,34,108,99,34,58,123,34,99,111,100,101,34,58,34,115,111,109,101,45,99,111,100,101,34,44,34,105,100,34,58,34,115,111,109,101,45,105,100,34,125,125,125,44,34,121,117,105,100,34,58,34,102,53,101,52,57,53,98,102,45,100,98,102,100,45,52,102,53,102,45,56,99,56,98,45,53,97,56,98,50,56,57,98,52,48,49,97,34,125]},"PartitionKey":"integrationKey"},{"SequenceNumber":"49625122979782922897342908653632002731218779711435964418","ApproximateArrivalTimestamp":1640263837.347,"Data":{"type":"Buffer","data":[123,34,116,105,109,101,115,116,97,109,112,34,58,49,54,52,48,50,54,51,56,51,55,44,34,100,116,109,34,58,49,54,52,48,50,54,51,56,51,55,44,34,101,34,58,34,101,34,44,34,116,114,97,99,107,101,114,95,118,101,114,115,105,111,110,34,58,34,118,101,114,115,105,111,110,34,44,34,117,114,108,34,58,34,104,116,116,112,115,58,47,47,116,101,115,116,46,99,111,109,34,44,34,104,99,99,34,58,102,97,108,115,101,44,34,115,99,34,58,49,44,34,99,111,110,116,101,120,116,34,58,123,34,101,116,34,58,34,101,116,34,44,34,100,101,118,34,58,34,100,101,118,34,44,34,100,119,101,108,108,34,58,49,44,34,111,105,100,34,58,49,44,34,119,105,100,34,58,49,44,34,115,116,97,116,101,34,58,123,34,108,99,34,58,123,34,99,111,100,101,34,58,34,115,111,109,101,45,99,111,100,101,34,44,34,105,100,34,58,34,115,111,109,101,45,1pre05,100,34,125,125,125,44,34,121,117,105,100,34,58,34,102,53,101,52,57,53,98,102,45,100,98,102,100,45,52,102,53,102,45,56,99,56,98,45,53,97,56,98,50,56,57,98,52,48,49,97,34,125]},"PartitionKey":"integrationKey"}],"NextShardIterator":"AAAAAAAAAAE+9W/bI4CsDfzvJGN3elplafFFBw81/cVB0RjojS39hpSglW0ptfsxrO6dCWKEJWu1f9BxY7OZJS9uUYyLn+dvozRNzKGofpHxmGD+/1WT0MVYMv8tkp8sdLdDNuVaq9iF6aBKma+e+iD079WfXzW92j9OF4DqIOCWFIBWG2sl8wn98figG4x74p4JuZ6Q5AgkE41GT2Ii2J6SkqBI1wzM","MillisBehindLatest":0} The actual python consumer I have used in many other settings to introspec other kinesis streams we have and its working as expected. But for some reason here its not working. Does anyone have a clue what might be going on here?
So I was finally able to identify the issue, and perhaps it will be useful for someone else with similar problem. In my setup, I am using a local kinesis stream (kinesalite) which doesn't support CBOR. You have to disable this explicitly otherwise I was seeing the following error when trying to deserialize the received record. Unable to unmarshall response (We expected a VALUE token but got: START_OBJECT). Response Code: 200, Response Text: OK In my case, setting the environment variable: AWS_CBOR_DISABLE=1 did the trick
How to change failure message for Alexa?
I want to change the default failure message in Alexa, Sorry, I'm having trouble accessing your {} skill right now.
You cannot change that prompt but you can code to avoid that as much as possible. The error happens when Alexa is not able to get a valid response from your skill endpoint. There can be multiple reasons to that as mentioned here 1. Your endpoint is giving an invalid response This can be due to the errors/exceptions happening in your endpoint code. You can make sure that error/exceptions don't occur and if they occur, thre is code to catch them and provide a valid response back to Alexa, with an error message of your choice. 2. Your endpoint availability Make sure that your endpoints are available all the time if you have configured them as an endpoint. This is pretty much guaranteed if you are using Lambda endpoints. But if you are your own hosted web service endpoint, then you must put in all the measures to keep it available for Alexa to communicate with it. 3. Your endpoint response time Make sure that your endpoint gives back the response within the time period that Alexa expects it to get(guess its 10 seconds). Also make sure if you are using Lambda functions, you have configured them with reasonable execution time to avoid timeout errors. If you cover the exception/error/availability scenarios well then you can avoid the default error message as much as possible.
System.ServiceModel.FaultException: Server was unable to process request. ---> ... with key 0 was not found
I have a simple service (C# web service) that accepts an integer and returns an integer, i have tested it using Storm it is working properly. Now i am calling this service in a for loop in a file with around 2000 records approx, this service is failing giving the above error with some records. If i run the error file it goes through as if nothing was wrong, what might be the problem please help.
The error doesn't seem related to it being a web service call: it seems to indicate you either tried to GetEntity and passed in a zero/NullIdentifier() (not a valid Id), or maybe you tried an CreateEntity and that entity has a foreign key that is not filled in (i.e. zero/NullIdentifier() again). I would start by checking the logic inside the WS method for those action calls and the inputs you are using there.
Enterprise service object from WSDL returns null
I created a service consumer through the wizard, based on a WSDL. Proxy object is generated, all structures and methods are found. Then, I add a logical port through SOAMANAGER - all fine, it pings and the connection works. I populate the input structure, call my method and get an error: Error during proxy processing (PART UNKNOWN (NULL)). This is a very useless error message to me. So, I activate all manners of tracing, so I can see what's going on calling and retrieving data. I can see that My proxy is called correctly The payload sent TO the service looks correct The payload received FROM the service is correct. I know this because it's identical to the XML I get back calling the service through other means. The transformation is empty Here a screen of (the start of) the returned XML. getRecordsResult set is what I need: This is the second response, after "conversion": Nothing about this service has been customized: it's generated straight up through the wizard. I have already deleted and recreated it but no results. Anyone got any advice on what to do next?
Amazon SNS CreatePlatformApplication returns error when reusing platform applications
I had code that was working that would create a new platform application for every message that went out. I thought that was wasteful so I tried to change the code to use list_platform_applications to get available applications and reuse the one that has the proper name (part of the PlatformApplicationArn). This will work for several messages in a row when suddenly I'll get this error from CreatePlatformApplication: {"Error":{"Code":"InvalidParameter","Message":"Invalid parameter: This endpoint is already registered with a different token.","Type":"Sender"},"RequestId":"06bd3443-598e-5c06-9f5c-7f84349ea067"} That doesn't even make sense. I'm creating an endpoint. I didn't pass one in. Is it really complaining about the endpoint it's returning. According to the Amazon documentation: "The CreatePlatformEndpoint action is idempotent, so if the requester already owns an endpoint with the same device token and attributes, that endpoint's ARN is returned without creating a new endpoint." So it seems to me, if there's an appropriate one it will be returned. Otherwise, create a brand new fresh one. Am I missing something?
Oh darn. I think I found the reason for this behavior. After facing this issue, I made sure that each token was only uploaded once to AWS SNS. When testing this, I realized that nevertheless I ended up with multiple endpoints with the same token - huh??? It turned out that these duplicated tokens resulted from outdated tokens being uploaded to AWS SNS. After creating an endpoint using an outdated token, SNS would automagically revive the endpoint by updating it with the current device token (which afaik is delivered back from GCM as a canonical ID once you try to send push messages to outdated tokens). So e.g. uploading these (made-up) tokens and custom data APA9...YFDw, {original_token: APA9...YFDw} APA9...XaSd, {original_token: APA9...XaSd} <-- Assume this token is outdated APA9...sVQa, {original_token: APA9...sVQa} might result in something like this - i.e. different endpoints with identical tokens: APA9...YFDw, {original_token: APA9...YFDw}, arn:aws:sns:eu-west-1:4711:endpoint/GCM/myapp/daf64...5c204 APA9...YFDw, {original_token: APA9...XaSd}, arn:aws:sns:eu-west-1:4711:endpoint/GCM/myapp/a980f...e3c82 <-- Duplicate token! APA9...sVQa, {original_token: APA9...sVQa}, arn:aws:sns:eu-west-1:4711:endpoint/GCM/myapp/14777...7d9ff This scenario in turn seems to lead to above error on subsequent attempts to create endpoints using outdated tokens. On the hand, it seems correct that subsequent requests fail. On the other hand, intuitively I have the gut-feeling that the duplication of tokens that is taking place seems wrong, or at least difficult to handle. Maybe once SNS discovers that a token is outdated and needs to be changed, it could first check if there is already another endpoint existent with the same token... I will research on this a bit more and see if I can find a way to handle this properly. Cheers
Had the same issue, with the device reporting one token (outdated according to GCM) and the SNS retrieving/storing another. We solved it by clearing the app cache on the device and reopening the app (which in our case, re-registered the device on the gcm service), generating the same token (not outdated) that SNS was attempting to push to.