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: