geotools wfs-ng thread safety and strange behaviour problem

Question

I'm having a big trouble using geotools wfs-ng datastore plugin together with geoserver instance (geoserver is not a problem here, it's just a wfs implementation and provider of the data). Use case seems plain:

custom web service that is sort of proxy to underlying wfs
create wfs data store while my web service application starts:

final URL wfsUrl = new URL(url);
final WFSConfig wfsConfig = WFSConfig.fromParams(Map.of(
    WFSDataAccessFactory.AXIS_ORDER.key, WFSDataAccessFactory.AXIS_ORDER_EAST_NORTH));
final SimpleHttpClient httpClient = new SimpleHttpClient();
return new WFSDataStore(new WFSClient(wfsUrl, httpClient, wfsConfig));

reuse it on consecutive custom api calls to proxy underlying wfs, many of below calls are being done in multiple threads

final SimpleFeatureSource eventsSource = dataStore.getFeatureSource(typeName);
final String geometryColumn = dataStore.getSchema(typeName).getGeometryDescriptor().getLocalName();
final Filter filter = filterOf(parameters, geometryColumn);
final SimpleFeatureCollection eventsFeatures = eventsSource.getFeatures(new Query(typeName, filter));
final SimpleFeatureIterator features = eventsFeatures.features();
try {
    while (features.hasNext()) {
        final SimpleFeature next = features.next();
        //do something
    }
} finally {
    features.close();
}

tried version of geotools wfs-ng datastore plugin: 22.3, 23.5

symptoms:

strange in behaviour of the wfs-ng plugin is that every wfs GetFeature call releases DescribeFeatureType call (for the schema which seems failing, from org.geotools.xsd.impl PullParser probably), why isn't one sufficient?
after number of multithreaded wfs calls (sometimes less, somethimes more)

Caused by: java.lang.ArrayIndexOutOfBoundsException: arraycopy: last source index 94 out of bounds for object array[93]
    at java.base/java.lang.System.arraycopy(Native Method) ~[na:na]
    at org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapterList.ensureSafety(BasicNotifierImpl.java:214) ~[org.eclipse.emf.common-2.15.0.jar!/:na]
    at org.eclipse.emf.common.notify.impl.BasicNotifierImpl$EAdapterList.remove(BasicNotifierImpl.java:244) ~[org.eclipse.emf.common-2.15.0.jar!/:na]
    at org.geotools.xsd.impl.SchemaIndexImpl.destroy(SchemaIndexImpl.java:93) ~[gt-xsd-core-22.3.jar!/:na]
    at org.geotools.xsd.Encoder.encode(Encoder.java:1119) ~[gt-xsd-core-22.3.jar!/:na]
    at org.geotools.filter.v2_0.bindings.BinarySpatialOpTypeBinding$1.encode(BinarySpatialOpTypeBinding.java:70) ~[gt-xsd-fes-22.3.jar!/:na]
    at org.geotools.xsd.Encoder.encode(Encoder.java:727) ~[gt-xsd-core-22.3.jar!/:na]
    ... 103 common frames omitted

are you using GeoServer to cascade a remote WFS service or a GeoTools client to access a local (or remote) GeoServer WFS? where is the error thrown client or GeoServer? Where are you multi-threading? is there one client per thread or is it shared? — Ian Turton, Mar 04 '21 at 14:53
good catch, the problem is on client side: geotools wfs-ng implementation of wfs. geoserver is just a service providing the data, multithreading is also on client side, one datastore which is invoked in many threads (but tried with one datastore per thread and the problem still occured) — PiotrkS, Mar 04 '21 at 18:35
So are you sure it's a threading issue then, if it occurs when you have one client per thread. — Ian Turton, Mar 04 '21 at 18:51
currently I'm not, will run a case on single sequential request iterated multiple times and let you know if this still occur — PiotrkS, Mar 05 '21 at 10:10
multithreaded invocation gives error pretty fast, while invoting it in sequences I wasn't able to reproduce the case, I've managed to prepare a separated testbed for the case if you are interested: https://github.com/PiotrStrzelecki-TomTom/geotools-wfs-ng-showcase — PiotrkS, Mar 06 '21 at 16:47
Best to raise the issue on the geotools user list, where its easier to discuss — Ian Turton, Mar 06 '21 at 19:47

geotools wfs-ng thread safety and strange behaviour problem

0 Answers0