talend soop auscpr & anmn_nrs_bgc - failing

[lbesnard]

harvesters are failing, same error

Exception in component sWfsInput_1_GI
java.lang.RuntimeException: Parsing failed for MetadataURL: java.lang.NullPointerException

[lbesnard]

Also to point out that for example, no mod has been done on auscpr harvester for the last 2 months. I don't think po's can solve this kind of issue.

@pblain ?

[pblain]

@lbesnard , please let @smancini know about this so that it can be included in the next pre-panning.

[lbesnard]

probably have spotted the issue. Took me some time cause the harvester was complaining about a variable which doesn't exist in the current version.

re anmn nrs bgc

@9-nsp-mel:/mnt/ebs/talend/jobs/anmn_nrs_bgc-anmn_nrs_bgc/etc$ talend_version anmn_nrs_bgc-anmn_nrs_bgc
GIT_COMMIT=21815ae6c65fa948a4c4be25fd2e1acbd9cb207f
BUILD_URL=https://kenkins.aodn.org.au/job/talend_build/182/
BUILD_TAG=jenkins-talend_build-182

but the latest commit is https://github.com/aodn/harvesters/commit/28ea65a7ee8d957d6162a7fae0a2ee257b7ab872

and I can't find this pipeline in https://jenkins.aodn.org.au/view/talend/. I suspect something got wrong there when changed from kenkins to jenkins. What do you think @danfruehauf ?

will see if same thing for auscpr

[lbesnard]

actually the commit number doesn't mean anything because it refers to the commit of the entire repo, not the one from the harvester

[danfruehauf]

@lbesnard Notice that https://github.com/aodn/harvesters/commit/21815ae6c65fa948a4c4be25fd2e1acbd9cb207f is after https://github.com/aodn/harvesters/commit/28ea65a7ee8d957d6162a7fae0a2ee257b7ab872

So the build trigger (when it was bulk rebuilt) did not necessarily take the latest specific commit of the directory, but the one of the repository.

To cut the long story short, changes from https://github.com/aodn/harvesters/commit/28ea65a7ee8d957d6162a7fae0a2ee257b7ab872 are included in the build.

[lbesnard]

re __ANMN_NRSBGC harvester 1) The harvester message is absolutely useless 2) it seems like the subjob station_harvest is the one which makes things fail (but for some reasons, talend doesn't put a red cross of the failing component, a bit harder to debug)

The NRS_STATION table from the CMAR geoserver WFS can be downloaded here as a CSV https://www.cmar.csiro.au/geoserver/imos/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=imos:NRS_STATION&maxFeatures=50&outputFormat=csv​

If one opens the file, there is no geometry point for the SOTS station. Since the sWFSInput component is configured to fail on NULL value of the column STATION_PT, then it fails. It's just that the error message is more than vague.

Anyway, seems like that's the fix to do. @mhidas Could you please contact cmar so they add the missing geometry value to the SOTS station ?

[mhidas]

@lbesnard Request sent to CMAR.

[lbesnard]

I'm also wondering how they compute their Lat/Lon coordinates :

Lon	lat	geom
151.21815	-34.11758	POINT (151.26 -34.15)
153.562	-27.345	POINT (153.6 -27.3)
151.22667	-34.11923	POINT (151.25 -34.08333)

[mhidas]

Update: the NULL value in the NRS_STATION table was fixed weeks ago. However, both harvesters are still failing, with this error:

Exception in component sWfsInput_1_GI
java.lang.RuntimeException: Parsing failed for MetadataURL: java.lang.NullPointerException

I don't see any reference to MetadataURL anywhere in either harvester's code, not even looking at their history on GitHub.

@pblain @smancini Could we please get one of the developers to look into this?

[lbesnard]

@mhidas this MetadataURL is not part of the contexts nor the harvester. It is part of the sWFsInput component. Pretty sure the component doesn't like empty cells, and can't handle the Nullable option. Would still be good to have a look at it as it's blocking other harvesters such as https://github.com/aodn/harvesters/commit/81071111e3a0cdd48293c5b577bd2f17095a0833

[danfruehauf]

DO NOT CLOSE THIS ISSUE UNTIL THIS IS SOLVED PROPERLY

The CMAR geoserver is failing constantly. Either get them to get their act together or I'm going to stop monitoring these 2 harvesters because they always fail.

[mhidas]

The error messages in the log are a bit different this time, though still looks like the problem is with the response from the CMAR Geoserver.

Exception in component sWfsInput_1_GI
java.util.NoSuchElementException: Could not aquire feature:org.geotools.data.wfs.protocol.wfs.WFSException: WFS returned an exception. Target URL: https://www.cmar.csiro.au/geoserver/wfs?SRSNAME=urn%3Ax-ogc%3Adef%3Acrs%3AEPSG%3A4326&TYPENAME=imos%3ANRS_STATION&VERSION=1.1.0&OUTPUTFORMAT=text%2Fxml%3B+subtype%3Dgml%2F3.1.1&SERVICE=WFS&REQUEST=GetFeature. Originating request is: 
<?xml version="1.0" encoding="UTF-8"?>
<wfs:GetFeature handle="GeoTools 8.5 WFS DataStore"
 outputFormat="text/xml; subtype=gml/3.1.1" resultType="results"
 service="WFS" version="1.1.0" xmlns:ogc="http://www.opengis.net/ogc"
 xmlns:gml="http://www.opengis.net/gml"
 xmlns:xlink="http://www.w3.org/1999/xlink"
 xmlns:ows="http://www.opengis.net/ows" xmlns:wfs="http://www.opengis.net/wfs">
 <wfs:Query srsName="urn:x-ogc:def:crs:EPSG:4326" typeName="imos:NRS_STATION"/>
</wfs:GetFeature>

        [[java.lang.RuntimeException: java.io.IOException
java.io.IOExceptionNo more data to read from socket]]
        at org.geotools.data.store.NoContentIterator.next(NoContentIterator.java:58)
        at org.geotools.data.store.NoContentIterator.next(NoContentIterator.java:43)
        at org.geotools.feature.collection.DelegateFeatureIterator.next(DelegateFeatureIterator.java:58)
        at anmn_nrs_bgc.station_harvest_0_1.station_harvest.sWfsInput_1_GIProcess(station_harvest.java:2293)
...

[danfruehauf]

Doesn't matter that much, this has to be either fixed properly or it will not be worth monitoring. It's reoccurring too many times.

[mhidas]

Info and request from CMAR:

We were performing database upgrades, which would have affected harvest of some layers. Can I please request again that you don't harvest over the weekend? If you forward your harvest times to us we can endeavour to keep services up, but please bear in mind that this is our maintenance window, and we reserve the right to schedule system downtime at short notice during the weekend. Note that we wouldn't expect any changes/edits to be occurring over this time.

I don't see why we couldn't schedule this harvester to run just only Monday to Thursday.

[danfruehauf]

@mhidas That's fine. I can do the required changes then.

[smancini]

Closing this issue for now as we had no problems with these two harvesters for a few months