Date

Call-in Information

Time: 11:00 am, Eastern Daylight Time (New York, GMT-04:00)

To join the online meeting:

Slack

Attendees

(star)  Indicating note-taker

  1. Brian Lowe 
  2. Huda Khan (star)
  3. Don Elsborg
  4. Benjamin Gross
  5. Ralph O'Flinn

Agenda

  1. Open discussion
    1. Scholars: GraphQL and REST API
      1. Huda: Had considered a single API for VIVO with GraphQL or other implementations under the hood, so technologies or implementations could change without changing the API itself
      2. Ralph: GraphQL actually talking to REST API
      3. Don: Historical reasons: REST API part of TAMU's work with Angular. 
    2. Don: TDB loading is slow
      1. Brian: Haven't encountered a situation where TDB is as slow as SDB. Use SPARQL API.  Sometimes service available can remotely turn off inferencing/indexing.  Plain SPARQL update.  TDB usually better than SDB in this context
        1. May be related to how threads are managed
      2. Don: With RDF delta patch work - if listener is waiting for changes, if that portion could be put on another server, that may relieve resources for the main VIVO app
    3. Huda: Issue (also on email list) around how indexing plays into profile page load.  When information is updated, the first time the profile comes up it takes a long time
      1. Brian: Is she using multiple languages and if there are several? Noticed slow down recently that large publication lists in conjunction with large publication lists and on SDB, slow down possible because of filtering for desired language if operating against a much larger result set from SDB query
      2. Indexing process separate and not much related to the profile page, so it shouldn't be indexing that slows down the profile page
      3. Don: Custom faux properties that use OPTIONAL instead of UNION
      4. Ralph: Sometimes power settings on desktops can mess things up
      5. Huda: Will also suggest coming onto the development call and perhaps sharing screen/participating to help with debugging and/or troubleshooting
    4. Brian: Could be different ways of handling languages (as well as other areas) if were to architect from the ground up in the future
    5. Don: How does threading work with SPARQL update API?
      1. Brian: Not sure if additional threads are spun up. Each request made is own independent thread.  Separate threads talking to Jena persistence layer, and the Jena layer would be responsible for dealing with concurrent requests. 
      2. Don: Pondering what other options there are for sharding TDB store, etc. to load a lot more data quickly
    6. Benjamin: How safe to backup TDB without shutting down Tomcat? If transaction occurring while directory is being copied, there's a chance it could be corrupted
      1. Have cron job for backing that up nightly and ok so far
      2. Brian: could first check to see if lock file in TDB directory - if write lock exists, then wait until lock file disappears and then risk pretty lowly of copying at that point
      3. Don: Harvester issue - had to put in db close statements, operated on TDB - write locks gone in directory but database still thought it was open.  Set up branch in VIVO Community harvester and have PR from maint-rel-.1.11 into develop branch.
        1. Could we have a read only TDB?
        2. Brian: could write it so that only read only queries would be active (in the RDF service layer).  somewhere in startup listeners that set up two different models
  2. In-review tickets 
    1. Unable to locate Jira server for this macro. It may be due to Application Link configuration.

    2. type key summary assignee reporter priority status resolution created updated due

      Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Tickets

  1. Status of In-Review tickets

    type key summary assignee reporter priority status resolution created updated due

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Notes 


Actions

  • Organize a session on Brown's work on editing


  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.