Page History

...

1. Please squash a bug!

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

2. Tickets resolved this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

3. Tickets created this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

Minutes

1. Memento work
   1. Mohammed's
   PR
   1. 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. 

Actions

1. 1. Doron Shalvi to write up the issue and e-mail out to the Fedora listserv.
2. 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

• Danny Bernstein will try to push forward on FCREPO-1262.
• Doron Shalvi will write up a description of the Fedora URI concerns and post to the Fedora listserv to start discussion.
• Peter Eichman will create a ticket to document the stuck thread issue that UMD experienced and how they have resolved it thus far.
• Bring the proposal to disable versioning using a read-only LDPCv to the Fedora spec editors
• Document UMD's custom authNZ Tomcat configuration (Peter Eichman)