- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
This could be because Media Live is best effort delivery as per https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-service-event-list.html. In this case, you have few options :
1/ Publish events of your own in parallel to Media Live events. This way you get your own events as backup in case Media Live events do not arrive.
2/ Create a support request for MediaLive to offer better delivery attempt guarantees.
3/ Call their front-end repetitively to detect state changes :(
The second starting event could be due to the platform taking longer to actually start the instance and spin up the Channel. Since each pipeline occupies its own EC2 instance, one may finish promptly while the other waits for some pre-requisite to complete. So you may occasional duplicate starting messages.
Baldawar is correct, the best way to know the readiness of a Channel is to actually poll it. Lambda functions work well for this as most MediaLive channels start in well under 10 minutes, and Lambda functions have a fifteen minute life span. There should always be a BatchStart or similar API event from which you could trigger a monitoring Lambda. You could go further and have the Lambda start a backup channel in the event that the primary one doesn't become ready after XX minutes.
Contenuto pertinente
- AWS UFFICIALEAggiornata un anno fa
- AWS UFFICIALEAggiornata un anno fa
- AWS UFFICIALEAggiornata 9 mesi fa
- AWS UFFICIALEAggiornata 4 anni fa