Uploaded image for project: 'Portal'
  1. Portal
  2. POR-3032

usage issues not synced from nub build

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      according to solr these names should have issues:
      http://www.gbif-uat.org/species/search?q=&dataset_key=d7dddbf4-2cf0-4f39-9b2a-bb099caae36c&issue=PUBLISHED_BEFORE_GENUS

      Looking at the record the parent is different from the binomial, so it should have another issue flag:
      http://www.gbif-uat.org/species/7827453

      But no issues are shown:
      http://api.gbif-uat.org/v1/species/7827453

      Smells like a nub import sync bug

        Gliffy Diagrams

        Issue Links

          Activity

          Hide
          Markus Döring added a comment -

          do we have test coverage for this?

          Show
          Markus Döring added a comment - do we have test coverage for this?
          Hide
          Markus Döring added a comment -

          turns out this is a read problem in mybatis. A very strange one that only appears after 4 get NameUsage calls.

          Show
          Markus Döring added a comment - turns out this is a read problem in mybatis. A very strange one that only appears after 4 get NameUsage calls.
          Hide
          Matthew Blissett added a comment -

          It's not (unfortunately) the cache key collision fixed by this commit: https://github.com/mybatis/ehcache-cache/commit/e5bcb6f0cdf52e8a1c04033fd0a9aad8965acd0b (we aren't using the caching?)

          It's not something introduced by release 3.3.1 of MyBatis, which is only 3 days old.

          Using full Postgres query logging, the same query is being made each time.

          The issue still happens with requests to different names, e.g.
          service.get(100000037, null);
          service.get(100000038, null);
          service.get(100000039, null);
          service.get(100000040, null); ← fails.

          Show
          Matthew Blissett added a comment - It's not (unfortunately) the cache key collision fixed by this commit: https://github.com/mybatis/ehcache-cache/commit/e5bcb6f0cdf52e8a1c04033fd0a9aad8965acd0b (we aren't using the caching?) It's not something introduced by release 3.3.1 of MyBatis, which is only 3 days old. Using full Postgres query logging, the same query is being made each time. The issue still happens with requests to different names, e.g. service.get(100000037, null); service.get(100000038, null); service.get(100000039, null); service.get(100000040, null); ← fails.
          Hide
          Markus Döring added a comment -

          caching can be enabled by setting the mybatis config in the properties file in our config repo. It is not enabled in any of our projects although we could. We should see if ehcache gains us sth. We used to have it enabled I recall in the beginnings
          http://www.mybatis.org/mybatis-3/configuration.html#settings

          Show
          Markus Döring added a comment - caching can be enabled by setting the mybatis config in the properties file in our config repo. It is not enabled in any of our projects although we could. We should see if ehcache gains us sth. We used to have it enabled I recall in the beginnings http://www.mybatis.org/mybatis-3/configuration.html#settings
          Hide
          Markus Döring added a comment -

          I can trace the same behavior down to straight JDBC PreparedStatements. Simple Statements work fine, just repeated prepared statements stop working after 5 times.

          Show
          Markus Döring added a comment - I can trace the same behavior down to straight JDBC PreparedStatements. Simple Statements work fine, just repeated prepared statements stop working after 5 times.
          Hide
          Matthew Blissett added a comment -

          I never pressed Add on this yesterday:

          I tracked it down to the JDBC driver anyway — the debugger showed a binary response representing the array being turned to null. (I've now lost track of exactly where, I lost my breakpoints when I changed the driver version.)

          According to this comment https://github.com/pgjdbc/pgjdbc/issues/421#issuecomment-155397895 the Postgres JDBC backend switches to a named statement after the 5th time. That bug has been fixed, and ours remains with the latest driver, but it's suspiciously close.

          PostgresJDBC changelog: https://jdbc.postgresql.org/documentation/changelog.html

          Show
          Matthew Blissett added a comment - I never pressed Add on this yesterday: I tracked it down to the JDBC driver anyway — the debugger showed a binary response representing the array being turned to null. (I've now lost track of exactly where, I lost my breakpoints when I changed the driver version.) According to this comment https://github.com/pgjdbc/pgjdbc/issues/421#issuecomment-155397895 the Postgres JDBC backend switches to a named statement after the 5th time. That bug has been fixed, and ours remains with the latest driver, but it's suspiciously close. PostgresJDBC changelog: https://jdbc.postgresql.org/documentation/changelog.html
          Hide
          Markus Döring added a comment -

          the postgres data type was changed to plain text and type handler and analysis sql adjusted.
          Works fine on uat now: http://api.gbif-uat.org/v1/species/1432

          Show
          Markus Döring added a comment - the postgres data type was changed to plain text and type handler and analysis sql adjusted. Works fine on uat now: http://api.gbif-uat.org/v1/species/1432
          Show
          Markus Döring added a comment - https://github.com/gbif/checklistbank/commit/272ab3f9b60f844e7f516d0f678f3b2c25bbb934 https://github.com/gbif/checklistbank/commit/43e86f07b0040f8c3a23511413af63d2af36f890
          Hide
          Markus Döring added a comment -
          Show
          Markus Döring added a comment - filed bug with pgjdbc https://github.com/pgjdbc/pgjdbc/issues/517

            People

            • Assignee:
              Markus Döring
              Reporter:
              Markus Döring
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: