Mir ist es ein paarmal passiert dass der Download der Ergebnisse über den Browser (d.h. vom IDP auf meinen lokalen Rechner im Büro) nach einer Weile abgebrochen hat, es gab keine weitere Fehlermeldung, in der Übersicht stand unter dem Download nur "fehlgeschlagen".

Ist heute bei einer MOD14- und einer Landsat 8-Order aufgetreten und soweit ich mich erinnern kann auch schon bei Sentinel.

Der Link mit dem das heute passiert ist:
https://217.150.144.19/oseov100-0.0.1/ordering?orderid=ID-DataInputPortalDev-48547-1441800341422-0-2891
(habe ich 2mal versucht, hat bei ca. 600 MB abgebrochen)

PS.:
Die Downloadgeschwindigkeit ist heute auch extremst gering, keine 20 KB/Sekunde.
(EDIT: Heute bei ca. 1 MB / Sekunde)

PS2.:
Vielleicht ein Timeout ?

Mir ist es gestern und heute passiert, dass der Katalog abstürzt wenn man viele Metadaten einfügen möchte.

In beiden Fällen liefen Schleifen die nacheinander mehrere 10.000 Datensätze eingefügt haben, irgendwann ist die Konsolen-Ausgabe des Application-Servers mitten in einem Wort stehen geblieben und dadurch ist auch der Task im ESB (ohne Fehlermeldung) stehen geblieben.

PS.:
Der Application Server lässt sich danach nur neu starten wenn man die ganze VM neu startet, anscheinend ist die DB noch gesperrt..

PS2.:
Tritt im Moment nicht mehr auf, sollten wir in Sachen Zuverlässigkeit aber im Auge behalten.

Ich habe mehrere Orders aufgegeben, die auch korrekt heruntergeladen und vom Consolidation Module bearbeitet wurden.

Als Status bekomme ich aber immer nur "partial" zurück, und in der WSO2-Konsole vom Input Data Portal laufen Fehlermeldungen durch:
ERROR - WSEventDispatcher Unable to send message
org.apache.axis2.AxisFault: DataInputPortal
(..)
Caused by: java.net.UnknownHostException: DataInputPortal

Ich nutze die Dev. - Version vom IDP da ich etwas am Consolidation Module verändert habe.

Wir müssen uns auch noch darum kümmern, dass einmal geladene Dateien und der Output des Consolidation-Modules nach einer bestimmten Zeit automatisch gelöscht werden.
Im Moment bleiben die Daten unbegrenzt liegen.

Ist aber glaube ich nicht der dringenste offene Punkt, ich wollte es nur schon einmal auf die ToDo-Liste setzen.

Es wäre glaube ich hilfreich nochmal den Katalog-Inhalt zu löschen, weil sich da inwzsichen doch einige fehlerhafte Datensätze angesammelt haben dürften.

Außerdem wäre die Frage, ob wir die landsat-Metadaten im Katalog behalten wollen, da wir die Dateien ja nicht bestellen können.

Ich habe mehrere Orders mit je einer Landsat8-Datei aufgegeben, für alle Orders wurde das Browse-Image runtergeladen, aber danach wurde weder die große Datei geladen noch das Consolidation-Module aufgerufen, sondern die Browse-Images scheinen in einer Art Endlosschleife immer wieder neu geladen zu werden.

IDP-Dev, Order zB Nr. 1853

Ich habe eine Bestellung mit 20 Dateien aufgegeben (Nr. 910), die auch alle erfolgreich heruntergeladen wurden.

In dem Ordner /storage/910/ gab es dann aber 2 Unterordner in denen je 10 Dateien lagen und das Consolidation Module hat jeden der Unterordner einzeln bearbeitet.

Die Dateien waren auch nicht nach Datum sortiert, in jedem Ordner lagen in dem Beispiel Dateien aus 2010 und 2011.

Ich habe letzte Woche testweise einige Landsat-Metadaten in den katalog eingelesen.
Jetzt scheint eine Abfrage nach allen Datensätzen (Status=ARCHIVED) zu lange zu dauern, so dass nach einer Weile eine Fehlermeldung angezeigt wird.

Wahrscheinlich braucht die VM also mehr Leistung.
Auch die Festplatte dürfte bald wieder zu eng werden, FR waren noch ca. 200 GB frei, jetzt sind es noch ca. 130. D.h. wenn wir später alle Metadaten einlesen wollen, brauchen wir noch mehr Festplattenplatz für die Datenbank.

PS:
Wir brauchen zwischen 2.5 und 4 GB für 100.000 Datensätze, wenn wir von ca. 10 Mio. Datensätzen ausgehen und etwas Spielraum haben wollen, wäre eine 500 GB - Festplatte für die Katalog-Datenbank also angemessen.

Ich habe ca. 960 Dateien (in 55 Orders mit je bis zu 20 Dateien) kurz nacheinander bestellt, dabei sind bei vielen Orders Fehler aufgetreten: "Error-Message: Internal Status: Suspended Description: All files or some of them are re-scheduled for another download try."

Zur Einordnung:
Diese Menge an Dateien fällt an wenn wir ein kleines Untersuchungsgebiet für ein Jahr berechnen wollen, bei größeren Gebieten und mehreren Jahren gleichzeitig kann sich die Zahl der Dateien schnell verzehnfachen.

Da es auch Orders gibt die funktioniert haben, liegt der Fehler wohl in der Koordination der vielen gleichzeitigen Orders, nicht in dem inhaltlichen Code für die Bearbeitung einer Bestellung.
EDIT: Vielleicht zuviele Downloads gleichzeitig vom selben Server versucht ?
Wir hatten schonmal entsprechende Fehlermeldungen "to many connections" als wir unsere Verbindungen nicht sauber getrennt hatten.

Was auch wieder passiert ist, ist dass eine Order mit mehreren Dateien für das Consolidation-Module in mehrere Unterordner aufgeteilt wurde, was zu Fehlern führen kann.
(siehe Fehler #12 )

PS.:
Ich habe das produktive IDP benutzt, nicht die Dev.-Version.

Bei landsat 8 passiert es oft (immer?) dass der Download nach ca. 600 MB (bei ca. 1 MB die Sekunde Downloadgeschwindigkeit also nach ca. 10 Minuten) abbricht.

Ist da vielleicht ein Timeout zu niedrig gesetzt ?

Ich konnte ein paar Orders aufgeben und auch den Status abfragen, aber wenn ich jetzt weitere Dateien ordern will (egal welche parentID) bekomme ich folgende Fehlermeldung in der WSO2-Konsole:

SCHWERWIEGEND: Servlet.service() for servlet [cxf] in context with path [/oseov-0.0.1] threw exception java.lang.NullPointerException
at org.apache.cfx.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:251)
(..)

Die Response ist eine HTTP-Seite:
Endpoint: http://192.168.10.60:9766/oseov100-0.0.1/services

HTTP Status 500 -

type Exception report

message

description The server encountered an internal error that prevented it from fulfilling this request.

exception

java.lang.NullPointerException org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:251) org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234) org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208) org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160) org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171) org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:293) org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:212) javax.servlet.http.HttpServlet.service(HttpServlet.java:755) org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:268) 

note The full stack trace of the root cause is available in the Apache Tomcat/7.0.34 logs.

Apache Tomcat/7.0.34

Ich habe mehrere MOD14-Orders gleichzeitig aufgegeben, aber in einigen fehlt danach die reprojectete Datei. In der Error-Log-Datei steht dass die Command-Line nicht ausgeführt werden könnte.

Im Moment vermute ich, dass das daran liegen könnte, dass mehrere Consolidation-Jobs (die in eigenen Threads parallel laufen) gleichzeitig dasselbe CommandLine-Tool nutzen wollen und dass das nicht möglich ist.

Darum muss ich mich kümmern, aber das könnte ein größerer Punkt sein, also eine Weile dauern.

Bis dahin:
MODIS-active fires und MODIS-burned areas nur einzeln bestellen und warten bis eine Order fertig ist.
RapidEye und Landsat sind nicht betroffen.

Der Service zum Anlegen der Consolidation Jobs scheint nicht mehr richtig aufgerufen zu werden:
Nach dem Download wird in der Konsole angezeigt, dass der Service aufgerufen wird, aber der Code des Services selber wird anscheinend trotzdem nicht ausgeführt.

Er sollte Ausgaben in der Konsole machen und Text in ein Logfile schreiben, was aber beides nicht passiert, die erste Zeile des im Service ausgeführten Codes lautet z.B.:
Out.WriteLn("\r\nStart Insert Consolidation-Job Service:");
Das sollte in der Konsole des WSO2-MB erscheinen.

In der Benutzeroberfläche vom WSO2 Message Broker steht:
Request Count: 6
Response Count: 0
Fault Count: 6

Das heisst natürlich auch, dass im Moment alle Orders mit FAILED enden.

Bei einigen (allen?) Landsat-Metadaten im Katalog sind lat und long vertauscht, so dass man zB irgendwo im roten Meer landet, wenn man nach München sucht.

In meinem aktuellem Code kann ich keinen Fehler finden.
Dieselben Methoden werden auch zum Einfügen der MODIS-Metadaten verwendet, wo ich schon erfolgreiche Bounding-Box-Tests (daten für Deutschland) durchgeführt habe..

Im Moment versuche ich die Landsat-Metadaten nochmal neu einzulesen, evtl. wurden die mit einer älteren Version eingespielt, die noch fehlerhaft war.

Die falschen Landsat-Ergebnisse haben aber nichts mit den anderen Problemen bei bounding-box-Abfragen zu tun !

Bei den Downloads von Orders mit dem parentIdentifier Sentinel1 benötigt man einen Benutzernamen und ein Passwort. Am besten wäre es meiner Meinung nach dafür einen neuen Account für das IDP im Sentinel data Hub anzulegen: https://scihub.esa.int/dhus/

Außerdem laufen die Downloads über HTTPS, was bei uns (Zugriff auf die Metadaten über die REST-Schnittstelle) einige Probleme mit den Zertifikaten verursacht hat.

Order Nr. 1265 enthält einen Sentinel1-Datensatz.
Die Fehlermeldung lautet:
Internal Status: Suspended Description: Download got an execution timeout or a concurrence access error to the target local file. The exceution was re-scheduled.
(Das Ganze auf dem normalem IDP, nicht auf der Entwicklungs-Version)

PS.:
Die Download-URLs sind auch etwas anders aufgebaut als bisher:

Beispiel für einen Download:
https://scihub.esa.int/dhus/odata/v1/Products('4fcc6058-514e-4f52-87b4-445d0d8029e4')/$value

Beispiel für ein Quicklook-Image:
https://scihub.esa.int/dhus/odata/v1/Products('4fcc6058-514e-4f52-87b4-445d0d8029e4')/Nodes('S1A_IW_GRDH_1SDV_20141205T060219_20141205T060244_003580_00439E_129B.SAFE')/Nodes('preview')/Nodes('quick-look.png')/$value

PS2.:
Der Download scheint in einer Endlosschleife festzuhängen:
Seit gestern Nachmittag kommt immer wieder dieselbe Fehlermeldung, der Downloadversuch wird nicht nach einer bestimmten Zahl von Fehlversuchen komplett abgebrochen.

Im Moment funktioniert der Metadata-Harvester nicht, d.h. es können keine neuen Daten in den Katalog eingelesen werden.

Das Problem ist, dass der WSO2 MB teilweise veralteten Code ausführt, der so nicht mehr in der AAR-Datei vorhanden ist.

Beim Einfügen von Metadaten in den Katalog habe ich folgenden Fehler bekommen:

WARNUNG: Error while committing data
java.sql.SQLException: Could not create slots
Slot urn:ogc:def:ebRIM-Slot:OGC-06-131:ascendingNodeDate of object urn:MYD14:2122002412 is not registered yet.

Das ist wahrscheinlich beim Löschen des Katalog-Inhaltes passiert ?
Am Metadaten-Einlesen haben wir schon länger nichts mehr verändert.

Eine RE Order mit 5 Szenen (die schon oft funktioniert hat) bricht nach 30 Sekunden mit Order Status Failed ab.
OrderID:ID-DataInputPortalDev-37262-1442493174792-0-13723

Wenn ich einen MODIS-active fires - Datensatz mit * in der URL bestelle, bekomme ich eine Fehlermeldung, der Download funktioniert nicht.

Order Nr. 1874 auf dem IDP-Dev.:

Ich habe eine RE-Datei bestellt, diese wurde nicht fertig runtergeladen (steht bei 91 MB, nachdem es vorher schon extrem langsam war), aber trotzdem gibt es schon einen Ordner /storage/1874/ für das Consolidation-Module, in dem sich aktuell 6 leere Unterordner befinden.

Alle 2 Minuten scheint ein zusätzlicher Unterordner dazu zu kommen.

Ich habe nach einer kleinen Bounding-Box gesucht, aber alle Datensätze (650.000) zurück bekommen, die im Katalog sind..

Mit der Bounding-Box hatten wir ja schonmal Probleme, zB unterschiedliche Ergebnisse, je nachdem, ob man BBOX oder BBox schreibt..

Request einer Suche:
(ohne eckige Klammern wegen Darstellung)

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
soapenv:Header/
soapenv:Body
csw:GetRecords startPosition="141" version="2.0.2" service="CSW" outputFormat="text/xml; charset=UTF-8" outputSchema="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" xmlns:ogc="http://www.opengis.net/ogc" xmlns:gml="http://www.opengis.net/gml" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
csw:Query typeNames="rim:ExtrinsicObject"
csw:ElementSetName typeNames="rim:ExtrinsicObject"
summary/csw:ElementSetName
csw:Constraint version="1.1.0"
ogc:Filter
ogc:And
ogc:PropertyIsEqualTo
ogc:PropertyName
/rim:ExtrinsicObject/@objectType/ogc:PropertyName
ogc:Literal
urn:x-ogc:specification:csw-ebrim:ObjectType:EO:EOProduct/ogc:Literal
/ogc:PropertyIsEqualTo
ogc:BBox
ogc:PropertyName
/rim:ExtrinsicObject/rim:Slot[@name="urn:ogc:def:ebRIM-Slot:OGC-06-131:multiExtentOf"]/rim:ValueList/rim:Value[1]/ogc:PropertyName
gml:Envelope srsName="EPSG:4326"
gml:lowerCorner
47 12/gml:lowerCorner
gml:upperCorner
48 13/gml:upperCorner
/gml:Envelope
/ogc:BBox
/ogc:And
/ogc:Filter
/csw:Constraint
/csw:Query
/csw:GetRecords
/soapenv:Body
/soapenv:Envelope

Bei den MCD64-Dateien (meint Datensätze mit parentIdentifier = NASA:AQUATERRA:MODIS:MCD64) habe ich mangels weiterer Metadaten bisher den Dateinamen mit in den Identifier der Katalog-Datensätze eingebaut. Diese Dateinamen haben sich allerdings inzwischen verändert.

Deshalb habe ich aktuell alle MCD64-Datensätze doppelt im Katalog, einmal mit den neuen und einmal mit den alten Dateinamen im Identifier, wobei die alten Dateinamen nicht mehr gefunden werden, so dass beim Download entsprechende Fehler kommen und die Order fehlschlägt.

In Zukunft baue ich den Platzhalter (*) sowohl beim Dateinamen als auch beim Identifier ein, aber die alten Datensätze müssen aus dem Katalog gelöscht werden.

Über dieses aktuelle Problem hinaus wäre es generell praktisch, eine Löschfunktion zu haben um nicht mehr benötigte Einträge (z.B. Landsat) zu entfernen und so auch die Performance zu erhöhen.

Die RapidEye Orders sind immer noch unvollständig, bei meinen letzten Orders waren auch kleine Bestellungen von z.B. einer Szene nicht vollständig(z.B. Order 726).

Es gibt noch Probleme beim Rückmelden des Consolidation-Ergebnisses (Server returned Error 500).

Im MOment benutze ich diesen Endpoint:
(URL des IDP):9766/services/jobstatus_response_service

Den Fehlermeldungen in der WSO2-Konsole nach zu urteilen gibt es diesen Endpoint nicht.
Der Workflow läuft aber trotzdem noch weiter über den alten GetStatus-Service.

Order Endpoint returns http response code 500 for Order XML that worked with older IDP versions.

Im Ordner /storage/ gibt es einige leere Ordner, z.B.:
urn_MYD14_2121999795
urn_Sentinel1_9b030bfe-483a-4750-8ab8-b71518d195e6
urn_MCD64_MCD6A1.A2012001.h09v06.051._.hdf

In diesen Ordnern sollten eigentlich die (noch nicht weiter verarbeiteten) Downloads liegen, insofern scheint mir der Download für diese Dateien nicht funktioniert zu haben ?

Das Internet auf unserer VM (ZebrisMain) geht wieder.

Auch das übrige Netzwerk im IDPDev scheint nicht mehr zu funktionieren:
Katalog-Anfragen von unserer VM scheinen gar nicht erst anzukommen, es gibt keine Aktivität in den WSO2-Konsolen.
Und wenn ich im IDPDev lokal einen Job über SOAPUI anlegen will, bekomme ich die Meldung:
Java.net.SocketException: Das Netzwerk ist nicht erreichbar.

Wenn ich mich richtig erinnere hatten wir mal festgelegt dass für das Consolidation-Module immer nur Dateien aus einem Jahr für einen Consolidation-Job übergeben werden sollten. Ich glaube das hatte letztes Jahr auch schonmal funktioniert. Wenn Daten aus mehreren Jahren in einer Order waren wurde für jedes Jahr ein neuer Unterordner angelegt und es wurden für eine Order mehrere Consolidation-Jobs angelegt.

Im Moment werden aber anscheinend immer alle Dateien einer Order zusammen dem Consolidation-Module übergeben und es wird nur ein Consolidation-Job angelegt.

Wenn man MCD45, MCD64 oder MCD12 bestellt führt das dazu, dass Mosaike aus diesen Dateien gebildet werden, auch wenn sie zeitlich nicht zusammenpassen.
Dann hat man z.B. ein Mosaik das im Westen Daten aus 2007 anzeigt und um Osten Daten aus 2008.
Eine Fehlermeldung erzeugt das Consolidation-Module im Moment nicht, d.h. der Job ist am Ende DONE obwohl das Ergebnis unbrauchbar ist.

Bei den anderen Produkten hat das keine Auswirkung.

Ist für die Präsentation auch nicht so wichtig da wir da ohnehin max. Daten aus einem Jahr bestellen werden und außer uns diese Daten glaube ich niemand verwendet. Hat also keine Priorität.

PS.:
Könnte man auch durch eine Anpassung des Consolidation-Modules lösen.

Seit gestern bleiben meine Orders im Status "partial", mit der zusätzlichen Nachricht:
„Waiting, next status will be changed to download or error”.

Auf der Festplatte im IDP ist wieder genug Platz (war letzte Woche mal fast voll), den WSO2-MB habe ich auch schon neu gestartet, das hilft aber nichts. In der Konsole laufen Meldungen durch, die für mich so klingen als wäre die Datenbank gesperrt, wie/warum auch immer..

Es werden aktuell unter /storage keine neuen Ordner mehr angelegt, was früher immer passiert ist, selbst wenn die Order danach fehlgeschlagen ist.

PS.:
Ein Neustart der VM scheint auch nichts geholfen zu haben.

Ich habe versucht, Landsat-Szenen zu bestellen, und dabei einige Male keine Response erhalten.
ZB beim Versuch die Szene Landsat:LE71930272010222ASN00 zu bestellen.

Eine andere Landsat-Szene oder eine MODIS-Szene konnte ich dagegen bestellen.

Die Konsolidierung der MOD14-Dateien funktioniert anscheinend nicht mehr, das CommandLine-Tool für die Reprojection meldet fast immer einen Fehler.

Da wir die Landsat-Daten nicht über das IDP bestellen können und die Datensätze einen großen Teil des Kataloges ausmachen (und entsprechend die Performance verschlechtern) wäre es meiner Meinung nach überlegenswert, die Landsat-Metadaten nicht mehr im IDP zu behalten.

Wenigstens solange es keine Möglichkeit die Dateien auch wirklich automatisch downzuloaden.

Auch wenn wir daran nichts ändern können mache ich mal einen Punkt für die Probleme mit der Web-Oberfläche auf, um das wenigstens zu dokumentieren:

Aktuell ist es bei mir so, dass die Web-Oberfläche mit Mozilla Firefox (evtl. seit dem letzten Update) nicht aufgerufen werden kann, im Internet Explorer komme ich zwar auf die Web-Oberfläche, kann aber keine virtuellen Maschinen öffnen, weil sich das entsprechende Plugin nicht installieren lässt.

Im Moment nutze ich Opera, da muss ich zwar auch gelegentlich einige Minuten auf das Login warten, aber dann funktioniert es. Diese lange Wartezeit hatte ich im Firefox auch schon seit einigen Wochen, aber bis vor ca. 2 Wochen kam dann irgendwann das Login.

Beim Einfügen von Landsat-Metadaten bekomme ich 2 verschiedene Fehler:

-Einmal ein internes Java-Problem mit leeren Strings, das unter Windows beim Lesen der CSV-datei nicht auftritt.

-Und gelegentlich einen Fehler-Code 500 (Internal Server Error) vom Katalog beim Einfügen der Metadaten.

Der erste Fehler scheint bei jedem Datensatz aufzutreten (EDIT: Bei vielen, aber nicht allen), der zweite nur gelegentlich. Kann also unterschiedliche Ursachen haben.

Evtl. Zusammenhang mit Fehler #7 ?

Da ich die Metadaten auslese trage ich mich selber als assigned ein, für den internen Serverfehler brauche ich aber evtl. Hilfe von Abel, wenn er nach Lösen des ersten Fehlers noch auftritt.

Ich habe 2 Orders (Nr. 912 und 913) aufgegeben, die an und für sich korrekt bearbeitet wurden: Die Downloads wurden korrekt durchgeführt und das Consolidation-Module ist durchgelaufen und hat "Done" als Status für seinen Job abgespeichert.

Aber wenn ich den Status der Order abfrage bekomme ich (auch nach längerem Warten) nur ein "partial".

Die Fehlermeldungen in der Konsole sehen für mich so aus, als würde das IDP den GetJobStatus-Service vom Consolidation Module nicht erreichen.

Beim Aufruf des Consolidation Modules wird für den ParentIdentifier manchmal der Wert "unknown" übergeben (=steht in der Tabelle zebris.jobs), was dann dazu führt, dass dieser Consolidation-Job fehlschlägt (Status=FAILED).

Bei der Suche nach Datensätzen in Deutschland finde ich z.B. mehrere Landsat-Szenen mit diesen Koordinaten als posList:

52.76601 -179.7945
52.29843 -177.07431
50.60282 -177.8851
51.06222 179.4916
52.76601 -179.7945
(also auf beiden Seiten der Datumsgrenze bei 180 Grad)

Korrekterweise wäre das ein Rechteck über der Datumsgrenze, dargestellt wird es aber als ein schmaler Streifen einmal rund um den Globus. So wird die Szene auch für Deutschland gefunden, obwohl sie es natürlich nicht abdeckt.

PS.:
Das sie gefunden wird, obwohl nach Szenen in Deutschland gesucht wurde, bedeutet dass der Katalog die Koordinaten falsch interprtiert.
Das die Szene im PHP-Client als Streifen rund um den Globus dargestellt wird, bedeutet dass auch Leaflet diese Koordnaten falsch versteht.

Ähnliche Probleme hatten wir auch schon mit PostGIS, das scheint viele GIS-Produkte zu betreffen.