Rozwiązywanie typowych problemów
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Jeśli napotkasz problemy, zapoznaj się z sekcjami poniżej.
Stan utraconego urządzenia w Fleet Engine
Podczas pracy z Fleet Engine zaprojektuj wdrożenie tak, aby przewidywać awarie. Jeśli na przykład wyślesz do Fleet Engine żądanie aktualizacji pojazdu, może ona odpowiedzieć błędem wskazującym, że pojazd nie istnieje. Wdrożenie powinno następnie odtworzyć pojazd w nowym stanie.
W bardzo mało prawdopodobnym scenariuszu katastrofalnej awarii Fleet Engine może być konieczne ponowne utworzenie większości lub wszystkich pojazdów i zadań. Jeśli tempo tworzenia stanie się zbyt wysokie, niektóre żądania mogą ponownie zakończyć się niepowodzeniem z powodu problemów z limitem, ponieważ limity są sprawdzane, aby uniknąć ataków typu „odmowa usługi” (DOS). W takim przypadku zmniejsz częstotliwość ponownego tworzenia, stosując strategię wycofywania w przypadku ponownych prób.
Liczba ponownych prób
Upewnij się, że system implementuje ponawianie żądań do Fleet Engine, ponieważ czasami mogą one się nie powieść. Biblioteki klienta Fleet Engine domyślnie ponawiają próby.
Utrata stanu w aplikacji dla kierowców
Jeśli aplikacja kierowcy ulegnie awarii, musi ona odtworzyć bieżący stan w pakiecie Driver SDK. Aplikacja powinna spróbować ponownie utworzyć zadania, aby upewnić się, że istnieją, i przywrócić ich bieżące stany. Aplikacja powinna też ponownie utworzyć i wyraźnie ustawić listę przystanków dla pakietu Driver SDK.
Uwaga: przywracanie musi odbywać się autonomicznie, bez korzystania z informacji z Fleet Engine, z wyjątkiem błędów wskazujących, czy i kiedy podmiot już istnieje w bazie danych. Jeśli element już istnieje, można zignorować ten błąd i zaktualizować element za pomocą jego identyfikatora.
O ile nie stwierdzono inaczej, treść tej strony jest objęta licencją Creative Commons – uznanie autorstwa 4.0, a fragmenty kodu są dostępne na licencji Apache 2.0. Szczegółowe informacje na ten temat zawierają zasady dotyczące witryny Google Developers. Java jest zastrzeżonym znakiem towarowym firmy Oracle i jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-09-05 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 2025-09-05 UTC."],[[["\u003cp\u003eFleet Engine implementations should be designed to handle failures and potential data loss by recreating vehicles and tasks when necessary.\u003c/p\u003e\n"],["\u003cp\u003eIn case of Fleet Engine failures, use a backoff strategy to manage the recreation rate and avoid quota issues.\u003c/p\u003e\n"],["\u003cp\u003eImplement retries for Fleet Engine requests to address occasional failures, leveraging client library defaults or custom mechanisms.\u003c/p\u003e\n"],["\u003cp\u003eDriver apps should autonomously restore state after crashes by recreating tasks and stops within the Driver SDK, relying on error handling for existing entities.\u003c/p\u003e\n"]]],["Implement error handling for Fleet Engine failures, such as vehicle non-existence, by recreating entities. In catastrophic failures, recreate vehicles and tasks, using a backoff strategy if quota issues arise. Implement request retries, as provided by Fleet Engine client libraries. If the driver app crashes, autonomously recreate tasks and stop lists within the Driver SDK, relying only on Fleet Engine errors to determine if entities already exist for update purposes.\n"],null,["# Troubleshoot common issues\n\nCheck the following sections for help if you experience any issues.\n\nLost state in Fleet Engine\n--------------------------\n\nWhen working with Fleet Engine, design your implementation to anticipate\nfailures. For example, if you issue a request to Fleet Engine to update a\nvehicle, it might respond with an error indicating that the vehicle does not\nexist. Your implementation should then recreate the vehicle in the new state.\n\nIn the extremely unlikely scenario of a catastrophic failure of Fleet Engine,\nyou may need to recreate most or all vehicles and tasks. If the creation rate\nbecomes too high, some requests may fail again due to quota issues since quota\nchecks are in place to avoid denial of service (DOS) attacks. In this case, slow\ndown the recreation rate using a backoff strategy for reattempts.\n\n### Retries\n\nBe sure your system implements retries for requests to Fleet Engine since they\nmight fail occasionally. Fleet Engine client libraries issue retries by default.\n\nLost state in the driver app\n----------------------------\n\nIf the driver app crashes, the app must recreate the current state within the\nDriver SDK. The app should attempt to recreate tasks to ensure that they exist\nand to restore their current states. The app should also recreate and explicitly\nset the list of stops for the Driver SDK.\n\n**Note**: These restorations must be done autonomously without relying on\ninformation from Fleet Engine, other than errors indicating if and when an\nentity already exists in the database. If an entity does already exist, then\nthat error can be absorbed and the entity can be updated using its ID."]]
