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