[Archivesspace_Users_Group] FW: Archivesspace_Users_Group Digest, Vol 40, Issue 2
Greta Kuriger Suiter
gsuiter at mit.edu
Fri Dec 2 12:16:52 EST 2016
Just wanted to record a problem with ASpace and see if anyone has a solution. When I try to add a sibling to a folder list it adds the sibling to the bottom of the list - not where I want it to go. I then have to drag the newly created folder up to where I wanted to put it. Anyone else have this problem / know a solution? When I do this I have the folder before the one I want to create highlighted, thinking that the added sibling would fall in after the highlighted one but that doesn't happen.
Thanks for any help! I'll search this list history for answers too.
-Greta
Greta Kuriger Suiter
Collections Archivist | Institute Archives & Special Collections
MIT Libraries, Bldg. 14N-118 | 77 Massachusetts Ave., Cambridge, MA 02139-4307
gsuiter at mit.edu
My pronouns: she, her, hers
-----Original Message-----
From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of archivesspace_users_group-request at lyralists.lyrasis.org
Sent: Wednesday, November 16, 2016 9:40 AM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: Archivesspace_Users_Group Digest, Vol 40, Issue 2
Send Archivesspace_Users_Group mailing list submissions to
archivesspace_users_group at lyralists.lyrasis.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
or, via email, send a message with subject or body 'help' to
archivesspace_users_group-request at lyralists.lyrasis.org
You can reach the person managing the list at
archivesspace_users_group-owner at lyralists.lyrasis.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Archivesspace_Users_Group digest..."
Today's Topics:
1. Re: LibraryHost (Tummino, Annie)
2. Re: LibraryHost (Tummino, Annie)
3. Check out the test site of the new ArchivesSpace PUI
(Custer, Mark)
4. Re: Check out the test site of the new ArchivesSpace PUI
(Custer, Mark)
5. new technical support option for ArchivesSpace members
(Christine Di Bella)
6. Job Posting: Digital Initiatives Librarian @ Brandeis
University (Hong Jing)
7. Job posting for Vanderbilt University (ArchivesSpaceHome)
8. DACS 7.1.6 equivalent in ArchivesSpace (Cheri Crist)
9. Problems working with archival object with large number of
direct children (Sally Vermaaten)
10. Re: [archivesspace] Problems working with archival object
with large number of direct children (Runyon, Carolyn)
11. Re: Problems working with archival object with large number
of direct children (Ryan Edwards)
12. Re: Problems working with archival object with large number
of direct children (Jason Loeffler)
13. Re: Problems working with archival object with large number
of direct children (Jason Loeffler)
14. Re: Problems working with archival object with large number
of direct children (Joshua D. Shaw)
15. Re: Problems working with archival object with large number
of direct children (James Bullen)
16. Re: Problems working with archival object with large number
of direct children (Jason Loeffler)
17. Re: Problems working with archival object with large number
of direct children (James Bullen)
18. A user who is set as manager of a collection can not create
containers... (Gadsby, Eric T.)
19. Re: Problems working with archival object with large number
of direct children (Jason Loeffler)
20. Re: Problems working with archival object with large number
of direct children (James Bullen)
21. Re: A user who is set as manager of a collection can not
create containers... (Payten Giles)
22. Re: A user who is set as manager of a collection can not
create containers... (Payten Giles)
23. Re: A user who is set as manager of a collection can not
create containers... (Gadsby, Eric T.)
24. Re: Problems working with archival object with large number
of direct children (Joshua D. Shaw)
25. Re: A user who is set as manager of a collection can not
create containers... (Yvonne Kester)
----------------------------------------------------------------------
Message: 1
Date: Thu, 10 Nov 2016 22:06:49 +0000
From: "Tummino, Annie" <atummino at sunymaritime.edu>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] LibraryHost
Message-ID: <d2478d3ae0184133ad042e3ec72119fe at EX02.sunymaritime.edu>
Content-Type: text/plain; charset="utf-8"
P.S. I should add that this is really for creating resources (finding aids) and assumes you have already set up a repository and created an accession.
From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Clifford Allen
Sent: Thursday, October 27, 2016 3:57 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] LibraryHost
Thanks Annie -- we're in the same boat. Good to know that the training is on hold; maybe that'll give us a little time to get more of our stuff together.
I would be interested in seeing that user guide if it is not too much trouble. This is virgin territory for us though I have worked in porting out EAD to DAMs before... it's a little different.
Cheers,
Clifford
On Thu, Oct 27, 2016 at 3:21 PM, Tummino, Annie <atummino at sunymaritime.edu<mailto:atummino at sunymaritime.edu>> wrote:
Hi Allen,
We just started using LibraryHost a couple of months ago and it is working out great so far. I sent this same query to the SAA Lone Arrangers list and only got positive feedback about LibraryHost, which made me confident about moving forward. They also offer a free trial which is nice.
Because we have no EAD files to begin with, we are starting with a relatively clean slate, so we didn?t need assistance with migration. Generally speaking, I am sure starting from scratch is a lot easier than what large institutions are confronting.
I?ll note that the LibraryHost expert on ASpace is currently on maternity leave, so they are not able to do a training until she returns, but we are moving forward with branding in her absence. I have found that for our needs, I?ve been getting along just fine using the ASpace help center documentation, and it?s not really been a problem that we had to put off the training. We are creating a user guide which I?d be happy to share with you.
Hope this helps,
Annie
From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Clifford Allen
Sent: Thursday, October 27, 2016 11:27 AM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] LibraryHost
Hi All,
Forgive me if this has been brought up before and is a dead-horse topic, but as someone who is just beginning to implement ArchivesSpace, what are the advantages/disadvantages of LibraryHost as compared to Atlas and LYRASIS? As we are a small institution their lower price points are attractive, but I'm wondering if that is because certain necessary services/aspects aren't being offered.
Thanks so much in advance for weighing in.
Sincerely,
--
Clifford Allen
Archivist | The Watermill Center | Robert Wilson
115 W 29th St., 10th Fl., New York, NY 10001
main: +1 212 253 7484 x 113<tel:%2B1%20212%20253%207484%20x%20113>
clifford.allen at watermillcenter.org<mailto:clifford.allen at watermillcenter.org> | www.watermillcenter.org<http://www.watermillcenter.org>
JOIN US! | BECOME A MEMBER OF THE WATERMILL CENTER TODAY
Connect with us on Facebook<https://www.facebook.com/thewatermillcenter>, Twitter<http://twitter.com/#%21/watermillcenter>, Instagram<http://instagram.com/watermillcenter>, Flickr,<http://www.flickr.com/photos/watermillresidencies/> and Vimeo<https://vimeo.com/watermillcenter>. Join our email list!<http://watermillcenter.org/content/newsletter-signup>
The Watermill Center is the principal operation of the Byrd Hoffman Watermill Foundation, a US 501(c)3 organization incorporated in the state of New York.
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
--
Clifford Allen
Archivist | The Watermill Center | Robert Wilson
115 W 29th St., 10th Fl., New York, NY 10001
main: +1 212 253 7484 x 113
clifford.allen at watermillcenter.org<mailto:clifford.allen at watermillcenter.org> | www.watermillcenter.org<http://www.watermillcenter.org>
JOIN US! | BECOME A MEMBER OF THE WATERMILL CENTER TODAY
Connect with us on Facebook<https://www.facebook.com/thewatermillcenter>, Twitter<http://twitter.com/#%21/watermillcenter>, Instagram<http://instagram.com/watermillcenter>, Flickr,<http://www.flickr.com/photos/watermillresidencies/> and Vimeo<https://vimeo.com/watermillcenter>. Join our email list!<http://watermillcenter.org/content/newsletter-signup>
The Watermill Center is the principal operation of the Byrd Hoffman Watermill Foundation, a US 501(c)3 organization incorporated in the state of New York.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161110/2b464b8f/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 10 Nov 2016 22:08:25 +0000
From: "Tummino, Annie" <atummino at sunymaritime.edu>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] LibraryHost
Message-ID: <523f6c8459934b039830b01928647d8c at EX02.sunymaritime.edu>
Content-Type: text/plain; charset="utf-8"
Sorry folks! I was trying to send this to Clifford and mistakenly sent to the whole list. Well, if anyone else wants to see our Guide, there you have it. That?s what happens when you try to do things at the end of the day when you are about to leave.
Best,
Annie
From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Tummino, Annie
Sent: Thursday, November 10, 2016 5:07 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] LibraryHost
P.S. I should add that this is really for creating resources (finding aids) and assumes you have already set up a repository and created an accession.
From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Clifford Allen
Sent: Thursday, October 27, 2016 3:57 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] LibraryHost
Thanks Annie -- we're in the same boat. Good to know that the training is on hold; maybe that'll give us a little time to get more of our stuff together.
I would be interested in seeing that user guide if it is not too much trouble. This is virgin territory for us though I have worked in porting out EAD to DAMs before... it's a little different.
Cheers,
Clifford
On Thu, Oct 27, 2016 at 3:21 PM, Tummino, Annie <atummino at sunymaritime.edu<mailto:atummino at sunymaritime.edu>> wrote:
Hi Allen,
We just started using LibraryHost a couple of months ago and it is working out great so far. I sent this same query to the SAA Lone Arrangers list and only got positive feedback about LibraryHost, which made me confident about moving forward. They also offer a free trial which is nice.
Because we have no EAD files to begin with, we are starting with a relatively clean slate, so we didn?t need assistance with migration. Generally speaking, I am sure starting from scratch is a lot easier than what large institutions are confronting.
I?ll note that the LibraryHost expert on ASpace is currently on maternity leave, so they are not able to do a training until she returns, but we are moving forward with branding in her absence. I have found that for our needs, I?ve been getting along just fine using the ASpace help center documentation, and it?s not really been a problem that we had to put off the training. We are creating a user guide which I?d be happy to share with you.
Hope this helps,
Annie
From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Clifford Allen
Sent: Thursday, October 27, 2016 11:27 AM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] LibraryHost
Hi All,
Forgive me if this has been brought up before and is a dead-horse topic, but as someone who is just beginning to implement ArchivesSpace, what are the advantages/disadvantages of LibraryHost as compared to Atlas and LYRASIS? As we are a small institution their lower price points are attractive, but I'm wondering if that is because certain necessary services/aspects aren't being offered.
Thanks so much in advance for weighing in.
Sincerely,
--
Clifford Allen
Archivist | The Watermill Center | Robert Wilson
115 W 29th St., 10th Fl., New York, NY 10001
main: +1 212 253 7484 x 113<tel:%2B1%20212%20253%207484%20x%20113>
clifford.allen at watermillcenter.org<mailto:clifford.allen at watermillcenter.org> | www.watermillcenter.org<http://www.watermillcenter.org>
JOIN US! | BECOME A MEMBER OF THE WATERMILL CENTER TODAY
Connect with us on Facebook<https://www.facebook.com/thewatermillcenter>, Twitter<http://twitter.com/#%21/watermillcenter>, Instagram<http://instagram.com/watermillcenter>, Flickr,<http://www.flickr.com/photos/watermillresidencies/> and Vimeo<https://vimeo.com/watermillcenter>. Join our email list!<http://watermillcenter.org/content/newsletter-signup>
The Watermill Center is the principal operation of the Byrd Hoffman Watermill Foundation, a US 501(c)3 organization incorporated in the state of New York.
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
--
Clifford Allen
Archivist | The Watermill Center | Robert Wilson
115 W 29th St., 10th Fl., New York, NY 10001
main: +1 212 253 7484 x 113
clifford.allen at watermillcenter.org<mailto:clifford.allen at watermillcenter.org> | www.watermillcenter.org<http://www.watermillcenter.org>
JOIN US! | BECOME A MEMBER OF THE WATERMILL CENTER TODAY
Connect with us on Facebook<https://www.facebook.com/thewatermillcenter>, Twitter<http://twitter.com/#%21/watermillcenter>, Instagram<http://instagram.com/watermillcenter>, Flickr,<http://www.flickr.com/photos/watermillresidencies/> and Vimeo<https://vimeo.com/watermillcenter>. Join our email list!<http://watermillcenter.org/content/newsletter-signup>
The Watermill Center is the principal operation of the Byrd Hoffman Watermill Foundation, a US 501(c)3 organization incorporated in the state of New York.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161110/9fa832cd/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 11 Nov 2016 14:47:59 +0000
From: "Custer, Mark" <mark.custer at yale.edu>
To: "Archivesspace Users Group
(archivesspace_users_group at lyralists.lyrasis.org)"
<archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Check out the test site of the
new ArchivesSpace PUI
Message-ID:
<BN3PR08MB131830F17AA189BFAE17674E8CBB0 at BN3PR08MB1318.namprd08.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Dear ArchivesSpace colleagues:
I am writing to provide an update about the development of the new ArchivesSpace Public Interface. As a reminder, here is the release timeline that we drafted and shared earlier in the year:
* candidate release, 12/16/2016
* official testing period, 12/19/2016 - 2/28/2017
* official release, 3/31/2017
We're still on track to have everything done in time for an official release in March, but it's likely that we will push that candidate release date back a few weeks. Since we haven't changed the date yet I don't have a new date to share at this time, but if we do push the date back it will probably be postponed to January.
In the meantime, I also wanted to share a link with everyone to a working version of the new public interface so that you could see things in action before everything is finished. You can access that website here:
http://pui.hudmol.com/
(and thanks to Hudson Molonglo for hosting this site for us during the development process!!!)
Please note that this site is still a work in progress. You might stumble across bugs, and it's possible that some features could stop working from one day to the next. Also, not all features have been added (e.g. "Record Group" / Classification pages) or fully implemented yet (e.g. the "Collection organization" navigation sidebar). In any event, this site will provide a more interactive way to explore the development process before the design has been finished. In the coming weeks, we will also create a few introductory videos for the new PUI that will focus on and explain a few of the new, exciting features.
You can also follow along with the development process at the ArchivesSpace PUI wiki: https://archivesspace.atlassian.net/wiki/display/ADC/Public+Interface+Enhancement+Project<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_ADC_Public-26-2343-3BInterface-26-2343-3BEnhancement-26-2343-3BProject&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=EVhE7hGgEiFUwEqMCd6wOUjBAjB-m9qD3KnMCwCnzGk&s=9J-sJPfocPm1WF4QSm9MvnLFX4jAWKWwRSNMGBqB5jc&e=>
More news soon,
Mark Custer
On behalf of the ArchivesSpace Public Interface development group.
* James Bullen, Hudson Molonglo
* Mark Cooper, LYRASIS
* Mark Custer, Yale University
* Bobbi Fox, Harvard University
* Payten Giles, Hudson Molonglo
* Brian Hoffman, Consultant
* Susan Pyzynski, Harvard University
* Mark Triggs, Hudson Molonglo
* Brad Westbrook, ArchivesSpace
* Melissa Wisner, Yale University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161111/b1ef5532/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 11 Nov 2016 15:18:52 +0000
From: "Custer, Mark" <mark.custer at yale.edu>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Check out the test site of
the new ArchivesSpace PUI
Message-ID:
<BN3PR08MB1318741EC76BD5401A2DBC918CBB0 at BN3PR08MB1318.namprd08.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
All,
I regret that I didn't include at least one search example with the previous announcement. Since today's the first day of the 2016 World Chess Championship, here's a timely one:
http://pui.hudmol.com/search?utf8=%E2%9C%93&q=chess
I'll also come back to this example later on in one of the introductory videos, since I think it might be a good case to explain how the new archival inheritance feature will work once it's implemented (see https://archivesspace.atlassian.net/browse/AR-1300).
All my best,
Mark
From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark
Sent: Friday, 11 November, 2016 9:48 AM
To: Archivesspace Users Group (archivesspace_users_group at lyralists.lyrasis.org)
Subject: [Archivesspace_Users_Group] Check out the test site of the new ArchivesSpace PUI
Dear ArchivesSpace colleagues:
I am writing to provide an update about the development of the new ArchivesSpace Public Interface. As a reminder, here is the release timeline that we drafted and shared earlier in the year:
* candidate release, 12/16/2016
* official testing period, 12/19/2016 - 2/28/2017
* official release, 3/31/2017
We're still on track to have everything done in time for an official release in March, but it's likely that we will push that candidate release date back a few weeks. Since we haven't changed the date yet I don't have a new date to share at this time, but if we do push the date back it will probably be postponed to January.
In the meantime, I also wanted to share a link with everyone to a working version of the new public interface so that you could see things in action before everything is finished. You can access that website here:
http://pui.hudmol.com/<https://urldefense.proofpoint.com/v2/url?u=http-3A__pui.hudmol.com_&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=mHKsaKwdKo1giNBjiurqEHO18veSK4gHeKMYhEh3Y_s&s=cT2ROAsYvRYwVtJMlVbfF0Uij0OilGhnxk88YuxsoKM&e=>
(and thanks to Hudson Molonglo for hosting this site for us during the development process!!!)
Please note that this site is still a work in progress. You might stumble across bugs, and it's possible that some features could stop working from one day to the next. Also, not all features have been added (e.g. "Record Group" / Classification pages) or fully implemented yet (e.g. the "Collection organization" navigation sidebar). In any event, this site will provide a more interactive way to explore the development process before the design has been finished. In the coming weeks, we will also create a few introductory videos for the new PUI that will focus on and explain a few of the new, exciting features.
You can also follow along with the development process at the ArchivesSpace PUI wiki: https://archivesspace.atlassian.net/wiki/display/ADC/Public+Interface+Enhancement+Project<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_wiki_display_ADC_Public-26-2343-3BInterface-26-2343-3BEnhancement-26-2343-3BProject&d=CwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=EVhE7hGgEiFUwEqMCd6wOUjBAjB-m9qD3KnMCwCnzGk&s=9J-sJPfocPm1WF4QSm9MvnLFX4jAWKWwRSNMGBqB5jc&e=>
More news soon,
Mark Custer
On behalf of the ArchivesSpace Public Interface development group.
* James Bullen, Hudson Molonglo
* Mark Cooper, LYRASIS
* Mark Custer, Yale University
* Bobbi Fox, Harvard University
* Payten Giles, Hudson Molonglo
* Brian Hoffman, Consultant
* Susan Pyzynski, Harvard University
* Mark Triggs, Hudson Molonglo
* Brad Westbrook, ArchivesSpace
* Melissa Wisner, Yale University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161111/5b70d59c/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 14 Nov 2016 14:19:02 +0000
From: Christine Di Bella <christine.dibella at lyrasis.org>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>, Archivesspace
Member Reps <archivesspace_member_reps at lyralists.lyrasis.org>,
"archivesspace_tac_uac at lyralists.lyrasis.org"
<archivesspace_tac_uac at lyralists.lyrasis.org>
Cc: "archivesspace_bot_members at lyralists.lyrasis.org"
<archivesspace_bot_members at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] new technical support option for
ArchivesSpace members
Message-ID:
<DM2PR0801MB08486FEAD74E619903115941F1BC0 at DM2PR0801MB0848.namprd08.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Dear ArchivesSpace members,
ArchivesSpace is happy to announce an additional way for ArchivesSpace members to receive technical support. Courtesy of resources approved by the ArchivesSpace Governance Board, staff from LYRASIS Technology Services will be taking an added role in providing help to individual ArchivesSpace members and contributing to the technical documentation for the application.
As befits a Community-Supported Software application, when you need help, we encourage you to look to the community first by posting to the Users Group listserv. Given the breadth of knowledge and experience on the listserv, and the sheer number of people participating (currently over 850 subscribers), many issues will be resolved quickly this way and everyone will benefit from the discussion of the issue and its solution.
If you are unable to resolve the issue using the listserv, or if you think you need more individualized assistance from the start, please email ArchivesSpaceHome at lyrasis.org<mailto:ArchivesSpaceHome at lyrasis.org> with your issue. If it requires technical assistance beyond the program staff's expertise, a program staff member will create a ticket and LYRASIS Technology Services staff will follow up with you. When applicable, once the issue has been resolved, LYRASIS Technology Services staff will also update related technical documentation on GitHub to make the issue easier to resolve for other users.
Please note that while there is no limit on the number of requests a member organization may make for assistance, support provided through membership is geared toward helping people learn how to help themselves and there are limits to the complexity of issues that can be addressed. For example, membership does not include hosting, customization, data migration, or intensive data repair. We can provide you with strong guidance in these areas, but we can't undertake the solutions themselves for you. If your issue requires assistance beyond what is possible through membership, we will alert you to this and suggest alternatives.
Please continue to file bug reports and feature requests via JIRA at http://support.archivesspace.org. More information is available at https://archivesspace.atlassian.net/wiki/display/ADC/How+to+Report+a+Bug and https://archivesspace.atlassian.net/wiki/display/ADC/How+to+Request+a+New+Feature. Program staff can assist you with filing these if you need help, or if a bug report or feature request comes out of your support request.
We hope that you will find the availability of this additional level of technical assistance helpful. If you have any questions, or if you need assistance, please email the program team at ArchivesSpaceHome at lyrasis.org<mailto:ArchivesSpaceHome at lyrasis.org>.
Christine
Christine Di Bella
Community Outreach Manager
christine.dibella at lyrasis.org<mailto:christine.dibella at lyrasis.org>
800.999.8558 x2905
678-235-2905
cdibella13 (Skype)
[cid:image003.png at 01CE734E.FD759D30]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161114/ffeb11b2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7645 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161114/ffeb11b2/attachment-0001.png>
------------------------------
Message: 6
Date: Mon, 14 Nov 2016 09:52:00 -0500
From: Hong Jing <jennyjing at brandeis.edu>
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Job Posting: Digital Initiatives
Librarian @ Brandeis University
Message-ID:
<CAMFN=HY+8KKyfw9yeNkkmBvADKtfbWHSzRGXV8598eDsWMBgkg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
*Please excuse for cross-posting*
*Job Posting: Digital Initiatives Librarian (Job ID: 525688)*
Brandeis University seeks to hire a Digital Initiatives Librarian to be
responsible for administration and configuration of institutional
repository and related systems and applications.
*Examples of Key Responsibilities:*
- Responsible for administration and configuration of institutional
repository and related systems and applications, including but not limited
to creation of new IR communities and collections. Outreach to
communities, for planning and performing batch loads of new collections,
implementation of workflow, technical processes and methodology, and
administering authorizations and roles within the institutional repository
and related applications.
- Works in conjunction with library systems staff, vendor support staff
and open source communities, and Scholarly Communications to troubleshoot,
resolve and escalate problems; works in conjunction with library systems
staff to coordinate and perform application and system upgrades. Creates
specifications and scripting for metadata transformation and crosswalks.
- Performs technical support for faculty and staff in the use of the
institutional repository and related applications, and assists with process
and workflow development. Works as a member of the library team to plan
and implement changes to delivered public interfaces; works as a member of
the library team to integrate digital collections with other campus-wide
applications.
- Assists with creation of short and long-term plans for digitization of
selected materials, working with content specialists and faculty members to
determine priorities for digitization. Works as a member of Library &
Technology Service (LTS) teams to assist faculty and staff in decision
making for new collections. Receives requests for assistance with digital
materials, and evaluates the appropriateness of those materials for
inclusion in current or future digital asset systems.
- Performs execution and support of LTS institutional repository
policies and procedures, and assists in the development of policies as
needed. Serves as resident authority for metadata and digitization
standards. Helps guide and ensure adherence to capture standards, metadata
standards, preservation standards, technical workflow and quality control.
- Back-up core function of systems in the library and be available for
on-call
*Qualifications:*
MLS or MSI degree from an ALA-accredited institution of higher education;
3-5 years experience with library digital repositories
Experience developing and managing digital software (DSpace,
ArchivesSpace); knowledge and experience working in Unix or Linux systems
at the CLI
Proven engagement in the broader library systems community with a focus on
administering and supporting digital initiatives applications and services;
familiarity with metadata standards such as EAD, MARC, Dublic Core
Strong organizational, communication, customer service and interpersonal
skills; ability to work well with faculty, staff, and students.
*Preferred skills:*
Familiarity with digitization projects and standards for various materials,
e.g. electronic theses and dissertations, manuscripts, photographs and
audio and video recordings
Experience with scripting languages and using APIs; experience with CSS,
XML, XSL, XSLT and harvesting standards; experience in a research library
or academic library
*How to Apply:*
Submit cover letter and resume as a single document at
http://www.brandeis.edu/humanresources/jobs/external.html. Elect option
for "External Applicant". Sort the job listing by clicking the *Job
ID* column
heading. Locate the desired job listing by Job ID. Click the job title
and then Apply Now.
*Closing Statement:*
Brandeis University is an affirmative action/equal opportunity employer and
encourages minorities, women, disabled individuals, and eligible veterans
to apply. It is the policy of the University not to discriminate against
any applicant or employee on the basis of race, ancestry, color, religion,
sex, sexual orientation, age, genetic information, national origin,
disability, veteran status, or on the basis of any other legally protected
category.
--
Jenny Jing
Manager, Library Systems
Library & Technology Services,
Brandeis University Library
781-736-4698
JennyJing at brandeis.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161114/9596dc4d/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 15 Nov 2016 13:56:15 +0000
From: ArchivesSpaceHome <ArchivesSpaceHome at lyrasis.org>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Job posting for Vanderbilt
University
Message-ID:
<DM2PR0801MB0848D4E2205EF8D204522EF6F1BF0 at DM2PR0801MB0848.namprd08.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Posted on behalf of Valerie Hotchkiss.
From: Hotchkiss, Valerie [mailto:valerie.hotchkiss at vanderbilt.edu]
Sent: Monday, November 14, 2016 2:53 PM
To: ArchivesSpaceHome <ArchivesSpaceHome at lyrasis.org>
Subject: Job posting
Dear Archives Space colleagues,
Since this job description specifically entails introducing ArchivesSpace at Vanderbilt, I wonder if you can help us spread the word about it?
https://vanderuniv.taleo.net/careersection/.vu_cs/jobdetail.ftl?job=1605657
Many thanks,
v
Valerie Hotchkiss
University Librarian
The Jean and Alexander Heard Library<http://www.library.vanderbilt.edu/>
Vanderbilt University
(615) 322-4782
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/5444b374/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 15 Nov 2016 12:34:55 -0500
From: Cheri Crist <ccrist at eastman.org>
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] DACS 7.1.6 equivalent in
ArchivesSpace
Message-ID:
<CAGmhTeNHR5u_t2H8hB3Eg6ynv28Lta=AQFVXEmfHf031MF3dvA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi list,
I'm finding that somewhere in the annals of time, individual pieces of
ephemera were given museum object numbers in TMS, and these numbers are
written on the items. I'm wondering if anyone out there has a best practice
for recording these numbers in AS. I thought recording the TMS number in
the Component Unique Identifier field at item level would work, but it
doesn't show up in the pdf. (It does show in the public interface,
however.) What have other people done?
Thanks,
Cheri
Cheri Crist
Project Archivist
Richard and Ronay Menschel Library
George Eastman Museum
900 East Ave.
Rochester, NY 14607
ccrist at eastman.org
(585)271-3361 ext. 280
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/7ae31a86/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 15 Nov 2016 14:37:56 -0500
From: Sally Vermaaten <sally.vermaaten at nyu.edu>
To: archivesspace at googlegroups.com, Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Problems working with archival
object with large number of direct children
Message-ID:
<CALt9ybsGYKTab7ESLLCxZ6qCk64TXr3ysZzqdiPXN0WomXzAWA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi everyone,
We're running into an issue with a large resource record in ArchivesSpace
and wonder if anyone has experienced a similar issue. In one resource
record, we have a series/archival object with around 19,000 direct
children/archival objects. We've found that:
- it takes several minutes to open the series in the 'tree' navigation
view and then, once opened scrolling through series is very slow / laggy
- it takes a couple of minutes to open any archival object in the series
in edit mode and
- it takes a couple of minutes to save changes to any archival object
within the series
Does anyone else have a similarly large archival object in a resource
record? If so, have you observed the same long load/save time when editing
the component records?
The slow load time does not seem to be affected by memory allocation; we've
tried increasing the speed / size of the server and it seemed to have no
effect. We'd definitely appreciate any other suggestions for how we might
fix or work around the problem.
We also wonder if this performance issue is essentially caused by the
queries being run to generate the UI view - i.e. perhaps in generating the
resource 'tree' view, all data for the whole series (all 19k archival
objects) is being retrieved and stored in memory? If so, we wondered if it
would be possible and would make sense to change the queries running during
tree generation, etc. to only retrieve some batches at a time, lazy loading
style?
Thanks,
Weatherly and Sally
--
Sally Vermaaten
Project Manager, Archival Systems
New York University Libraries
1-212-992-6259
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/f4355ae5/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 15 Nov 2016 19:46:25 +0000
From: "Runyon, Carolyn" <Carolyn-Runyon at utc.edu>
To: "archivesspace at googlegroups.com" <archivesspace at googlegroups.com>,
Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] [archivesspace] Problems
working with archival object with large number of direct children
Message-ID: <A53D9B54-61F9-4CE9-9208-C03808A87914 at utc.edu>
Content-Type: text/plain; charset="utf-8"
We have noticed this as well. In fact, one of our resource records is large enough that it won?t open on the staff interface at all.
Carolyn Runyon
Assistant Head of Collection Services and Director of Special Collections
University of Tennessee at Chattanooga Library
615 McCallie Ave., Chattanooga, TN 37403
Carolyn-Runyon at utc.edu<mailto:Carolyn-Runyon at utc.edu>, (423) 425-4503
Dept. 6456, LIB 439D
On Nov 15, 2016, at 2:37 PM, Sally Vermaaten <sally.vermaaten at nyu.edu<mailto:sally.vermaaten at nyu.edu>> wrote:
Hi everyone,
We're running into an issue with a large resource record in ArchivesSpace and wonder if anyone has experienced a similar issue. In one resource record, we have a series/archival object with around 19,000 direct children/archival objects. We've found that:
* it takes several minutes to open the series in the 'tree' navigation view and then, once opened scrolling through series is very slow / laggy
* it takes a couple of minutes to open any archival object in the series in edit mode and
* it takes a couple of minutes to save changes to any archival object within the series
Does anyone else have a similarly large archival object in a resource record? If so, have you observed the same long load/save time when editing the component records?
The slow load time does not seem to be affected by memory allocation; we've tried increasing the speed / size of the server and it seemed to have no effect. We'd definitely appreciate any other suggestions for how we might fix or work around the problem.
We also wonder if this performance issue is essentially caused by the queries being run to generate the UI view - i.e. perhaps in generating the resource 'tree' view, all data for the whole series (all 19k archival objects) is being retrieved and stored in memory? If so, we wondered if it would be possible and would make sense to change the queries running during tree generation, etc. to only retrieve some batches at a time, lazy loading style?
Thanks,
Weatherly and Sally
--
Sally Vermaaten
Project Manager, Archival Systems
New York University Libraries
1-212-992-6259
--
You received this message because you are subscribed to the Google Groups "ArchivesSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archivesspace+unsubscribe at googlegroups.com<mailto:archivesspace+unsubscribe at googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/987641d9/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 15 Nov 2016 19:49:02 +0000
From: Ryan Edwards <REedwards at getty.edu>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>,
"archivesspace at googlegroups.com" <archivesspace at googlegroups.com>
Subject: Re: [Archivesspace_Users_Group] Problems working with
archival object with large number of direct children
Message-ID:
<DM5PR05MB3244D4492CCBD4DE4817C07CBEBF0 at DM5PR05MB3244.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hello Sally,
We?ve also noticed that it can take a while (2-3 minutes) to load one of our largest resources, even after we increased the physical RAM on our server.
-Ryan
Ryan Edwards
Digital Access and Systems Librarian
Getty Research Institute
From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Sally Vermaaten
Sent: Tuesday, November 15, 2016 11:38 AM
To: archivesspace at googlegroups.com; Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children
Hi everyone,
We're running into an issue with a large resource record in ArchivesSpace and wonder if anyone has experienced a similar issue. In one resource record, we have a series/archival object with around 19,000 direct children/archival objects. We've found that:
? it takes several minutes to open the series in the 'tree' navigation view and then, once opened scrolling through series is very slow / laggy
? it takes a couple of minutes to open any archival object in the series in edit mode and
? it takes a couple of minutes to save changes to any archival object within the series
Does anyone else have a similarly large archival object in a resource record? If so, have you observed the same long load/save time when editing the component records?
The slow load time does not seem to be affected by memory allocation; we've tried increasing the speed / size of the server and it seemed to have no effect. We'd definitely appreciate any other suggestions for how we might fix or work around the problem.
We also wonder if this performance issue is essentially caused by the queries being run to generate the UI view - i.e. perhaps in generating the resource 'tree' view, all data for the whole series (all 19k archival objects) is being retrieved and stored in memory? If so, we wondered if it would be possible and would make sense to change the queries running during tree generation, etc. to only retrieve some batches at a time, lazy loading style?
Thanks,
Weatherly and Sally
--
Sally Vermaaten
Project Manager, Archival Systems
New York University Libraries
1-212-992-6259
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/255cb23a/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 15 Nov 2016 15:25:20 -0500
From: Jason Loeffler <j at minorscience.com>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Cc: archivesspace at googlegroups.com
Subject: Re: [Archivesspace_Users_Group] Problems working with
archival object with large number of direct children
Message-ID:
<CAP4gJsW_9wbo6ZvzXAJq1cFaP-CK47hwNow8AEBfa_P5Ffj_iA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sally,
Definitely, yes. We have many resources with 5,000 or more archival object
records. We've deployed on some pretty decent Amazon EC2 boxes (16GB
memory, burstable CPU, etc.) with negligible improvement. I have a feeling
that this is not a resource allocation issue. Looking at the web inspector,
most of the time is spent negotiating jstree <http://jstree.com/> and/or
loading* all JSON objects* associated with a resource into the browser.
Maybe an ASpace dev can weigh in.
>From the sysadmin side, Maureen Callahan at Yale commissioned Percona to
evaluate ArchivesSpace and MySQL performance. I've attached the report. Let
me know if you need any help interpreting the report.
At some point, and quite apart from this thread, I hope we can collectively
revisit the staff interface architecture and recommend improvements.
JL
On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <sally.vermaaten at nyu.edu>
wrote:
> Hi everyone,
>
> We're running into an issue with a large resource record in ArchivesSpace
> and wonder if anyone has experienced a similar issue. In one resource
> record, we have a series/archival object with around 19,000 direct
> children/archival objects. We've found that:
>
> - it takes several minutes to open the series in the 'tree' navigation
> view and then, once opened scrolling through series is very slow / laggy
> - it takes a couple of minutes to open any archival object in the
> series in edit mode and
> - it takes a couple of minutes to save changes to any archival object
> within the series
>
> Does anyone else have a similarly large archival object in a resource
> record? If so, have you observed the same long load/save time when editing
> the component records?
>
> The slow load time does not seem to be affected by memory allocation;
> we've tried increasing the speed / size of the server and it seemed to have
> no effect. We'd definitely appreciate any other suggestions for how we
> might fix or work around the problem.
>
> We also wonder if this performance issue is essentially caused by the
> queries being run to generate the UI view - i.e. perhaps in generating the
> resource 'tree' view, all data for the whole series (all 19k archival
> objects) is being retrieved and stored in memory? If so, we wondered if it
> would be possible and would make sense to change the queries running during
> tree generation, etc. to only retrieve some batches at a time, lazy loading
> style?
>
> Thanks,
> Weatherly and Sally
>
> --
> Sally Vermaaten
> Project Manager, Archival Systems
> New York University Libraries
> 1-212-992-6259
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/41bbc85b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: report.pdf
Type: application/pdf
Size: 81907 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/41bbc85b/attachment-0001.pdf>
------------------------------
Message: 13
Date: Tue, 15 Nov 2016 15:35:06 -0500
From: Jason Loeffler <j at minorscience.com>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Cc: archivesspace at googlegroups.com
Subject: Re: [Archivesspace_Users_Group] Problems working with
archival object with large number of direct children
Message-ID:
<CAP4gJsX8HimVyaPCha-PSfRhRO44erMm9Tv-8AwO-DqrHf3kHA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I should add that application performance was a hot topic in August last
year. Some of the issues described have been mitigated and/or implemented;
others not so much.
http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2015-August/002285.html
http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2015-August/002319.html
http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2015-August/002346.html
On Tue, Nov 15, 2016 at 3:25 PM, Jason Loeffler <j at minorscience.com> wrote:
> Hi Sally,
>
> Definitely, yes. We have many resources with 5,000 or more archival object
> records. We've deployed on some pretty decent Amazon EC2 boxes (16GB
> memory, burstable CPU, etc.) with negligible improvement. I have a feeling
> that this is not a resource allocation issue. Looking at the web inspector,
> most of the time is spent negotiating jstree <http://jstree.com/> and/or
> loading* all JSON objects* associated with a resource into the browser.
> Maybe an ASpace dev can weigh in.
>
> From the sysadmin side, Maureen Callahan at Yale commissioned Percona to
> evaluate ArchivesSpace and MySQL performance. I've attached the report. Let
> me know if you need any help interpreting the report.
>
> At some point, and quite apart from this thread, I hope we can
> collectively revisit the staff interface architecture and recommend
> improvements.
>
> JL
>
> On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <sally.vermaaten at nyu.edu>
> wrote:
>
>> Hi everyone,
>>
>> We're running into an issue with a large resource record in ArchivesSpace
>> and wonder if anyone has experienced a similar issue. In one resource
>> record, we have a series/archival object with around 19,000 direct
>> children/archival objects. We've found that:
>>
>> - it takes several minutes to open the series in the 'tree'
>> navigation view and then, once opened scrolling through series is very slow
>> / laggy
>> - it takes a couple of minutes to open any archival object in the
>> series in edit mode and
>> - it takes a couple of minutes to save changes to any archival object
>> within the series
>>
>> Does anyone else have a similarly large archival object in a resource
>> record? If so, have you observed the same long load/save time when editing
>> the component records?
>>
>> The slow load time does not seem to be affected by memory allocation;
>> we've tried increasing the speed / size of the server and it seemed to have
>> no effect. We'd definitely appreciate any other suggestions for how we
>> might fix or work around the problem.
>>
>> We also wonder if this performance issue is essentially caused by the
>> queries being run to generate the UI view - i.e. perhaps in generating the
>> resource 'tree' view, all data for the whole series (all 19k archival
>> objects) is being retrieved and stored in memory? If so, we wondered if it
>> would be possible and would make sense to change the queries running during
>> tree generation, etc. to only retrieve some batches at a time, lazy loading
>> style?
>>
>> Thanks,
>> Weatherly and Sally
>>
>> --
>> Sally Vermaaten
>> Project Manager, Archival Systems
>> New York University Libraries
>> 1-212-992-6259
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/e441cee3/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 15 Nov 2016 20:46:44 +0000
From: "Joshua D. Shaw" <Joshua.D.Shaw at dartmouth.edu>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Problems working with
archival object with large number of direct children
Message-ID: <44F19B6F-CD13-43C6-A494-92223359C987 at dartmouth.edu>
Content-Type: text/plain; charset="utf-8"
Hi all ?
We at Dartmouth have experienced similar issues. We have some large resources as well (one has 60K+ objects in the tree) and anything that involves a save or rearrangement (moving a file around, etc) can take a *lot* of time (many minutes) and may cause an error ? typically of the ?another user is modifying this record? type.
If we have to do any modifications to a resource of that size, we a) budget a lot of time and b) do things in small increments ? ie don?t move more than a couple of files around at a time. It?s not a great solution, but it does minimize some of the headache.
I *think* (but haven?t had the time to really dig into this) that one reason the error comes about is because the indexer steps on/collides with the process that the save/arrangement kicked off. We are still running 1.3 and hope that some of our issues will be mitigated when we move to 1.5.1, though we know that not all of them have been resolved yet.
One other data point is that we?ve got a plugin that runs as a background job doing a bunch of importing. This background job touches some of the larger resources, but does *not* cause the errors and long save times, which leads me to believe that a lot of the problem is in the frontend ? perhaps with the way the tree is populated - as Jason pointed out.
Best,
Joshua
From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Jason Loeffler <j at minorscience.com>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Date: Tuesday, November 15, 2016 at 3:25 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Cc: "archivesspace at googlegroups.com" <archivesspace at googlegroups.com>
Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children
Hi Sally,
Definitely, yes. We have many resources with 5,000 or more archival object records. We've deployed on some pretty decent Amazon EC2 boxes (16GB memory, burstable CPU, etc.) with negligible improvement. I have a feeling that this is not a resource allocation issue. Looking at the web inspector, most of the time is spent negotiating jstree<http://jstree.com/> and/or loading all JSON objects associated with a resource into the browser. Maybe an ASpace dev can weigh in.
>From the sysadmin side, Maureen Callahan at Yale commissioned Percona to evaluate ArchivesSpace and MySQL performance. I've attached the report. Let me know if you need any help interpreting the report.
At some point, and quite apart from this thread, I hope we can collectively revisit the staff interface architecture and recommend improvements.
JL
On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <sally.vermaaten at nyu.edu<mailto:sally.vermaaten at nyu.edu>> wrote:
Hi everyone,
We're running into an issue with a large resource record in ArchivesSpace and wonder if anyone has experienced a similar issue. In one resource record, we have a series/archival object with around 19,000 direct children/archival objects. We've found that:
? it takes several minutes to open the series in the 'tree' navigation view and then, once opened scrolling through series is very slow / laggy
? it takes a couple of minutes to open any archival object in the series in edit mode and
? it takes a couple of minutes to save changes to any archival object within the series
Does anyone else have a similarly large archival object in a resource record? If so, have you observed the same long load/save time when editing the component records?
The slow load time does not seem to be affected by memory allocation; we've tried increasing the speed / size of the server and it seemed to have no effect. We'd definitely appreciate any other suggestions for how we might fix or work around the problem.
We also wonder if this performance issue is essentially caused by the queries being run to generate the UI view - i.e. perhaps in generating the resource 'tree' view, all data for the whole series (all 19k archival objects) is being retrieved and stored in memory? If so, we wondered if it would be possible and would make sense to change the queries running during tree generation, etc. to only retrieve some batches at a time, lazy loading style?
Thanks,
Weatherly and Sally
--
Sally Vermaaten
Project Manager, Archival Systems
New York University Libraries
1-212-992-6259<tel:1-212-992-6259>
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/f1ff16f0/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 16 Nov 2016 10:17:37 +1100
From: James Bullen <james at hudmol.com>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>,
archivesspace at googlegroups.com
Subject: Re: [Archivesspace_Users_Group] Problems working with
archival object with large number of direct children
Message-ID: <404DE50A-B8DD-4A4D-B14A-FDDED5B64D57 at hudmol.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
As part of our new role as ArchivesSpace development partner, we will be addressing issues like this as a priority.
It is still early days and we?re working with the folks at the ArchivesSpace program on a release schedule, so we can?t make any definitive statements yet, but please know that we are aware of this issue and will address it as soon as we are able.
Cheers,
James
?
James Bullen
Hudson Molonglo
> On Nov 16, 2016, at 7:46 AM, Joshua D. Shaw <Joshua.D.Shaw at dartmouth.edu> wrote:
>
> Hi all ?
>
> We at Dartmouth have experienced similar issues. We have some large resources as well (one has 60K+ objects in the tree) and anything that involves a save or rearrangement (moving a file around, etc) can take a *lot* of time (many minutes) and may cause an error ? typically of the ?another user is modifying this record? type.
>
> If we have to do any modifications to a resource of that size, we a) budget a lot of time and b) do things in small increments ? ie don?t move more than a couple of files around at a time. It?s not a great solution, but it does minimize some of the headache.
>
> I *think* (but haven?t had the time to really dig into this) that one reason the error comes about is because the indexer steps on/collides with the process that the save/arrangement kicked off. We are still running 1.3 and hope that some of our issues will be mitigated when we move to 1.5.1, though we know that not all of them have been resolved yet.
>
> One other data point is that we?ve got a plugin that runs as a background job doing a bunch of importing. This background job touches some of the larger resources, but does *not* cause the errors and long save times, which leads me to believe that a lot of the problem is in the frontend ? perhaps with the way the tree is populated - as Jason pointed out.
>
> Best,
> Joshua
>
> From: <archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Jason Loeffler <j at minorscience.com <mailto:j at minorscience.com>>
> Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org>>
> Date: Tuesday, November 15, 2016 at 3:25 PM
> To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org>>
> Cc: "archivesspace at googlegroups.com <mailto:archivesspace at googlegroups.com>" <archivesspace at googlegroups.com <mailto:archivesspace at googlegroups.com>>
> Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children
>
> Hi Sally,
>
> Definitely, yes. We have many resources with 5,000 or more archival object records. We've deployed on some pretty decent Amazon EC2 boxes (16GB memory, burstable CPU, etc.) with negligible improvement. I have a feeling that this is not a resource allocation issue. Looking at the web inspector, most of the time is spent negotiating jstree <http://jstree.com/> and/or loading all JSON objects associated with a resource into the browser. Maybe an ASpace dev can weigh in.
>
>
> From the sysadmin side, Maureen Callahan at Yale commissioned Percona to evaluate ArchivesSpace and MySQL performance. I've attached the report. Let me know if you need any help interpreting the report.
>
> At some point, and quite apart from this thread, I hope we can collectively revisit the staff interface architecture and recommend improvements.
>
> JL
>
> On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <sally.vermaaten at nyu.edu <mailto:sally.vermaaten at nyu.edu>> wrote:
>> Hi everyone,
>>
>> We're running into an issue with a large resource record in ArchivesSpace and wonder if anyone has experienced a similar issue. In one resource record, we have a series/archival object with around 19,000 direct children/archival objects. We've found that:
>> ? it takes several minutes to open the series in the 'tree' navigation view and then, once opened scrolling through series is very slow / laggy
>> ? it takes a couple of minutes to open any archival object in the series in edit mode and
>> ? it takes a couple of minutes to save changes to any archival object within the series
>> Does anyone else have a similarly large archival object in a resource record? If so, have you observed the same long load/save time when editing the component records?
>>
>> The slow load time does not seem to be affected by memory allocation; we've tried increasing the speed / size of the server and it seemed to have no effect. We'd definitely appreciate any other suggestions for how we might fix or work around the problem.
>>
>> We also wonder if this performance issue is essentially caused by the queries being run to generate the UI view - i.e. perhaps in generating the resource 'tree' view, all data for the whole series (all 19k archival objects) is being retrieved and stored in memory? If so, we wondered if it would be possible and would make sense to change the queries running during tree generation, etc. to only retrieve some batches at a time, lazy loading style?
>>
>> Thanks,
>> Weatherly and Sally
>>
>> --
>> Sally Vermaaten
>> Project Manager, Archival Systems
>> New York University Libraries
>> 1-212-992-6259 <tel:1-212-992-6259>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>
> !DSPAM:582b7444314351074817778! _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>
>
> !DSPAM:582b7444314351074817778!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/4054a705/attachment-0001.html>
------------------------------
Message: 16
Date: Tue, 15 Nov 2016 18:28:44 -0500
From: Jason Loeffler <j at minorscience.com>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Cc: archivesspace at googlegroups.com
Subject: Re: [Archivesspace_Users_Group] Problems working with
archival object with large number of direct children
Message-ID:
<CAP4gJsVcnku_79ParxD4j-s88z7-6G8HdywDRHRZwVWWM_RMBw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks so much, James. Can you tell me if there's a script available for
generating an arbitrary number of test records? Something similar to
Drupal's devel generate <https://api.drupal.org/api/devel/functions/8.x-1.x>
hooks?
Jason Loeffler
Technology Consultant | The American Academy in Rome
Minor Science | Application Development & Metadata Strategy
Brooklyn, New York
jason at minorscience.com
(347) 405-0826
minorscience (Skype)
On Tue, Nov 15, 2016 at 6:17 PM, James Bullen <james at hudmol.com> wrote:
>
> Hi all,
>
> As part of our new role as ArchivesSpace development partner, we will be
> addressing issues like this as a priority.
>
> It is still early days and we?re working with the folks at the
> ArchivesSpace program on a release schedule, so we can?t make any
> definitive statements yet, but please know that we are aware of this issue
> and will address it as soon as we are able.
>
>
> Cheers,
> James
>
>
> ?
> James Bullen
> Hudson Molonglo
>
>
>
> On Nov 16, 2016, at 7:46 AM, Joshua D. Shaw <Joshua.D.Shaw at dartmouth.edu>
> wrote:
>
> Hi all ?
>
> We at Dartmouth have experienced similar issues. We have some large
> resources as well (one has 60K+ objects in the tree) and anything that
> involves a save or rearrangement (moving a file around, etc) can take a *
> *lot** of time (many minutes) and may cause an error ? typically of the
> ?another user is modifying this record? type.
>
> If we have to do any modifications to a resource of that size, we a)
> budget a lot of time and b) do things in small increments ? ie don?t move
> more than a couple of files around at a time. It?s not a great solution,
> but it does minimize some of the headache.
>
> I **think** (but haven?t had the time to really dig into this) that one
> reason the error comes about is because the indexer steps on/collides with
> the process that the save/arrangement kicked off. We are still running 1.3
> and hope that some of our issues will be mitigated when we move to 1.5.1,
> though we know that not all of them have been resolved yet.
>
> One other data point is that we?ve got a plugin that runs as a background
> job doing a bunch of importing. This background job touches some of the
> larger resources, but does **not** cause the errors and long save times,
> which leads me to believe that a lot of the problem is in the frontend ?
> perhaps with the way the tree is populated - as Jason pointed out.
>
> Best,
> Joshua
>
> *From: *<archivesspace_users_group-bounces at lyralists.lyrasis.org> on
> behalf of Jason Loeffler <j at minorscience.com>
> *Reply-To: *Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Date: *Tuesday, November 15, 2016 at 3:25 PM
> *To: *Archivesspace Users Group <archivesspace_users_group@
> lyralists.lyrasis.org>
> *Cc: *"archivesspace at googlegroups.com" <archivesspace at googlegroups.com>
> *Subject: *Re: [Archivesspace_Users_Group] Problems working with archival
> object with large number of direct children
>
> Hi Sally,
>
> Definitely, yes. We have many resources with 5,000 or more archival object
> records. We've deployed on some pretty decent Amazon EC2 boxes (16GB
> memory, burstable CPU, etc.) with negligible improvement. I have a feeling
> that this is not a resource allocation issue. Looking at the web inspector,
> most of the time is spent negotiating jstree <http://jstree.com/> and/or
> loading* all JSON objects* associated with a resource into the browser.
> Maybe an ASpace dev can weigh in.
>
>
> From the sysadmin side, Maureen Callahan at Yale commissioned Percona to
> evaluate ArchivesSpace and MySQL performance. I've attached the report. Let
> me know if you need any help interpreting the report.
>
> At some point, and quite apart from this thread, I hope we can
> collectively revisit the staff interface architecture and recommend
> improvements.
>
> JL
>
> On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <sally.vermaaten at nyu.edu>
> wrote:
>
> Hi everyone,
>
> We're running into an issue with a large resource record in ArchivesSpace
> and wonder if anyone has experienced a similar issue. In one resource
> record, we have a series/archival object with around 19,000 direct
> children/archival objects. We've found that:
> ? it takes several minutes to open the series in the 'tree'
> navigation view and then, once opened scrolling through series is very slow
> / laggy
> ? it takes a couple of minutes to open any archival object in the
> series in edit mode and
> ? it takes a couple of minutes to save changes to any archival
> object within the series
> Does anyone else have a similarly large archival object in a resource
> record? If so, have you observed the same long load/save time when editing
> the component records?
>
> The slow load time does not seem to be affected by memory allocation;
> we've tried increasing the speed / size of the server and it seemed to have
> no effect. We'd definitely appreciate any other suggestions for how we
> might fix or work around the problem.
>
> We also wonder if this performance issue is essentially caused by the
> queries being run to generate the UI view - i.e. perhaps in generating the
> resource 'tree' view, all data for the whole series (all 19k archival
> objects) is being retrieved and stored in memory? If so, we wondered if it
> would be possible and would make sense to change the queries running during
> tree generation, etc. to only retrieve some batches at a time, lazy loading
> style?
>
> Thanks,
> Weatherly and Sally
>
> --
> Sally Vermaaten
> Project Manager, Archival Systems
> New York University Libraries
> 1-212-992-6259
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
> !DSPAM:582b7444314351074817778! ___________________________________
> ____________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
> !DSPAM:582b7444314351074817778!
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/129b5b6e/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 16 Nov 2016 10:56:38 +1100
From: James Bullen <james at hudmol.com>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Cc: archivesspace at googlegroups.com
Subject: Re: [Archivesspace_Users_Group] Problems working with
archival object with large number of direct children
Message-ID: <E1A76F49-19CF-4743-A5A9-523FDC5DA155 at hudmol.com>
Content-Type: text/plain; charset="utf-8"
Hi Jason - I?m not aware of a script like this. Cheers ? James
> On Nov 16, 2016, at 10:28 AM, Jason Loeffler <j at minorscience.com> wrote:
>
> Thanks so much, James. Can you tell me if there's a script available for generating an arbitrary number of test records? Something similar to Drupal's devel generate <https://api.drupal.org/api/devel/functions/8.x-1.x> hooks?
>
> Jason Loeffler
> Technology Consultant | The American Academy in Rome
> Minor Science | Application Development & Metadata Strategy
> Brooklyn, New York
> jason at minorscience.com <mailto:jason at minorscience.com>
> (347) 405-0826
> minorscience (Skype)
>
>
>
> On Tue, Nov 15, 2016 at 6:17 PM, James Bullen <james at hudmol.com <mailto:james at hudmol.com>> wrote:
>
> Hi all,
>
> As part of our new role as ArchivesSpace development partner, we will be addressing issues like this as a priority.
>
> It is still early days and we?re working with the folks at the ArchivesSpace program on a release schedule, so we can?t make any definitive statements yet, but please know that we are aware of this issue and will address it as soon as we are able.
>
>
> Cheers,
> James
>
>
> ?
> James Bullen
> Hudson Molonglo
>
>
>
>> On Nov 16, 2016, at 7:46 AM, Joshua D. Shaw <Joshua.D.Shaw at dartmouth.edu <mailto:Joshua.D.Shaw at dartmouth.edu>> wrote:
>>
>> Hi all ?
>>
>> We at Dartmouth have experienced similar issues. We have some large resources as well (one has 60K+ objects in the tree) and anything that involves a save or rearrangement (moving a file around, etc) can take a *lot* of time (many minutes) and may cause an error ? typically of the ?another user is modifying this record? type.
>>
>> If we have to do any modifications to a resource of that size, we a) budget a lot of time and b) do things in small increments ? ie don?t move more than a couple of files around at a time. It?s not a great solution, but it does minimize some of the headache.
>>
>> I *think* (but haven?t had the time to really dig into this) that one reason the error comes about is because the indexer steps on/collides with the process that the save/arrangement kicked off. We are still running 1.3 and hope that some of our issues will be mitigated when we move to 1.5.1, though we know that not all of them have been resolved yet.
>>
>> One other data point is that we?ve got a plugin that runs as a background job doing a bunch of importing. This background job touches some of the larger resources, but does *not* cause the errors and long save times, which leads me to believe that a lot of the problem is in the frontend ? perhaps with the way the tree is populated - as Jason pointed out.
>>
>> Best,
>> Joshua
>>
>> From: <archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Jason Loeffler <j at minorscience.com <mailto:j at minorscience.com>>
>> Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org>>
>> Date: Tuesday, November 15, 2016 at 3:25 PM
>> To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org>>
>> Cc: "archivesspace at googlegroups.com <mailto:archivesspace at googlegroups.com>" <archivesspace at googlegroups.com <mailto:archivesspace at googlegroups.com>>
>> Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children
>>
>> Hi Sally,
>>
>> Definitely, yes. We have many resources with 5,000 or more archival object records. We've deployed on some pretty decent Amazon EC2 boxes (16GB memory, burstable CPU, etc.) with negligible improvement. I have a feeling that this is not a resource allocation issue. Looking at the web inspector, most of the time is spent negotiating jstree <http://jstree.com/> and/or loading all JSON objects associated with a resource into the browser. Maybe an ASpace dev can weigh in.
>>
>>
>> From the sysadmin side, Maureen Callahan at Yale commissioned Percona to evaluate ArchivesSpace and MySQL performance. I've attached the report. Let me know if you need any help interpreting the report.
>>
>> At some point, and quite apart from this thread, I hope we can collectively revisit the staff interface architecture and recommend improvements.
>>
>> JL
>>
>> On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <sally.vermaaten at nyu.edu <mailto:sally.vermaaten at nyu.edu>> wrote:
>>> Hi everyone,
>>>
>>> We're running into an issue with a large resource record in ArchivesSpace and wonder if anyone has experienced a similar issue. In one resource record, we have a series/archival object with around 19,000 direct children/archival objects. We've found that:
>>> ? it takes several minutes to open the series in the 'tree' navigation view and then, once opened scrolling through series is very slow / laggy
>>> ? it takes a couple of minutes to open any archival object in the series in edit mode and
>>> ? it takes a couple of minutes to save changes to any archival object within the series
>>> Does anyone else have a similarly large archival object in a resource record? If so, have you observed the same long load/save time when editing the component records?
>>>
>>> The slow load time does not seem to be affected by memory allocation; we've tried increasing the speed / size of the server and it seemed to have no effect. We'd definitely appreciate any other suggestions for how we might fix or work around the problem.
>>>
>>> We also wonder if this performance issue is essentially caused by the queries being run to generate the UI view - i.e. perhaps in generating the resource 'tree' view, all data for the whole series (all 19k archival objects) is being retrieved and stored in memory? If so, we wondered if it would be possible and would make sense to change the queries running during tree generation, etc. to only retrieve some batches at a time, lazy loading style?
>>>
>>> Thanks,
>>> Weatherly and Sally
>>>
>>> --
>>> Sally Vermaaten
>>> Project Manager, Archival Systems
>>> New York University Libraries
>>> 1-212-992-6259 <tel:1-212-992-6259>
>>>
>>> _______________________________________________
>>> Archivesspace_Users_Group mailing list
>>> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
>>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>>
>> wbr>582b7444314351074817778! _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>>
>>
>> !DSPAM:582b7444314351074817778!
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>
>
> !DSPAM:582b9a4b138833087816299! _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>
>
> !DSPAM:582b9a4b138833087816299!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/7b414b69/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 16 Nov 2016 00:47:14 +0000
From: "Gadsby, Eric T." <egadsby at towson.edu>
To: "archivesspace_users_group at lyralists.lyrasis.org"
<archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] A user who is set as manager of a
collection can not create containers...
Message-ID: <52B9DEC3-08BD-43F0-ABCC-0DA6A4AB4BA4 at towson.edu>
Content-Type: text/plain; charset="utf-8"
I posted this to the list earlier but the list seems more active this week so I thought I?d try again. One of ouse users is manger of a collection but can?t create containers in it here is what they report:
?While attempting to create top containers for instances, I only had access to ?browse? but not create. I had management level access at the time. I had to be given admin level access to be able to gain the create button for top containers. The create option disappeared when placed on just admin level access. I had to be placed in both levels of access to be able to create top containers.?
Our server has only been in production for a few weeks and is set-up per the http://www.archivesspace.org recommendations. Our server does authenticate via LDAP (Active Directory) but our users experience is the same using an AD or ArchivesSpace local users. Do you know how we might resolve this or what might be the next steps in troubleshooting? Thanks!
Sincerely,
Eric T Gadsby
IT Operations Specialist, Cook Library
Towson University
egadsby at towson.edu<mailto:egadsby at towson.edu>
410-704-3340
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/2170c700/attachment-0001.html>
------------------------------
Message: 19
Date: Wed, 16 Nov 2016 02:10:52 +0000 (UTC)
From: Jason Loeffler <j at minorscience.com>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Cc: archivesspace at googlegroups.com
Subject: Re: [Archivesspace_Users_Group] Problems working with
archival object with large number of direct children
Message-ID:
<E0903B9C708FD3BF.5EEE58AA-F43D-496F-AA20-9F8755C27EEE at mail.outlook.com>
Content-Type: text/plain; charset="utf-8"
Thanks, James. Just wondering if there's a load test battery for a large dataset. I can generate a large dataset if you think it is useful for your work.?
On Tue, Nov 15, 2016 at 6:56 PM -0500, "James Bullen" <james at hudmol.com> wrote:
Hi Jason - I?m not aware of a script like this. ?Cheers ? James
On Nov 16, 2016, at 10:28 AM, Jason Loeffler <j at minorscience.com> wrote:
Thanks so much, James. Can you tell me if there's a script available for generating an arbitrary number of test records? Something similar to Drupal's devel?generate?hooks?
Jason LoefflerTechnology Consultant |?The American Academy in RomeMinor Science | Application Development & Metadata StrategyBrooklyn, New Yorkjason at minorscience.com(347) 405-0826minorscience (Skype)
On Tue, Nov 15, 2016 at 6:17 PM, James Bullen?<james at hudmol.com>?wrote:
Hi all,
As part of our new role as ArchivesSpace development partner, we will be addressing issues like this as a priority.
It is still early days and we?re working with the folks at the ArchivesSpace program on a release schedule, so we can?t make any definitive statements yet, but please know that we are aware of this issue and will address it as soon as we are able.
Cheers,James
?James BullenHudson Molonglo
On Nov 16, 2016, at 7:46 AM, Joshua D. Shaw <Joshua.D.Shaw at dartmouth.edu> wrote:
Hi all ??We at Dartmouth have experienced similar issues. We have some large resources as well (one has 60K+ objects in the tree) and anything that involves a save or rearrangement (moving a file around, etc) can take a *lot* of time (many minutes) and may cause an error ? typically of the ?another user is modifying this record? type.?If we have to do any modifications to a resource of that size, we a) budget a lot of time and b) do things in small increments ? ie don?t move more than a couple of files around at a time. It?s not a great solution, but it does minimize some of the headache.?I *think* (but haven?t had the time to really dig into this) that one reason the error comes about is because the indexer steps on/collides with the process that the save/arrangement kicked off. We are still running 1.3 and hope that some of our issues will be mitigated when we move to 1.5.1, though we know that not all of them have been resolved yet.?One other data point is that we?ve got !
a plugin
that runs as a background job doing a bunch of importing. This background job touches some of the larger resources, but does *not* cause the errors and long save times, which leads me to believe that a lot of the problem is in the frontend ? perhaps with the way the tree is populated - as Jason pointed out.?Best,Joshua?From:?<archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Jason Loeffler <j at minorscience.com>
Reply-To:?Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Date:?Tuesday, November 15, 2016 at 3:25 PM
To:?Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Cc:?"archivesspace at googlegroups.com" <archivesspace at googlegroups.com>
Subject:?Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children?Hi Sally,?Definitely, yes. We have many resources with 5,000 or more archival object records. We've deployed on some pretty decent Amazon EC2 boxes (16GB memory, burstable CPU, etc.) with negligible improvement. I have a feeling that this is not a resource allocation issue. Looking at the web inspector, most of the time is spent negotiating?jstree?and/or loading?all JSON objects?associated with a resource into the browser. Maybe an ASpace dev can weigh in.
>From the sysadmin side, Maureen Callahan at Yale commissioned Percona to evaluate ArchivesSpace and MySQL performance. I've attached the report. Let me know if you need any help interpreting the report.?At some point, and quite apart from this thread, I hope we can collectively revisit the staff interface architecture and recommend improvements.??JL?On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <sally.vermaaten at nyu.edu> wrote:Hi everyone,?We're running into an issue with a large resource record in ArchivesSpace and wonder if anyone has experienced a similar issue.?In one resource record, we have a series/archival object with around 19,000 direct children/archival objects. We've found that: ???????????it takes several minutes to open the series in the 'tree' navigation view and then, once opened scrolling through series is very slow / laggy??????????it takes a couple of minutes to open any archival object in the series in edit mode and???????????it takes a couple of minut!
es to sav
e changes to any archival object within the seriesDoes anyone else have a similarly large archival object in a resource record? If so, have you observed the same long load/save time when editing the component records???The slow load time does not seem to be affected by memory allocation; we've tried increasing the speed / size of the server and it seemed to have no effect. We'd definitely appreciate any other suggestions for how we might fix or work around the problem.?We also wonder if this performance issue is essentially caused by the queries being run to generate the UI view - i.e. perhaps in generating the resource 'tree' view, all data for the whole series (all 19k archival objects) is being retrieved and stored in memory? If so, we wondered if it would be possible and would make sense to change the queries running during tree generation, etc. to only retrieve some batches at a time, lazy loading style???Thanks,Weatherly?and Sally?--?Sally Vermaaten
Project Manager, Archival Systems
New York University Libraries1-212-992-6259
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group?wbr>582b7444314351074817778!?_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
!DSPAM:582b7444314351074817778!
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
!DSPAM:582b9a4b138833087816299! _______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
!DSPAM:582b9a4b138833087816299!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/272967ce/attachment-0001.html>
------------------------------
Message: 20
Date: Wed, 16 Nov 2016 13:34:17 +1100
From: James Bullen <james at hudmol.com>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Cc: archivesspace at googlegroups.com
Subject: Re: [Archivesspace_Users_Group] Problems working with
archival object with large number of direct children
Message-ID: <6C7D60FD-2AA6-447C-A55A-19BCC2433E49 at hudmol.com>
Content-Type: text/plain; charset="utf-8"
That could be useful thanks Jason. Cheers ? James
> On Nov 16, 2016, at 1:10 PM, Jason Loeffler <j at minorscience.com> wrote:
>
>
> Thanks, James. Just wondering if there's a load test battery for a large dataset. I can generate a large dataset if you think it is useful for your work.
>
>
>
>
> On Tue, Nov 15, 2016 at 6:56 PM -0500, "James Bullen" <james at hudmol.com <mailto:james at hudmol.com>> wrote:
>
>
> Hi Jason - I?m not aware of a script like this. Cheers ? James
>
>
>> On Nov 16, 2016, at 10:28 AM, Jason Loeffler <j at minorscience.com <mailto:j at minorscience.com>> wrote:
>>
>> Thanks so much, James. Can you tell me if there's a script available for generating an arbitrary number of test records? Something similar to Drupal's devel generate <https://api.drupal.org/api/devel/functions/8.x-1.x> hooks?
>>
>> Jason Loeffler
>> Technology Consultant | The American Academy in Rome
>> Minor Science | Application Development & Metadata Strategy
>> Brooklyn, New York
>> jason at minorscience.com <mailto:jason at minorscience.com>
>> (347) 405-0826
>> minorscience (Skype)
>>
>>
>>
>> On Tue, Nov 15, 2016 at 6:17 PM, James Bullen <james at hudmol.com <mailto:james at hudmol.com>> wrote:
>>
>> Hi all,
>>
>> As part of our new role as ArchivesSpace development partner, we will be addressing issues like this as a priority.
>>
>> It is still early days and we?re working with the folks at the ArchivesSpace program on a release schedule, so we can?t make any definitive statements yet, but please know that we are aware of this issue and will address it as soon as we are able.
>>
>>
>> Cheers,
>> James
>>
>>
>> ?
>> James Bullen
>> Hudson Molonglo
>>
>>
>>
>>> On Nov 16, 2016, at 7:46 AM, Joshua D. Shaw <Joshua.D.Shaw at dartmouth.edu <mailto:Joshua.D.Shaw at dartmouth.edu>> wrote:
>>>
>>> Hi all ?
>>>
>>> We at Dartmouth have experienced similar issues. We have some large resources as well (one has 60K+ objects in the tree) and anything that involves a save or rearrangement (moving a file around, etc) can take a *lot* of time (many minutes) and may cause an error ? typically of the ?another user is modifying this record? type.
>>>
>>> If we have to do any modifications to a resource of that size, we a) budget a lot of time and b) do things in small increments ? ie don?t move more than a couple of files around at a time. It?s not a great solution, but it does minimize some of the headache.
>>>
>>> I *think* (but haven?t had the time to really dig into this) that one reason the error comes about is because the indexer steps on/collides with the process that the save/arrangement kicked off. We are still running 1.3 and hope that some of our issues will be mitigated when we move to 1.5.1, though we know that not all of them have been resolved yet.
>>>
>>> One other data point is that we?ve got a plugin that runs as a background job doing a bunch of importing. This background job touches some of the larger resources, but does *not* cause the errors and long save times, which leads me to believe that a lot of the problem is in the frontend ? perhaps with the way the tree is populated - as Jason pointed out.
>>>
>>> Best,
>>> Joshua
>>>
>>> From: <archivesspace_users_group-bounces at lyralists.lyrasis.org <mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Jason Loeffler <j at minorscience.com <mailto:j at minorscience.com>>
>>> Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org>>
>>> Date: Tuesday, November 15, 2016 at 3:25 PM
>>> To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org <mailto:archivesspace_users_group at lyralists.lyrasis.org>>
>>> Cc: "archivesspace at googlegroups.com <mailto:archivesspace at googlegroups.com>" <archivesspace at googlegroups.com <mailto:archivesspace at googlegroups.com>>
>>> Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children
>>>
>>> Hi Sally,
>>>
>>> Definitely, yes. We have many resources with 5,000 or more archival object records. We've deployed on some pretty decent Amazon EC2 boxes (16GB memory, burstable CPU, etc.) with negligible improvement. I have a feeling that this is not a resource allocation issue. Looking at the web inspector, most of the time is spent negotiating jstree <http://jstree.com/> and/or loading all JSON objects associated with a resource into the browser. Maybe an ASpace dev can weigh in.
>>>
>>>
>>> From the sysadmin side, Maureen Callahan at Yale commissioned Percona to evaluate ArchivesSpace and MySQL performance. I've attached the report. Let me know if you need any help interpreting the report.
>>>
>>> At some point, and quite apart from this thread, I hope we can collectively revisit the staff interface architecture and recommend improvements.
>>>
>>> JL
>>>
>>> On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <sally.vermaaten at nyu.edu <mailto:sally.vermaaten at nyu.edu>> wrote:
>>>> Hi everyone,
>>>>
>>>> We're running into an issue with a large resource record in ArchivesSpace and wonder if anyone has experienced a similar issue. In one resource record, we have a series/archival object with around 19,000 direct children/archival objects. We've found that:
>>>> ? it takes several minutes to open the series in the 'tree' navigation view and then, once opened scrolling through series is very slow / laggy
>>>> ? it takes a couple of minutes to open any archival object in the series in edit mode and
>>>> ? it takes a couple of minutes to save changes to any archival object within the series
>>>> Does anyone else have a similarly large archival object in a resource record? If so, have you observed the same long load/save time when editing the component records?
>>>>
>>>> The slow load time does not seem to be affected by memory allocation; we've tried increasing the speed / size of the server and it seemed to have no effect. We'd definitely appreciate any other suggestions for how we might fix or work around the problem.
>>>>
>>>> We also wonder if this performance issue is essentially caused by the queries being run to generate the UI view - i.e. perhaps in generating the resource 'tree' view, all data for the whole series (all 19k archival objects) is being retrieved and stored in memory? If so, we wondered if it would be possible and would make sense to change the queries running during tree generation, etc. to only retrieve some batches at a time, lazy loading style?
>>>>
>>>> Thanks,
>>>> Weatherly and Sally
>>>>
>>>> --
>>>> Sally Vermaaten
>>>> Project Manager, Archival Systems
>>>> New York University Libraries
>>>> 1-212-992-6259 <tel:1-212-992-6259>
>>>>
>>>> _______________________________________________
>>>> Archivesspace_Users_Group mailing list
>>>> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
>>>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>>>
>>> wbr>582b7444314351074817778! _______________________________________________
>>> Archivesspace_Users_Group mailing list
>>> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
>>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>>>
>>>
>>> wbr class="">582b7444314351074817778!
>>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>>
>>
>> !DSPAM:582b9a4b138833087816299! _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
>>
>>
>> !DSPAM:582b9a4b138833087816299!
>
> !DSPAM:582bc03b277649809715286!
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
> !DSPAM:582bc03b277649809715286!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/da104852/attachment-0001.html>
------------------------------
Message: 21
Date: Wed, 16 Nov 2016 18:20:26 +1100
From: Payten Giles <payten at paytengiles.com>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] A user who is set as manager
of a collection can not create containers...
Message-ID: <etPan.582c08d8.50b81168.1fc at paytengiles.com>
Content-Type: text/plain; charset="utf-8"
Hi there Eric,
Access to the ?Create? for containers is provided by the?update_container_record role. ?It looks like this isn?t granted to managers (repository-managers) by default. ?This has a bug vibe and I?ll ensure a JIRA issue is recorded.
In the meantime, you can expand the roles available to your repository managers by following these steps:
1. Login as an administrator
2. Ensure the repository you?d like to update is selected
3. Under the ?cog? icon next to the repository name, select "Manage Groups?
4. Select ?Edit? next to the?repository-managers group
5. Under ?Members can?, ensure the checkbox for "create/update top container records? is selected
6. Save Group
Hopefully the ?Create? action will now be available!
Thanks,
Payten
On 16 November 2016 at 11:47:21 AM, Gadsby, Eric T. (egadsby at towson.edu) wrote:
I posted this to the list earlier but the list seems more active this week so I thought I?d try again. One of ouse users is manger of a collection but can?t create containers in it here is what they report:?
?While attempting to create top containers for instances, I only had access to ?browse? but not create. I had management level access at the time. I had to be given admin level access to be able to gain the create button for top containers. The create option disappeared when placed on just admin level access. I had to be placed in both levels of access to be able to create top containers.??
Our server has only been in production for a few weeks and is set-up per the?http://www.archivesspace.org?recommendations. Our server does authenticate via LDAP (Active Directory) but our users experience is the same using an AD or ArchivesSpace local users. Do you know how we might resolve this or what might be the next steps in troubleshooting? Thanks!?
Sincerely,
Eric T Gadsby
IT Operations Specialist, Cook Library
Towson University
egadsby at towson.edu
410-704-3340 _______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/21a11577/attachment-0001.html>
------------------------------
Message: 22
Date: Wed, 16 Nov 2016 04:05:24 -0300
From: Payten Giles <payten.giles at gmail.com>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] A user who is set as manager
of a collection can not create containers...
Message-ID:
<CAFwQ+jR8UXQ=pjX=itikO8uLe3Nb8NjXwuT=N_p4m5ib8q7h0Q at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi there Eric,
Access to the ?Create? for containers is provided by
the update_container_record role. It looks like this isn?t granted to
managers (repository-managers) by default. This has a bug vibe and I?ll
ensure a JIRA issue is recorded.
In the meantime, you can expand the roles available to your repository
managers by following these steps:
1. Login as an administrator
2. Ensure the repository you?d like to update is selected
3. Under the ?cog? icon next to the repository name, select "Manage Groups?
4. Select ?Edit? next to the repository-managers group
5. Under ?Members can?, ensure the checkbox for "create/update top
container records? is selected
6. Save Group
Hopefully the ?Create? action will now be available!
Thanks,
Payten
On 16 November 2016 at 11:47:21 AM, Gadsby, Eric T. (egadsby at towson.edu)
wrote:
I posted this to the list earlier but the list seems more active this week
so I thought I?d try again. One of ouse users is manger of a collection but
can?t create containers in it here is what they report:
?While attempting to create top containers for instances, I only had access
to ?browse? but not create. I had management level access at the time. I
had to be given admin level access to be able to gain the create button for
top containers. The create option disappeared when placed on just admin
level access. I had to be placed in both levels of access to be able to
create top containers.?
Our server has only been in production for a few weeks and is set-up per
the http://www.archivesspace.org recommendations. Our server does
authenticate via LDAP (Active Directory) but our users experience is the
same using an AD or ArchivesSpace local users. Do you know how we might
resolve this or what might be the next steps in troubleshooting? Thanks!
Sincerely,
Eric T Gadsby
IT Operations Specialist, Cook Library
Towson University
egadsby at towson.edu
410-704-3340 _______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/f0e12ee0/attachment-0001.html>
------------------------------
Message: 23
Date: Wed, 16 Nov 2016 12:32:22 +0000
From: "Gadsby, Eric T." <egadsby at towson.edu>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] A user who is set as manager
of a collection can not create containers...
Message-ID: <BF16D65B-B14C-4FA1-9201-01E90D88934A at towson.edu>
Content-Type: text/plain; charset="utf-8"
Payten,
Thanks I will have the users try that and report back. Thanks for your help!
Sincerely,
Eric T Gadsby
IT Operations Specialist, Cook Library
Towson University
egadsby at towson.edu<mailto:egadsby at towson.edu>
410-704-3340
On Nov 16, 2016, at 2:20 AM, Payten Giles <payten at paytengiles.com<mailto:payten at paytengiles.com>> wrote:
Hi there Eric,
Access to the ?Create? for containers is provided by the update_container_record role. It looks like this isn?t granted to managers (repository-managers) by default. This has a bug vibe and I?ll ensure a JIRA issue is recorded.
In the meantime, you can expand the roles available to your repository managers by following these steps:
1. Login as an administrator
2. Ensure the repository you?d like to update is selected
3. Under the ?cog? icon next to the repository name, select "Manage Groups?
4. Select ?Edit? next to the repository-managers group
5. Under ?Members can?, ensure the checkbox for "create/update top container records? is selected
6. Save Group
Hopefully the ?Create? action will now be available!
Thanks,
Payten
On 16 November 2016 at 11:47:21 AM, Gadsby, Eric T. (egadsby at towson.edu<mailto:egadsby at towson.edu>) wrote:
I posted this to the list earlier but the list seems more active this week so I thought I?d try again. One of ouse users is manger of a collection but can?t create containers in it here is what they report:
?While attempting to create top containers for instances, I only had access to ?browse? but not create. I had management level access at the time. I had to be given admin level access to be able to gain the create button for top containers. The create option disappeared when placed on just admin level access. I had to be placed in both levels of access to be able to create top containers.?
Our server has only been in production for a few weeks and is set-up per the http://www.archivesspace.org<http://www.archivesspace.org/> recommendations. Our server does authenticate via LDAP (Active Directory) but our users experience is the same using an AD or ArchivesSpace local users. Do you know how we might resolve this or what might be the next steps in troubleshooting? Thanks!
Sincerely,
Eric T Gadsby
IT Operations Specialist, Cook Library
Towson University
egadsby at towson.edu<mailto:egadsby at towson.edu>
410-704-3340 _______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/2077c8ae/attachment-0001.html>
------------------------------
Message: 24
Date: Wed, 16 Nov 2016 12:45:33 +0000
From: "Joshua D. Shaw" <Joshua.D.Shaw at dartmouth.edu>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Problems working with
archival object with large number of direct children
Message-ID: <F590EE90-5FE4-45CE-B225-409D33546282 at dartmouth.edu>
Content-Type: text/plain; charset="utf-8"
Thanks, James!
For the rest of the list, especially those who haven?t had a chance to work with James and the rest of the gang at HM, we?ve had nothing but great work on the customizations we?ve had done. All by way of saying that if James says they are gonna fix it? it?ll be fixed!
Joshua
From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of James Bullen <james at hudmol.com>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Date: Tuesday, November 15, 2016 at 6:17 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>, "archivesspace at googlegroups.com" <archivesspace at googlegroups.com>
Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children
Hi all,
As part of our new role as ArchivesSpace development partner, we will be addressing issues like this as a priority.
It is still early days and we?re working with the folks at the ArchivesSpace program on a release schedule, so we can?t make any definitive statements yet, but please know that we are aware of this issue and will address it as soon as we are able.
Cheers,
James
?
James Bullen
Hudson Molonglo
On Nov 16, 2016, at 7:46 AM, Joshua D. Shaw <Joshua.D.Shaw at dartmouth.edu<mailto:Joshua.D.Shaw at dartmouth.edu>> wrote:
Hi all ?
We at Dartmouth have experienced similar issues. We have some large resources as well (one has 60K+ objects in the tree) and anything that involves a save or rearrangement (moving a file around, etc) can take a *lot* of time (many minutes) and may cause an error ? typically of the ?another user is modifying this record? type.
If we have to do any modifications to a resource of that size, we a) budget a lot of time and b) do things in small increments ? ie don?t move more than a couple of files around at a time. It?s not a great solution, but it does minimize some of the headache.
I *think* (but haven?t had the time to really dig into this) that one reason the error comes about is because the indexer steps on/collides with the process that the save/arrangement kicked off. We are still running 1.3 and hope that some of our issues will be mitigated when we move to 1.5.1, though we know that not all of them have been resolved yet.
One other data point is that we?ve got a plugin that runs as a background job doing a bunch of importing. This background job touches some of the larger resources, but does *not* cause the errors and long save times, which leads me to believe that a lot of the problem is in the frontend ? perhaps with the way the tree is populated - as Jason pointed out.
Best,
Joshua
From: <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Jason Loeffler <j at minorscience.com<mailto:j at minorscience.com>>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Date: Tuesday, November 15, 2016 at 3:25 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Cc: "archivesspace at googlegroups.com<mailto:archivesspace at googlegroups.com>" <archivesspace at googlegroups.com<mailto:archivesspace at googlegroups.com>>
Subject: Re: [Archivesspace_Users_Group] Problems working with archival object with large number of direct children
Hi Sally,
Definitely, yes. We have many resources with 5,000 or more archival object records. We've deployed on some pretty decent Amazon EC2 boxes (16GB memory, burstable CPU, etc.) with negligible improvement. I have a feeling that this is not a resource allocation issue. Looking at the web inspector, most of the time is spent negotiating jstree<http://jstree.com/> and/or loading all JSON objects associated with a resource into the browser. Maybe an ASpace dev can weigh in.
>From the sysadmin side, Maureen Callahan at Yale commissioned Percona to evaluate ArchivesSpace and MySQL performance. I've attached the report. Let me know if you need any help interpreting the report.
At some point, and quite apart from this thread, I hope we can collectively revisit the staff interface architecture and recommend improvements.
JL
On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <sally.vermaaten at nyu.edu<mailto:sally.vermaaten at nyu.edu>> wrote:
Hi everyone,
We're running into an issue with a large resource record in ArchivesSpace and wonder if anyone has experienced a similar issue. In one resource record, we have a series/archival object with around 19,000 direct children/archival objects. We've found that:
? it takes several minutes to open the series in the 'tree' navigation view and then, once opened scrolling through series is very slow / laggy
? it takes a couple of minutes to open any archival object in the series in edit mode and
? it takes a couple of minutes to save changes to any archival object within the series
Does anyone else have a similarly large archival object in a resource record? If so, have you observed the same long load/save time when editing the component records?
The slow load time does not seem to be affected by memory allocation; we've tried increasing the speed / size of the server and it seemed to have no effect. We'd definitely appreciate any other suggestions for how we might fix or work around the problem.
We also wonder if this performance issue is essentially caused by the queries being run to generate the UI view - i.e. perhaps in generating the resource 'tree' view, all data for the whole series (all 19k archival objects) is being retrieved and stored in memory? If so, we wondered if it would be possible and would make sense to change the queries running during tree generation, etc. to only retrieve some batches at a time, lazy loading style?
Thanks,
Weatherly and Sally
--
Sally Vermaaten
Project Manager, Archival Systems
New York University Libraries
1-212-992-6259<tel:1-212-992-6259>
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
!DSPAM:582b7444314351074817778! _______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
!DSPAM:582b7444314351074817778!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/bf10e9c2/attachment-0001.html>
------------------------------
Message: 25
Date: Wed, 16 Nov 2016 14:40:17 +0000
From: Yvonne Kester <ykester at skidmore.edu>
To: Archivesspace Users Group
<archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] A user who is set as manager
of a collection can not create containers...
Message-ID:
<BN1PR0101MB0865718BA7101988449621A9C7BE0 at BN1PR0101MB0865.prod.exchangelabs.com>
Content-Type: text/plain; charset="utf-8"
Hi Eric,
We had a problem creating top containers a couple months ago. This is the answer I got from Christine:
?There is a permission that needs to be added for the permission group that your user account is part of in order for you to create top containers. See the three options for containers below; there is also one for the new location profile functionality. Have your system administrator (or someone who otherwise has privileges that allow them to manage users) add any permissions you need to your permission group.
[cid:image001.png at 01D23FED.6E85D7B0]
(There?s information about managing users and permission groups in the manual at http://docs.archivesspace.org/Default.htm#UserPermGroupsManage.htm )
I hope this helps!
Yvonne
From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Gadsby, Eric T.
Sent: Tuesday, November 15, 2016 7:47 PM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] A user who is set as manager of a collection can not create containers...
I posted this to the list earlier but the list seems more active this week so I thought I?d try again. One of ouse users is manger of a collection but can?t create containers in it here is what they report:
?While attempting to create top containers for instances, I only had access to ?browse? but not create. I had management level access at the time. I had to be given admin level access to be able to gain the create button for top containers. The create option disappeared when placed on just admin level access. I had to be placed in both levels of access to be able to create top containers.?
Our server has only been in production for a few weeks and is set-up per the http://www.archivesspace.org recommendations. Our server does authenticate via LDAP (Active Directory) but our users experience is the same using an AD or ArchivesSpace local users. Do you know how we might resolve this or what might be the next steps in troubleshooting? Thanks!
Sincerely,
Eric T Gadsby
IT Operations Specialist, Cook Library
Towson University
egadsby at towson.edu<mailto:egadsby at towson.edu>
410-704-3340
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/bfbb5215/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 20851 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/bfbb5215/attachment.png>
------------------------------
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
End of Archivesspace_Users_Group Digest, Vol 40, Issue 2
********************************************************
More information about the Archivesspace_Users_Group
mailing list