Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:

Attendees 

Agenda

  1. Update on status of memento/sprint 2 work

    1. Remaining work
      1. creating mementos (partially complete)
        1. https://github.com/fcrepo4/fcrepo4/pull/1262 ()
      2. getting listing of mementos
        1. FCREPO-2623
      3. getting mementos
    2. Status of Mohamed Mohideen Abdul Rasheed's in progress PR: (https://github.com/fcrepo4/fcrepo4/pull/1262)
      1. Do we need a volunteer to bring this one over the finish line? 
    3. Status of https://github.com/fcrepo4/fcrepo4/pull/1250:
      1. Support versioning with versioned child ignored
      2. Is there anything that needs to be discussed as a group in order to move this one forward? (Longshou Situ)
    4. PR's to be merged
      1. https://github.com/fcrepo4/fcrepo4/pull/1261 ()
      2. https://github.com/fcrepo4/fcrepo4/pull/1260 ()'
      3. https://github.com/fcrepo4/fcrepo4/pull/1241 (just needs to be merged - all feedback it complete)

  2. Follow-up discussion from last week: 

    1. Status of Doran's write-up regarding Fedora's strategy for permalinks
    2. Abandoning the single subject restriction: any feedback/illuminating discussion on the list?

  3. Stuck thread issue resolved! (post-op)

    1. https://groups.google.com/d/topic/fedora-tech/lPY4QGacnMg/discussion
  4. ...

  5. Tickets In-Review



Ticket Summaries

  1. Please squash a bug!


  2. Tickets resolved this week:


  3. Tickets created this week:


Minutes

  1. Memento work
    1. Mohammed's FCREPO-1262 was a Work In Progress start. It needs work to finish it. Danny Bernstein will try to push on this work and get it finished.
    2. Jared Whiklo not much progress on FCREPO-2623 
    3. Need some help merging some PRs that are in final stages
  2. Permalinks
    1. Concerns about Fedora URIs to be used in an abstract manner to the outside work. No changes from last week. Doron Shalvi to write up the issue and e-mail out to the Fedora listserv.
  3. Stuck thread issue
    1. It was the internal audit module that writes internal audit events back to the repository. Discovered by walking through starting from Modeshape kernel implementation to get a handle on what actual happens when you send a PUT/POST to the repo. What is the chain of steps when Modeshape persists. For every write to the repo, 2 audit records are written. One for the resource and one for the parent. So if we take the audit writes out of the equation, and it worked perfectly. So have removed the fcrepo-audit dependency since Monday. Was able to run 2 batches of 500 newspaper issues each. Each issue creates a couple hundred Fedora resources. With no stuck thread issue. Indexing was faster. Switched over to using the fcrepo-audit-triplestore camel route in development and testing it now. 
    2. Is there a bug there that needs to be fixed, like an endless loop? Not an endless loop, just the volume of writes that occur. Could possibly have been resolved by increasing the Modeshape buffer to an incredible size. It appears that multiple resources created inside one parent may have caused some of the lock conditions. No definite issue found in audit, but the N^2 writes from using audit seemed a good place to look.
    3. What would be helpful is to create a JIRA issue that pulls together the issue you've had and the resolution you found and points to what you think might be the issue. The we have a record and if someone else runs into it, they can find it. 
    4. There are unanswered issues to the direct cause, it appeared to be due to user-level transactions. But it also seems related to lower-level transaction handling. This is not a crazy use of the repository. They are 16 page newspapers, so several resources, proxy resources and binary resources but this should be usable.

Actions