W poprzednim poście pisałem iż czas życia instancji aplikacji w kontenerze GAE jest bardzo ograniczony ? aplikacja ładowana jest w momencie zapytania ? pozostaje w pamięci przez krótki czas ? o ile nie nadejdzie kolejne zapytanie.
Przy małym ruchu powoduje to w praktyce ładowanie aplikacji dla każdego zapytania – używając np. Springframework powoduje to kilkunasto sekundowe opóźnienie w obsłudze zapytania ? co jest niedopuszczalne.
Jak na razie jedynym rozwiązaniem, choć nie jestem w 100% przekonany, iż można założyć, że kolejne zapytanie zostanie obsłużone przez tą samą instancję, a po drugie zjada to …

Zanim zdecydujesz się na Google App Engine warto wiedzieć o pewnych przypadłościach i zastosowanych rozwiązaniach.

[-] Zapytania do Datastore mogą zwrócić jedynie do 1000 rekordów, zespół GAE pracuje nad propozycją kursora, który będzie pozwalał na iteracje po większej ilości danych.
[--] Duże limitacje GQL – w sortowaniu oraz użyciu operatorów. Szczegóły można przeczytać tutaj.
[---] Znaczne zużycie API CPU dla zapisu i odczytu danych z Datastore, zwłaszcza gdy ich hierarchia jest dość głęboka (więcej na ten temat w moim poprzednim poście – i o rozwiązaniu używając pola Serializowalnego).
[-] Długi czas tworzenia indeksów – …

W poprzednim poście napisałem o problemach z niebywale dużym zużyciem CPU podczas operacji zapisu do datastore Google App Engine. Od kilku dni zastanawiałem się, jak zaradzić temu problemowi – rozwiązanie znalazłem i zaimplementowałem dosłownie przed chwileczką.
Struktura rekordu z danymi zapisywany podczas zapytania do API była dość rozgałęziona – coś w stylu drzewa o 3 poziomach na drugim poziomie około 3-4 rekordów – na kolnym po około 2-3 dla każdego elementu z poziomu wyżej. Co ważne, żaden z elementów poniżej głównego rekordu nie był używany w zapytaniach.

Bawiąc się z małym projektem aplikacji dla Google App Engine doszedłem do różnych interesujących wniosków.
Jednym z ciekawszych jest użycie CPU – i bynajmniej nie CPU generowanego przez kod samej aplikacji – a CPU użyte przez datastore (jak wywnioskować można z panelu administracyjnego – około 90% użycia CPU jest generowane przez API Calls CPU).
Konsumowane jest ono w dość dużym tempie. Moja przykładowa aplikacja zapisuje pewne dane przy zapytaniu przesłanym do API. Zapytanie takie może zapisać/uaktualnić około (oszacowane manualnie na podstawie definicji modelu klas danych) 20 wierszy, musi załadować również dwa troszkę …

Po kilku tygodniach zabawy z GAE zauważyć można masę problemów. Jedną z bardzo denerwujących przypadłości Clouda w wykonaniu Google jest problem z Datastore, do którego proste zapytanie przekracza dozwolony czas odpowiedzi.
Logi prostej aplikacji po pewnym czasie pełne są informacji o DatastoreTimeoutException.

Jeżeli w Google App Engine próbujesz wysłać wiadomość e-mail i w logu widzisz błąd:

Illegal Arguments java.lang.IllegalArgumentException: Unauthorized Sender

upewnij się, czy aby na pewno jaki SENDER ustawione jest konto, które jest zarejestrowane jako jeden z administratorów Twojej aplikacji.
GAE pozwala wysyłać maile jedynie z kont zarejestrowanych jako administrator aplikacji. Możesz dodać dowolną ilość takich kont do swojej aplikacji w zakładce “Developers” w panelu administracyjnym.

Nie wiem jak wy, ale ja wolę eksploracyjne uczenie się nowych technologii. Czytanie kompleksowo dokumentcaji jakoś mi nie wychodzi Wolę odpalić Google i znaleźć to co potrzebuję.
I tak właśnie nie ładująca się lista obiektów zdefiniowana jako pole w jednej z klas pozwoliła mi odkryć taką oto stronę, gdzie czarno na białym (no, może z odrobiną koloru) przeczytać możemy o Fetch Groups – czyli tłumacząc (nie dosłownie) grupach przechwytywania – bo przynoszenia dziwnie brzmi.

Często sprawy oczywiste są najtrudniejsze do odkrycia!
I tym razem tak było. Przeoczyłem część dokumentacji do Google App Engine i już w duchu narzekałem, że nie można lokalnie podejrzeć i edytować Data Store dla GAE. No i nic bardziej mylnego, jak jasno napisane w dokumentacji wystarczy otworzyć: http://localhost:8080/_ah/admin gdy nasza aplikacja jest uruchomiona i po sprawie!
Pozdrowionka!

Ech. Nie jest łatwo zaprzyjaźnić się z GAE. Ciągle jakieś schody…
Przed momentem odkryłem problem z dostępem za pomocą refleksji do java.util.TimeZone, chcąc wyświetlić listę stref czasowych.
Wszystko zaczęło się niewinnie, od atrybutu modelu, zawierającego przefiltrowane listy:

Jeżeli zaraz po uaktualnieniu Twojej aplikacji Google App Engine otrzymujesz błąd HTTP 500:
Error: Server Error
The server encountered an error and could not complete your request.
If the problem persists, please report your problem and mention this error message and the query that caused it.
natomiast w logach serwera znajduje się następująca informacja:
Request was aborted after waiting too long to attempt to service your request. Most likely, this indicates that you have reached your simultaneous active request limit. This is almost always due to excessively high latency in your app. Please see http://code.google.com/appengine/docs/quotas.html …