Issue 18229

usage issues not synced from nub build

18229
Reporter: mdoering
Assignee: mdoering
Type: Bug
Summary: usage issues not synced from nub build
Priority: Major
Resolution: Fixed
Status: Closed
Created: 2016-02-11 13:33:45.458
Updated: 2016-02-18 10:32:04.119
Resolved: 2016-02-17 15:16:29.511
        
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]]>
    


Author: mdoering@gbif.org
Comment: do we have test coverage for this?
Created: 2016-02-11 13:34:49.175
Updated: 2016-02-11 13:34:49.175


Author: mdoering@gbif.org
Created: 2016-02-16 17:08:18.788
Updated: 2016-02-16 17:08:18.788
        
turns out this is a read problem in mybatis. A very strange one that only appears after 4 get NameUsage calls.

    


Author: mblissett
Created: 2016-02-16 19:22:26.518
Updated: 2016-02-16 19:22:26.518
        
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.


    


Author: mdoering@gbif.org
Created: 2016-02-16 20:01:32.914
Updated: 2016-02-16 20:01:32.914
        
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
    


Author: mdoering@gbif.org
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.
Created: 2016-02-16 21:44:42.052
Updated: 2016-02-16 21:44:42.052


Author: mblissett
Created: 2016-02-17 10:08:31.25
Updated: 2016-02-17 10:08:31.25
        
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

    


Author: mdoering@gbif.org
Created: 2016-02-17 15:12:10.25
Updated: 2016-02-17 15:12:10.25
        
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
    


Author: mdoering@gbif.org
Created: 2016-02-17 15:16:29.789
Updated: 2016-02-17 15:16:29.789
        
https://github.com/gbif/checklistbank/commit/272ab3f9b60f844e7f516d0f678f3b2c25bbb934

https://github.com/gbif/checklistbank/commit/43e86f07b0040f8c3a23511413af63d2af36f890
    


Author: mdoering@gbif.org
Comment: filed bug with pgjdbc https://github.com/pgjdbc/pgjdbc/issues/517
Created: 2016-02-18 10:32:04.119
Updated: 2016-02-18 10:32:04.119