[Archivesspace_Users_Group] FW: Archivesspace_Users_Group Digest, Vol 40, Issue 2
Jason Loeffler
j at minorscience.com
Fri Dec 2 12:28:13 EST 2016
Hi Greta,
There's a JIRA story here
<https://archivesspace.atlassian.net/browse/AR-1002?filter=11600> that
describes the issue.
It is in the backlog for our development partner, Hudson Molonglo. The fix
will not appear in the next release. We'll work to get it addressed in a
future release. Keep an eye on JIRA for activity on this issue.
Let me know if you have any questions.
Best, Jason
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 Fri, Dec 2, 2016 at 12:16 PM, Greta Kuriger Suiter <gsuiter at mit.edu>
wrote:
> 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:archivesspa
> ce_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:a
> rchivesspace_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:A
> rchivesspace_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:archivesspa
> ce_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:a
> rchivesspace_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:A
> rchivesspace_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@
> 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+8KKyfw9yeNkkmBvADKtfbWHSzRGXV8
> 598eDsWMBgkg 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=AQFVXEmfHf0
> 31MF3dvA 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:archiv
> esspace+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@
> 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<
> 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:A
> rchivesspace_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@
> 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@
> lyralists.lyrasis.org <mailto:archivesspace_users_
> group at lyralists.lyrasis.org>>
> > Cc: "archivesspace at googlegroups.com <mailto:archivesspace@
> googlegroups.com>" <archivesspace at googlegroups.com <mailto:archivesspace@
> 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@
> 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@
> lyralists.lyrasis.org <mailto:archivesspace_users_
> group at lyralists.lyrasis.org>>
> >> Cc: "archivesspace at googlegroups.com <mailto:archivesspace@
> googlegroups.com>" <archivesspace at googlegroups.com <mailto:archivesspace@
> 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@
> 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@
> 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?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@
> 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@
> lyralists.lyrasis.org <mailto:archivesspace_users_
> group at lyralists.lyrasis.org>>
> >>> Cc: "archivesspace at googlegroups.com <mailto:archivesspace@
> googlegroups.com>" <archivesspace at googlegroups.com <mailto:archivesspace@
> 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:A
> rchivesspace_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:A
> rchivesspace_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@
> lyralists.lyrasis.org>
> Date: Tuesday, November 15, 2016 at 6:17 PM
> To: Archivesspace Users Group <archivesspace_users_group@
> 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@
> lyralists.lyrasis.org<mailto: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<mailto:archivesspace_users_group@
> 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:A
> rchivesspace_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:A
> rchivesspace_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
> ********************************************************
> _______________________________________________
> 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/20161202/1a59ffa7/attachment-0001.html>
More information about the Archivesspace_Users_Group
mailing list