Несоответствующий синтаксический анализ WKB с использованием JTS - PullRequest
Новая
       41

Несоответствующий синтаксический анализ WKB с использованием JTS

1 голос
/ 07 марта 2020

У меня самая странная проблема, которую я просто не могу обернуть. Мой веб-API, который использует Spring Boot и postgresql / postgis, получает непоследовательные ошибки при попытке прочитать геометрию из базы данных. Я использую этот код (со случайными изменениями, конечно) в течение многих, многих лет, и это только начинает происходить в моем последнем выпуске.

Я использую openjdk 11.0.4 2019-07-16 в Ubuntu 18.04. Удалить pom. xml записи ... 

        <groupId>org.locationtech.jts</groupId>
            <artifactId>jts-core</artifactId>
            <version>1.16.1</version>
        </dependency>

Я получаю различные ошибки от API-вызовов следующих типов ...

например hexstring: 0101000020E6100000795C548B88184FC0206118B0E42750C0 

org.locationtech.jts.io.ParseException: Unknown WKB type 0
    at org.locationtech.jts.io.WKBReader.readGeometry(WKBReader.java:235)
    at org.locationtech.jts.io.WKBReader.read(WKBReader.java:156)
    at org.locationtech.jts.io.WKBReader.read(WKBReader.java:137)
    at net.crowmagnumb.database.RecordSet.getGeom(RecordSet.java:1073)

например, шестнадцатеричная строка: 0101000020E61000000080FB3F354F5AC0F3D30EF2C0773540 

java.lang.ArrayIndexOutOfBoundsException: arraycopy: length -1 is negative
    at java.base/java.lang.System.arraycopy(Native Method)
    at org.locationtech.jts.io.ByteArrayInStream.read(ByteArrayInStream.java:59)
    at org.locationtech.jts.io.ByteOrderDataInStream.readDouble(ByteOrderDataInStream.java:83)
    at org.locationtech.jts.io.WKBReader.readCoordinate(WKBReader.java:378)
    at org.locationtech.jts.io.WKBReader.readCoordinateSequence(WKBReader.java:345)
    at org.locationtech.jts.io.WKBReader.readPoint(WKBReader.java:256)
    at org.locationtech.jts.io.WKBReader.readGeometry(WKBReader.java:214)
    at org.locationtech.jts.io.WKBReader.read(WKBReader.java:156)
    at org.locationtech.jts.io.WKBReader.read(WKBReader.java:137)
    at net.crowmagnumb.database.RecordSet.getGeom(RecordSet.java:1073)

например, шестнадцатеричная: 0101000020E610000066666666669663C00D96D7371DD63440

* * * * * *5 = не соответствует номеру строки *, номер которого не указан * * * 
public class RecordSet {
    private static final Logger logger = LoggerFactory.getLogger(RecordSet.class);
    private static WKBReader wkbReader;

    private static WKBReader getWKBReader() {
        if (wkbReader == null) {
            wkbReader = new WKBReader();
        }
        return wkbReader;
    }

    private static byte[] hexStringToByteArray(final String hex) {
        if (StringUtils.isBlank(hex)) {
            return null;
        }

        int len = hex.length();
        byte[] data = new byte[len / 2];
        for (int i = 0; i < len; i += 2) {
            data[i / 2] = (byte) ((Character.digit(hex.charAt(i), 16) << 4) + Character.digit(hex.charAt(i + 1), 16));
        }
        return data;
    }

    public static Geometry getGeom(final String geomStr) {
        byte[] byteArray = hexStringToByteArray(geomStr);
        if (byteArray == null) {
            return null;
        }
        try {
            return getWKBReader().read(byteArray);
        } catch (Throwable ex) {
            logger.error(String.format("Error parsing geometry [%s]", geomStr), ex);
            return null;
        }
    }
}

Итак, крайне странно, что

  1. Это не происходит последовательно. Точно такой же вызов API, когда я пытаюсь повторить, работает нормально.
  2. Сообщенные шестнадцатеричные строки в сообщении об исключении совершенно верны! Если я запускаю их в тестовой программе с использованием того же кода, дайте правильный ответ и не исключение.

Опять все вышеупомянутые шестнадцатеричные строки, которые приводят к ошибкам в производственных вызовах API, являются действительными представлениями геометрии POINT .

Это какая-то странная потенциальная проблема утечки памяти?

1 Ответ

0 голосов
/ 08 марта 2020

Может быть, это должно было быть очевидно, но в свою защиту я использовал приведенный выше код много, много лет (как я уже говорил) без проблем, так что я думаю, что просто упустил очевидное? В любом случае, меня вдруг осенило, должен ли я снова и снова использовать один и тот же WKBReader в многопоточной среде? Что ж, получается, нет!

Если я просто создаю новый WBBReader () с каждым вызовом (вместо того, чтобы получать один stati c WKBReader), он работает нормально. Ну, есть источник моей "утечки памяти". Самостоятельная причина!

...