From Jessica.Crouch at lyrasis.org Mon May 2 10:09:55 2022 From: Jessica.Crouch at lyrasis.org (Jessica Crouch) Date: Mon, 2 May 2022 14:09:55 +0000 Subject: [Archivesspace_Users_Group] Upcoming Webinar: Using ArchivesSpace to create EAC-CPF records (90 minutes) In-Reply-To: <699EEA2C-4D25-4A19-8DB6-27C4BC2CD451@lyrasis.org> References: <699EEA2C-4D25-4A19-8DB6-27C4BC2CD451@lyrasis.org> Message-ID: Dear ArchivesSpace users, The next ArchivesSpace webinar will be a 90-minute learning opportunity on May 24th at 2:00pm ET/11:00am PT led by Regine Heberlein, Library IT Data Analyst at Princeton University, and Christine Di Bella, ArchivesSpace Program Manager, demonstrating how to create valid EAC-CPF records using ArchivesSpace and offering some tips and tricks for making the process easier within your repository. Originally scheduled for February 9th, this 90 minute learning opportunity has been postponed to May 24, 2022, at 2:00pm ET/11:00am PT. If you?ve already registered for this webinar, your registration has been transferred to this new date. If you need to cancel your registration, you can do so using the connection information provided via Zoom. Date: May 24, 2022 Time: 2:00pm ? 3:30pm ET (11:00am ? 12:30pm PT) Where: Zoom Registration: https://lyrasis.zoom.us/webinar/register/WN_e777kyjtQ6qjBMWeiiTWmg This webinar will be recorded and made available on the ArchivesSpace YouTube channel. Webinar description: The recent expansion of the agents module in ArchivesSpace greatly expanded the application?s support for the metadata standard Encoded Archival Context ? Corporate Bodies, Persons, and Families (EAC-CPF) and the potential for exchanging these records with other systems, including Social Networks and Archival Context (SNAC). Taking full advantage of this potential requires some work on the record creator?s part as ArchivesSpace?s requirements for creating agent records remain minimal. This learning opportunity will demonstrate how to create valid EAC-CPF records using ArchivesSpace and offer some tips and tricks for making the process easier within your repository. An open discussion and Q&A will follow. This learning opportunity introduces EAC-CPF in the context of ArchivesSpace but is not intended to be a full overview of the standard. Resources for learning more about EAC-CPF include: * Encoded Archival Standards: A Primer: https://www.youtube.com/watch?v=WYWQeBRnhz0 * EAC-CPF Community and Support page: https://eac.staatsbibliothek-berlin.de/community-and-mailinglist/ * EAC-CPF Tag Library: https://eac.staatsbibliothek-berlin.de/schemata-and-tag-library/ NOTE: This learning opportunity assumes basic knowledge of ArchivesSpace, including an understanding of agent records. If you do not have this, we recommend watching the videos of the Basics workshop series, available on YouTube at https://www.youtube.com/playlist?list=PL3cxupmXL7WiHyMc0uFmsCEIVOQmrI7FL. We will not be able to answer general questions about ArchivesSpace or specific questions about individual ArchivesSpace implementations during this session. Who should attend: Anyone interested in using ArchivesSpace to create valid EAC-CPF records. Please email ArchivesSpaceHome at lyrasis.org if you have any questions. Best, Jessica Jessica Dowd Crouch Community Engagement Coordinator for ArchivesSpace jessica.crouch at lyrasis.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.morrison at bodleian.ox.ac.uk Tue May 3 03:45:53 2022 From: andrew.morrison at bodleian.ox.ac.uk (Andrew Morrison) Date: Tue, 3 May 2022 08:45:53 +0100 Subject: [Archivesspace_Users_Group] Auto spacing in Notes field In-Reply-To: References: Message-ID: You could try this: https://www.loc.gov/ead/tglib/elements/lb.html Andrew. On 30/04/2022 03:52, ?? ??? wrote: > > Could we make line breaks in a Notes-Text filed without using br-tag? > > If any alternative doesn?t work, could we eliminate the brs which > automatically appear and create an unnecessary blank when formatted? > > Thanks, > > Hitomi Matsuyama, Audiovisual Archivist > > Nakanoshima Museum of Art, Osaka > > 4-3-1 Nakanoshima, Kita-ku > > Osaka 530-0005 JAPAN > > tel. +81 (0)6 64 79 05 58 > > email. matsuyama-h at nakka-art.jp > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjackson at hallieqbrown.org Tue May 3 14:24:53 2022 From: kjackson at hallieqbrown.org (Kayla Jackson) Date: Tue, 3 May 2022 18:24:53 +0000 Subject: [Archivesspace_Users_Group] IP address restrictions for volunteer users Message-ID: Hello All, I wanted to know if I am overlooking a feature in Archives Space to implement restrictions on where a volunteer can log into ArchivesSpace. I am trying to prevent volunteers from accessing our instance from their home computers, or any other terminal that's not on site. Thank you for any clarity you all can give. Sincerely, Kayla Kayla Jackson (she/her) Hallie Q. Brown Community Center Project Archivist 270 N. Kent Street? kjackson at hallieqbrown.org 651-224-4605 ext. 126 [cid:fc6453b8-0476-4ac5-86f3-ac3e0b20db3d] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Outlook-h1ruphp0.jpg Type: image/jpeg Size: 170064 bytes Desc: Outlook-h1ruphp0.jpg URL: From sdm7g at virginia.edu Tue May 3 15:11:50 2022 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Tue, 3 May 2022 19:11:50 +0000 Subject: [Archivesspace_Users_Group] IP address restrictions for volunteer users In-Reply-To: References: Message-ID: ArchivesSpace does not have a feature to implement those sort of intranet restrictions. Usually, that is done by server firewall (like iptables) or set in proxy server config (Apache). > On May 3, 2022, at 2:24 PM, Kayla Jackson wrote: > > Hello All, > > I wanted to know if I am overlooking a feature in Archives Space to implement restrictions on where a volunteer can log into ArchivesSpace. > > I am trying to prevent volunteers from accessing our instance from their home computers, or any other terminal that's not on site. > > Thank you for any clarity you all can give. > > Sincerely, > Kayla > > Kayla Jackson (she/her) > Hallie Q. Brown Community Center > Project Archivist > 270 N. Kent Street? > kjackson at hallieqbrown.org > 651-224-4605 ext. 126 > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3342 bytes Desc: not available URL: From christine.dibella at lyrasis.org Thu May 5 09:53:13 2022 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Thu, 5 May 2022 13:53:13 +0000 Subject: [Archivesspace_Users_Group] no Take a Break with ArchivesSpace on May 6 Message-ID: Due to other staff commitments, ArchivesSpace will not be hosting a Friday break this week. (Though we encourage you to take your own break!) We plan to resume on Friday, May 13. Christine Christine Di Bella ArchivesSpace Program Manager christine.dibella at lyrasis.org 800.999.8558 x2905 678-235-2905 [ASpaceOrgHomeMedium] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 13904 bytes Desc: image001.jpg URL: From jcross at clemson.edu Mon May 9 09:17:22 2022 From: jcross at clemson.edu (James E. Cross) Date: Mon, 9 May 2022 13:17:22 +0000 Subject: [Archivesspace_Users_Group] Question regarding Related Agents General relationship type Message-ID: I am working on instructions for using ArchivesSpace and a question has come up regarding the General relationship type in the Related Agents section of Agents. Can anyone point me to any definitions or use standards for the General relationship types in ArchivesSpace? Previous versions had definitions of the various relationships but that appears to be no longer true. I know that the types are based on the @cpfRelationType attribute values for the Relations element in EAC-CPF; I have looked at the documentation for the standard but do not any definitions for those values. Some appear to be relatively straightforward and are likely the same as in previous versions (e.g., Earlier/Later), but there are others that are not so clear. When would I use the Identity type, or the Temporal (instead of Earlier/Later)? Does Hierarchical fully replace Subordinate/Superior or if I wish to preserve the specific nature of the relationship information in the latter would I use Parent/Child? Is the Associative type still used mainly for officers of an organization or has it broadened out to any kind of "association?" Any help you can provide would be greatly appreciated. Thank you. Jim Cross Manuscripts Archivist James Edward Cross, C.A. CLEMSON UNIVERSITY Manuscripts Archivist Special Collections and Archives Clemson University Libraries Box 343001 Clemson, SC 29634-3001 Phone: (864) 656-5182 Website: http://library.clemson.edu/depts/specialcollections/ Pronouns: he/him/his Traditional Cherokee Lands | Site of Fort Hill Plantation Please do not feel obligated to respond to this message outside of your normal working hours. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benefiea at gvsu.edu Mon May 9 12:52:34 2022 From: benefiea at gvsu.edu (Annie Benefiel) Date: Mon, 9 May 2022 16:52:34 +0000 Subject: [Archivesspace_Users_Group] Reminder: Register for the ArchivesSpace Governance Board-Community Session Message-ID: Dear ArchivesSpace Community, The ArchivesSpace Governance Board once again invites you to an open community engagement session on Friday, May 27, 2022, 11 am- noon eastern time (find your local time). Join us to get to know the current board members and learn more about governance and decision making at ArchivesSpace. The session will provide an overview of the ArchivesSpace governance model, highlight recent board initiatives, and give participants an opportunity to interact with the board and their representatives. We welcome all members to join us with questions you might have about ArchivesSpace sustainability, governance, or opportunities for strengthening the community. Register to join at https://lyrasis.zoom.us/meeting/register/tZUkcOCqpjMtGNYQZrJ8ZUpY5Qm8Bv9zrtka Looking forward to seeing you, Annie Benefiel ArchivesSpace Governance Board, Medium membership level representative University Archivist and Digital Collections Librarian Grand Valley State University -------------- next part -------------- An HTML attachment was scrubbed... URL: From hanstra at nd.edu Tue May 10 10:23:21 2022 From: hanstra at nd.edu (Tom Hanstra) Date: Tue, 10 May 2022 10:23:21 -0400 Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Message-ID: I don't look at the logs a lot unless there are issues with ArchivesSpace, so maybe this is something normal. But, after a restart due to some complaints about database connectivity, it looks like our ArchivesSpace instance has decided to do a full reindex. The index log sure looks as if it is starting from scratch and running through the indexing of both PUI and Staff indexes. Is this possible? Is it something that happens periodically and I just did not notice it? Nothing has changed in my data directory, so I don't see any reason for indexing to occur. Yet that is what the logs show. If it is doing this for some reason, and knowing that we restart periodically, it seems like we will get into a loop where indexing just keeps happening all the time. Also, it would be helpful to understand what caused this to happen. Any thoughts or experiences from those who have run this for longer would be appreciated. I'd like to understand if it would be a good idea to clear the data directory and perform a full index over the weekend rather than an unexpected and possibly never ending round in the background. Thanks, Tom -- *Tom Hanstra* *Sr. Systems Administrator* hanstra at nd.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From Corey.Schmidt at uga.edu Tue May 10 13:09:04 2022 From: Corey.Schmidt at uga.edu (Corey Schmidt) Date: Tue, 10 May 2022 17:09:04 +0000 Subject: [Archivesspace_Users_Group] find_by_id/resources API Documentation Help Message-ID: Dear all, Hello, this is Corey from the University of Georgia. I hope everyone is well, staying healthy, and getting lots of sunshine! Would anyone be able to help me write a couple of documentation examples for the find_by_id/resources API endpoint? Specifically, I need help with making a SHELL example and an example using an ARK to find a resource. I've already submitted a Python example for this endpoint, but I don't have access to any ARK IDs to test and I cannot figure out how to parse the identifier parameter in SHELL. Any help would be greatly appreciated! I'm available in the Archivists Working with Archival Data slack server if that is a better communication method. Thanks, Corey Corey Schmidt Special Collections Libraries | Project Management Librarian/Archivist 300 S Hull St | Athens, GA 30605 Corey.Schmidt at uga.edu [University of Georgia] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 8920 bytes Desc: image001.png URL: From blake.carver at lyrasis.org Tue May 10 14:17:16 2022 From: blake.carver at lyrasis.org (Blake Carver) Date: Tue, 10 May 2022 18:17:16 +0000 Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 In-Reply-To: References: Message-ID: > Is this possible? Short answer, Yes, it's possible your indexer is starting over. Long answer. This can be tricky to figure out. Something is wrong, the indexer never wants to do that. Sometimes "something" "bad" gets into ArchivesSpace and the indexer will just crash and start over. The problem is the "something" can be anything and the "bad" can be hard to figure out. The more stuff you have in your DB, the harder it is to figure out. First, I'd make sure this is happening. Your logs should make it obvious. You might see some FATAL errors just before it starts over. You MIGHT be able to narrow it down from that. That is, what group of records had that error in the logs? Maybe that narrows it down enough. You just got lucky! I don't think I've ever been so lucky. What I'd do next is set your loglevel to DEBUG and restart. If you're feeling lucky or just impatient or both, leave the indexer speed as is. You'll get more details out of the logs and you should be able to narrow it down better. Ideally, you want to run the indexers at 1x1, which means it could take forrreeevverrrrr to get back around to the crash again. If you're lucky, it'll crash on a record, you'll go look at that record, the problem will be obvious, and there will be much rejoicing. With it running 1x1 you should see exactly what's causing the fail. If it's not crashing on the same record every time.... ugh. That's an even longer answer. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Tom Hanstra Sent: Tuesday, May 10, 2022 10:23 AM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 I don't look at the logs a lot unless there are issues with ArchivesSpace, so maybe this is something normal. But, after a restart due to some complaints about database connectivity, it looks like our ArchivesSpace instance has decided to do a full reindex. The index log sure looks as if it is starting from scratch and running through the indexing of both PUI and Staff indexes. Is this possible? Is it something that happens periodically and I just did not notice it? Nothing has changed in my data directory, so I don't see any reason for indexing to occur. Yet that is what the logs show. If it is doing this for some reason, and knowing that we restart periodically, it seems like we will get into a loop where indexing just keeps happening all the time. Also, it would be helpful to understand what caused this to happen. Any thoughts or experiences from those who have run this for longer would be appreciated. I'd like to understand if it would be a good idea to clear the data directory and perform a full index over the weekend rather than an unexpected and possibly never ending round in the background. Thanks, Tom -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hanstra at nd.edu Tue May 10 16:15:21 2022 From: hanstra at nd.edu (Tom Hanstra) Date: Tue, 10 May 2022 16:15:21 -0400 Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 In-Reply-To: References: Message-ID: Thanks, Blake. Turns out we did add quite a few records recently, so maybe there was something in there that it did not like all that much. How can you tell which record it is choking on? Is that your "1x1" suggestion? Or does the DEBUG option make that more clear? I have my indexing set to: AppConfig[:indexer_records_per_thread] = 25 AppConfig[:indexer_thread_count] = 2 for both PUI and Staff records. I believe you are suggesting it would most easily be found using 1 and 1? I can see where that could take a long time. But it if is going to choke over and over on the same record, then that may be the best way to address it. Do you think if I just did staff indexing without PUI, that it would be identified faster? Or could it pass the staff side but then die on PUI later? I hope to try some of these ideas after hours today, so if you can confirm that I've got the right idea, that would help. Tom On Tue, May 10, 2022 at 2:17 PM Blake Carver wrote: > > Is this possible? > > Short answer, Yes, it's possible your indexer is starting over. > > Long answer. This can be tricky to figure out. Something is wrong, the > indexer never wants to do that. Sometimes "something" "bad" gets into > ArchivesSpace and the indexer will just crash and start over. The problem > is the "something" can be anything and the "bad" can be hard to figure out. > The more stuff you have in your DB, the harder it is to figure out. > > First, I'd make sure this is happening. Your logs should make it obvious. > You might see some FATAL errors just before it starts over. You MIGHT be > able to narrow it down from that. That is, what group of records had that > error in the logs? Maybe that narrows it down enough. You just got lucky! > > I don't think I've ever been so lucky. What I'd do next is set your > loglevel to DEBUG and restart. If you're feeling lucky or just impatient or > both, leave the indexer speed as is. You'll get more details out of the > logs and you should be able to narrow it down better. Ideally, you want to > run the indexers at 1x1, which means it could take forrreeevverrrrr to get > back around to the crash again. If you're lucky, it'll crash on a record, > you'll go look at that record, the problem will be obvious, and there will > be much rejoicing. With it running 1x1 you should see exactly what's > causing the fail. If it's not crashing on the same record every time.... > ugh. That's an even longer answer. > > > > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Tom > Hanstra > *Sent:* Tuesday, May 10, 2022 10:23 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > I don't look at the logs a lot unless there are issues with ArchivesSpace, > so maybe this is something normal. But, after a restart due to some > complaints about database connectivity, it looks like our ArchivesSpace > instance has decided to do a full reindex. The index log sure looks as if > it is starting from scratch and running through the indexing of both PUI > and Staff indexes. > > Is this possible? Is it something that happens periodically and I just > did not notice it? Nothing has changed in my data directory, so I don't see > any reason for indexing to occur. Yet that is what the logs show. > > If it is doing this for some reason, and knowing that we restart > periodically, it seems like we will get into a loop where indexing just > keeps happening all the time. Also, it would be helpful to understand what > caused this to happen. > > Any thoughts or experiences from those who have run this for longer would > be appreciated. I'd like to understand if it would be a good idea to clear > the data directory and perform a full index over the weekend rather than an > unexpected and possibly never ending round in the background. > > Thanks, > Tom > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -- *Tom Hanstra* *Sr. Systems Administrator* hanstra at nd.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake.carver at lyrasis.org Tue May 10 17:06:07 2022 From: blake.carver at lyrasis.org (Blake Carver) Date: Tue, 10 May 2022 21:06:07 +0000 Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 In-Reply-To: References: Message-ID: 1x1 would mean setting both records_per_thread and thread_count to 1. Having loglevel on debug and running at 1x1, you'll be able to see exactly which thing is being indexed as it happens, and when it crashes, you'll see what it was working through at the time. PUI will always take longer, and a VERY long time 1x1, but unless you're sure which indexer is crashing, I'd switch them both up. You can just `grep Indexed archivesspace.out` after it's running and watch those numbers. As long as they're going up, all is well. It is also possible that it will finish without crashing running so slow as well. I've seen that happen with LARGE records. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Tom Hanstra Sent: Tuesday, May 10, 2022 4:15 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Thanks, Blake. Turns out we did add quite a few records recently, so maybe there was something in there that it did not like all that much. How can you tell which record it is choking on? Is that your "1x1" suggestion? Or does the DEBUG option make that more clear? I have my indexing set to: AppConfig[:indexer_records_per_thread] = 25 AppConfig[:indexer_thread_count] = 2 for both PUI and Staff records. I believe you are suggesting it would most easily be found using 1 and 1? I can see where that could take a long time. But it if is going to choke over and over on the same record, then that may be the best way to address it. Do you think if I just did staff indexing without PUI, that it would be identified faster? Or could it pass the staff side but then die on PUI later? I hope to try some of these ideas after hours today, so if you can confirm that I've got the right idea, that would help. Tom On Tue, May 10, 2022 at 2:17 PM Blake Carver > wrote: > Is this possible? Short answer, Yes, it's possible your indexer is starting over. Long answer. This can be tricky to figure out. Something is wrong, the indexer never wants to do that. Sometimes "something" "bad" gets into ArchivesSpace and the indexer will just crash and start over. The problem is the "something" can be anything and the "bad" can be hard to figure out. The more stuff you have in your DB, the harder it is to figure out. First, I'd make sure this is happening. Your logs should make it obvious. You might see some FATAL errors just before it starts over. You MIGHT be able to narrow it down from that. That is, what group of records had that error in the logs? Maybe that narrows it down enough. You just got lucky! I don't think I've ever been so lucky. What I'd do next is set your loglevel to DEBUG and restart. If you're feeling lucky or just impatient or both, leave the indexer speed as is. You'll get more details out of the logs and you should be able to narrow it down better. Ideally, you want to run the indexers at 1x1, which means it could take forrreeevverrrrr to get back around to the crash again. If you're lucky, it'll crash on a record, you'll go look at that record, the problem will be obvious, and there will be much rejoicing. With it running 1x1 you should see exactly what's causing the fail. If it's not crashing on the same record every time.... ugh. That's an even longer answer. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Tuesday, May 10, 2022 10:23 AM To: Archivesspace Users Group > Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 I don't look at the logs a lot unless there are issues with ArchivesSpace, so maybe this is something normal. But, after a restart due to some complaints about database connectivity, it looks like our ArchivesSpace instance has decided to do a full reindex. The index log sure looks as if it is starting from scratch and running through the indexing of both PUI and Staff indexes. Is this possible? Is it something that happens periodically and I just did not notice it? Nothing has changed in my data directory, so I don't see any reason for indexing to occur. Yet that is what the logs show. If it is doing this for some reason, and knowing that we restart periodically, it seems like we will get into a loop where indexing just keeps happening all the time. Also, it would be helpful to understand what caused this to happen. Any thoughts or experiences from those who have run this for longer would be appreciated. I'd like to understand if it would be a good idea to clear the data directory and perform a full index over the weekend rather than an unexpected and possibly never ending round in the background. Thanks, Tom -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] -------------- next part -------------- An HTML attachment was scrubbed... URL: From matsuyama-h at nakka-art.jp Wed May 11 03:37:01 2022 From: matsuyama-h at nakka-art.jp (=?utf-8?B?5p2+5bGx44CA44Gy44Go44G/?=) Date: Wed, 11 May 2022 07:37:01 +0000 Subject: [Archivesspace_Users_Group] PUI Ordering and Sorting Issue In-Reply-To: <2ad2fbff-4c25-a1cb-01fc-6e9fff4858c9@bodleian.ox.ac.uk> References: <9a86da8a-d6e9-1595-0a1b-e5dab408010d@bodleian.ox.ac.uk> <2ad2fbff-4c25-a1cb-01fc-6e9fff4858c9@bodleian.ox.ac.uk> Message-ID: Hello, again. We?ve tried as Andrew kindly suggested. However, it didn?t work as well as expected? We think using ?clean_for_sort; IndexerCommon? may interfere when ?title? is set to ?title_sort?. ?clean_for_sort? looks eliminating anything except alphabets and numbers when sorting. It would affect not only Japanese character but also any non-alphabet characters, such as Hangul or Cyrillic, we suppose. We also wonder what order is applied when ?title_sort? is empty. [?????? ???? ????????, ????, ???????? ???????????] [?????? ???? ????????, ????, ????????, ??? ???????????] Thanks, Hitomi Hitomi Matsuyama, Audiovisual Archivist Nakanoshima Museum of Art, Osaka 4-3-1 Nakanoshima, Kita-ku Osaka 530-0005 JAPAN tel. +81 (0)6 64 79 05 58 email. matsuyama-h at nakka-art.jp From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Andrew Morrison Sent: Thursday, April 28, 2022 8:46 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: Re: [Archivesspace_Users_Group] PUI Ordering and Sorting Issue I forgot to mention that you probably have to re-index after changing schema.xml and reloading the core. Andrew. On 28/04/2022 10:51, ?? ??? wrote: Thanks again Andrew! We?ll try applying what you gave to our current AS. Hitomi From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Andrew Morrison Sent: Thursday, April 28, 2022 6:09 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: Re: [Archivesspace_Users_Group] PUI Ordering and Sorting Issue If you're using the schema.xml that came with ArchivesSpace 3.0.1 in your external Solr 8.11, then it will still define the "sort_icu" fieldType as an instance of the solr.TextField class. If you look below that, there is a commented-out alternative fieldType definition which is an instance of solr.ICUCollationField. ArchivesSpace 3.2.0 has changed to that (because it no longer has to support the previously-built-in Solr 4.10) but you don't need to upgrade to it, you can just edit your schema.xml, then reload the Solr core. See the link in my previous email for help on how to set that up to be optimized for Japanese characters. Andrew. On 28/04/2022 09:44, ?? ??? wrote: Thank you Andrew! Our IT says we?ve already been using an external Solr 8.11 with ArchivesSpace 3.0.1, not the one built-in. We?re thinking of upgrading our AS to 3.2.0. Do you think we will get a better result? Hitomi From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Andrew Morrison Sent: Thursday, April 28, 2022 4:47 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: Re: [Archivesspace_Users_Group] PUI Ordering and Sorting Issue Are you using the built-in Solr search engine that comes with ArchivesSpace 3.0.1? If so, your sorting problems could be because it uses a very old version, because newer ones aren't compatible with the method of embedding it in a bigger application. But there is the option to configure ArchivesSpace to use an external Solr service: https://archivesspace.github.io/tech-docs/provisioning/solr.html That allows you to run a more up-to-date version, which would enable use of the solr.ICUCollationField class for sort fields. That can be adjusted to sort different languages according to their own sorting rules, as described here: https://solr.apache.org/guide/8_11/language-analysis.html#unicode-collation ArchivesSpace 3.2.0 removes the built-in Solr, so running an external Solr service will be necessary if you upgrade in the future. As for adding the option to sort on identifiers, I don't think there is a configuration option or simple interface for adding them. But it would probably be possible to develop a plug-in to override certain Ruby methods in the core code to do it. Andrew. On 27/04/2022 11:04, ?? ??? wrote: Hello all, We?ve been stuck in the ?ordering and sorting? issue in [~/repositories/resources]. Our AS is version 3.0.1. Presumably, because we use Japanese Character, our resource list cannot be displayed in a right, alphabetical order when sorted by Title. Could we add Identifier to the category of sorting; Relevance/Title(Asc/Desc)/Year(Asc/Desc), as alternative? We?d very much appreciate you helping solve our issue! All the best, Hitomi Matsuyama, Audiovisual Archivist Nakanoshima Museum of Art, Osaka 4-3-1 Nakanoshima, Kita-ku Osaka 530-0005 JAPAN tel. +81 (0)6 64 79 05 58 email. matsuyama-h at nakka-art.jp _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 114725 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 33989 bytes Desc: image002.png URL: From matsuyama-h at nakka-art.jp Wed May 11 03:41:26 2022 From: matsuyama-h at nakka-art.jp (=?utf-8?B?5p2+5bGx44CA44Gy44Go44G/?=) Date: Wed, 11 May 2022 07:41:26 +0000 Subject: [Archivesspace_Users_Group] Auto spacing in Notes field In-Reply-To: References: Message-ID: Thank you, Andrew! It?s rather easy and worked. Hitomi From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Andrew Morrison Sent: Tuesday, May 3, 2022 4:46 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: Re: [Archivesspace_Users_Group] Auto spacing in Notes field You could try this: https://www.loc.gov/ead/tglib/elements/lb.html Andrew. On 30/04/2022 03:52, ?? ??? wrote: Could we make line breaks in a Notes-Text filed without using br-tag? If any alternative doesn?t work, could we eliminate the brs which automatically appear and create an unnecessary blank when formatted? Thanks, Hitomi Matsuyama, Audiovisual Archivist Nakanoshima Museum of Art, Osaka 4-3-1 Nakanoshima, Kita-ku Osaka 530-0005 JAPAN tel. +81 (0)6 64 79 05 58 email. matsuyama-h at nakka-art.jp -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.morrison at bodleian.ox.ac.uk Wed May 11 04:53:46 2022 From: andrew.morrison at bodleian.ox.ac.uk (Andrew Morrison) Date: Wed, 11 May 2022 09:53:46 +0100 Subject: [Archivesspace_Users_Group] PUI Ordering and Sorting Issue In-Reply-To: References: <9a86da8a-d6e9-1595-0a1b-e5dab408010d@bodleian.ox.ac.uk> <2ad2fbff-4c25-a1cb-01fc-6e9fff4858c9@bodleian.ox.ac.uk> Message-ID: <46de3426-b3dd-89be-b103-41cb66012d28@bodleian.ox.ac.uk> I'd forgotten about clean_for_sort. I've overridden it myself, in a plug-in. The simplest way is: 1. In plugins/local, create a subfolder called "indexer" 2. Create a file in that subfolder called "indexer_common_override.rb" 3. In the file, declare "class IndexerCommon" 4. Copy the def for clean_for_sort into that, and adjust it to meet your requirements. 5. Restart and re-index. Something like: [^\p{L}\s] Would be a less anglocentric substitute for: [^\w\s] If that works, you probably won't have any empty title_sort values, but in general you can control the sorting of records without values in schema.xml with the sortMissingLast attribute, see: https://solr.apache.org/guide/8_8/field-type-definitions-and-properties.html Andrew. On 11/05/2022 08:37, ?? ??? wrote: > > Hello, again. > > We?ve tried as Andrew kindly suggested. > > However, it didn?t work as well as expected? > > We think using ?clean_for_sort; IndexerCommon? may interfere when > ?title? is set to ?title_sort?. > > ?clean_for_sort? looks eliminating anything except alphabets and > numbers when sorting. > > It would affect not only Japanese character but also any non-alphabet > characters, such as Hangul or Cyrillic, we suppose. > > We also wonder what order is applied when ?title_sort? is empty. > > > > Thanks, > > Hitomi > > Hitomi Matsuyama, Audiovisual Archivist > > Nakanoshima Museum of Art, Osaka > > 4-3-1 Nakanoshima, Kita-ku > > Osaka 530-0005 JAPAN > > tel. +81 (0)6 64 79 05 58 > > email. matsuyama-h at nakka-art.jp > > *From:*archivesspace_users_group-bounces at lyralists.lyrasis.org > *On Behalf > Of *Andrew Morrison > *Sent:* Thursday, April 28, 2022 8:46 PM > *To:* archivesspace_users_group at lyralists.lyrasis.org > *Subject:* Re: [Archivesspace_Users_Group] PUI Ordering and Sorting Issue > > I forgot to mention that you probably have to re-index after changing > schema.xml and reloading the core. > > Andrew. > > On 28/04/2022 10:51, ?? ???wrote: > > Thanks again Andrew! > > We?ll try applying what you gave to our current AS. > > Hitomi > > *From:*archivesspace_users_group-bounces at lyralists.lyrasis.org > > > *On Behalf Of *Andrew Morrison > *Sent:* Thursday, April 28, 2022 6:09 PM > *To:* archivesspace_users_group at lyralists.lyrasis.org > *Subject:* Re: [Archivesspace_Users_Group] PUI Ordering and > Sorting Issue > > If you're using the schema.xml that came with ArchivesSpace 3.0.1 > in your external Solr 8.11, then it will still define the > "sort_icu" fieldType as an instance of the solr.TextField class. > If you look below that, there is a commented-out alternative > fieldType definition which is an instance of > solr.ICUCollationField. ArchivesSpace 3.2.0 has changed to that > (because it no longer has to support the previously-built-in Solr > 4.10) but you don't need to upgrade to it, you can just edit your > schema.xml, then reload the Solr core. See the link in my previous > email for help on how to set that up to be optimized for Japanese > characters. > > Andrew. > > On 28/04/2022 09:44, ?? ??? wrote: > > Thank you Andrew! > > Our IT says we?ve already been using an external Solr 8.11 > with ArchivesSpace 3.0.1, not the one built-in. > > We?re thinking of upgrading our AS to 3.2.0. Do you think we > will get a better result? > > Hitomi > > *From:*archivesspace_users_group-bounces at lyralists.lyrasis.org > > > *On Behalf Of *Andrew Morrison > *Sent:* Thursday, April 28, 2022 4:47 PM > *To:* archivesspace_users_group at lyralists.lyrasis.org > *Subject:* Re: [Archivesspace_Users_Group] PUI Ordering and > Sorting Issue > > Are you using the built-in Solr search engine that comes with > ArchivesSpace 3.0.1? If so, your sorting problems could be > because it uses a very old version, because newer ones aren't > compatible with the method of embedding it in a bigger > application. But there is the option to configure > ArchivesSpace to use an external Solr service: > > https://archivesspace.github.io/tech-docs/provisioning/solr.html > > That allows you to run a more up-to-date version, which would > enable use of the solr.ICUCollationField class for sort > fields. That can be adjusted to sort different languages > according to their own sorting rules, as described here: > > https://solr.apache.org/guide/8_11/language-analysis.html#unicode-collation > > ArchivesSpace 3.2.0 removes the built-in Solr, so running an > external Solr service will be necessary if you upgrade in the > future. > > As for adding the option to sort on identifiers, I don't think > there is a configuration option or simple interface for adding > them. But it would probably be possible to develop a plug-in > to override certain Ruby methods in the core code to do it. > > Andrew. > > On 27/04/2022 11:04, ?? ???wrote: > > Hello all, > > We?ve been stuck in the ?ordering and sorting? issue in > [~/repositories/resources]. Our AS is version 3.0.1. > > Presumably, because we use Japanese Character, our > resource list cannot be displayed in a right, alphabetical > order when sorted by Title. > > Could we add Identifier to the category of sorting; > Relevance/Title(Asc/Desc)/Year(Asc/Desc), as alternative? > > We?d very much appreciate you helping solve our issue! > > All the best, > > Hitomi Matsuyama, Audiovisual Archivist > > Nakanoshima Museum of Art, Osaka > > 4-3-1 Nakanoshima, Kita-ku > > Osaka 530-0005 JAPAN > > tel. +81 (0)6 64 79 05 58 > > email. matsuyama-h at nakka-art.jp > > > > > > > _______________________________________________ > > Archivesspace_Users_Group mailing list > > Archivesspace_Users_Group at lyralists.lyrasis.org > > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > > _______________________________________________ > > Archivesspace_Users_Group mailing list > > Archivesspace_Users_Group at lyralists.lyrasis.org > > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > _______________________________________________ > > Archivesspace_Users_Group mailing list > > Archivesspace_Users_Group at lyralists.lyrasis.org > > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.morrison at bodleian.ox.ac.uk Wed May 11 05:03:39 2022 From: andrew.morrison at bodleian.ox.ac.uk (Andrew Morrison) Date: Wed, 11 May 2022 10:03:39 +0100 Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 In-Reply-To: References: Message-ID: Indexing can also fail at the commit stage, not related to any one record. That is when ArchivesSpace tells Solr to transfer changes made in memory to storage. It does that at several points in the indexing process, but the longest one is at the end of the PUI indexer's run. If, because you've got a lot of records, or slow storage on your Solr server, it takes longer it respond than the value of AppConfig[:indexer_solr_timeout_seconds], it will start all over again, and potentially go into a loop. The workaround is to increase the timeout. You might not notice you've got enough records to cause this until you do a full re-index, or someone edits something linked to most or all records (e.g. a repository, or a very widely-used subject), triggering the re-indexing of most of the system's records. Andrew. On 10/05/2022 22:06, Blake Carver wrote: > ?1x1 would mean setting both records_per_thread and thread_count to 1. > Having loglevel on debug and running at 1x1, you'll be able to see > exactly which thing is being indexed as it happens, and when it > crashes, you'll see what it was working through at the time. > > PUI will always take longer, and a VERY long time 1x1, but unless > you're sure which indexer is crashing, I'd switch them both up. > > You can just `grep Indexed archivesspace.out` after it's running and > watch those numbers. As long as they're going up, all is well. > > It is also possible that it will finish without crashing running so > slow as well. I've seen that happen with LARGE records. > ------------------------------------------------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of > Tom Hanstra > *Sent:* Tuesday, May 10, 2022 4:15 PM > *To:* Archivesspace Users Group > > *Subject:* Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 > Thanks, Blake. > > Turns out we did add quite a few records recently, so maybe there was > something in there that it did not like all that much. > > How can you tell which record it is choking on?? Is that your "1x1" > suggestion?? Or does the DEBUG option make that more clear?? I have my > indexing set to: > > AppConfig[:indexer_records_per_thread] ? ? ?= 25 > AppConfig[:indexer_thread_count] ? ? ? ? ? ?= 2 > > for both PUI and Staff records. I believe you are suggesting it would > most easily be found using 1 and 1?? I can see where that could take a > long time. But it if is going to choke over and over on the same > record, then that may be the best way to address it. > > Do you think if I just did staff indexing without PUI, that it would > be identified faster?? Or could it pass the staff side but then die on > PUI later? > > I hope to try some of these ideas after hours today, so if you can > confirm that I've got the right idea, that would help. > > Tom > > > On Tue, May 10, 2022 at 2:17 PM Blake Carver > wrote: > > > Is this possible? > > Short answer, Yes, it's possible your indexer is starting over. > > Long answer. This can be tricky to figure out. Something is wrong, > the indexer never wants to do that. Sometimes "something" "bad" > gets into ArchivesSpace and the indexer will just crash and start > over. The problem is the "something" can be anything and the "bad" > can be hard to figure out. The more stuff you have in your DB, the > harder it is to figure out. > > First, I'd make sure this is happening. Your logs should make it > obvious. You might see some FATAL errors just before it starts > over.? You MIGHT be able to narrow it down from that. That is, > what group of records had that error in the logs? Maybe that > narrows it down enough. You just got lucky! > > I don't think I've ever been so lucky. What I'd do next is set > your loglevel to DEBUG and restart. If you're feeling lucky or > just impatient or both, leave the indexer speed as is. You'll get > more details out of the logs and you should be able to narrow it > down better. Ideally, you want to run the indexers at 1x1, which > means it could take forrreeevverrrrr to get back around to the > crash again. If you're lucky, it'll crash on a record, you'll go > look at that record, the problem will be obvious, and there will > be much rejoicing. With it running 1x1 you should see exactly > what's causing the fail. If it's not crashing on the same record > every time.... ugh. That's an even longer answer. > > > > ------------------------------------------------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org > on > behalf of Tom Hanstra > *Sent:* Tuesday, May 10, 2022 10:23 AM > *To:* Archivesspace Users Group > > *Subject:* [Archivesspace_Users_Group] (re)indexing in 2.8.1 > I don't look at the logs a lot unless there are issues with > ArchivesSpace, so maybe this is something normal. But, after a > restart due to some complaints about database connectivity, it > looks like our ArchivesSpace instance has decided to do a full > reindex. The index log sure looks as if it is starting > from?scratch and running through the indexing of both PUI and > Staff indexes. > > Is this possible?? Is it something that happens periodically and I > just did not notice it? Nothing has changed in my data directory, > so I don't see any reason for indexing to occur. Yet that is what > the logs show. > > If it is doing this for some?reason, and knowing that we restart > periodically, it seems like we will get into a loop where indexing > just keeps happening all the?time. Also, it would be helpful to > understand what caused this to happen. > > Any thoughts or experiences from those who have run this for > longer would be appreciated. I'd like to understand if it would be > a good idea to clear the data directory and perform a full index > over the weekend rather than an unexpected and possibly never > ending round in the background. > > Thanks, > Tom > -- > *Tom Hanstra* > /Sr. Systems Administrator/ > hanstra at nd.edu > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > -- > *Tom Hanstra* > /Sr. Systems Administrator/ > hanstra at nd.edu > > > > _______________________________________________ > 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: From andrew.morrison at bodleian.ox.ac.uk Wed May 11 05:14:54 2022 From: andrew.morrison at bodleian.ox.ac.uk (Andrew Morrison) Date: Wed, 11 May 2022 10:14:54 +0100 Subject: [Archivesspace_Users_Group] PUI Ordering and Sorting Issue In-Reply-To: <46de3426-b3dd-89be-b103-41cb66012d28@bodleian.ox.ac.uk> References: <9a86da8a-d6e9-1595-0a1b-e5dab408010d@bodleian.ox.ac.uk> <2ad2fbff-4c25-a1cb-01fc-6e9fff4858c9@bodleian.ox.ac.uk> <46de3426-b3dd-89be-b103-41cb66012d28@bodleian.ox.ac.uk> Message-ID: <0fc865d9-6969-784d-a21d-5e82f9b0ea1e@bodleian.ox.ac.uk> Sorry, make that: [^\p{L}\d\s] Otherwise it'll strip out digits. Andrew. On 11/05/2022 09:53, Andrew Morrison wrote: > > I'd forgotten about clean_for_sort. I've overridden it myself, in a > plug-in. The simplest way is: > > 1. In plugins/local, create a subfolder called "indexer" > 2. Create a file in that subfolder called "indexer_common_override.rb" > 3. In the file, declare "class IndexerCommon" > 4. Copy the def for clean_for_sort into that, and adjust it to meet > your requirements. > 5. Restart and re-index. > > Something like: > > [^\p{L}\s] > > Would be a less anglocentric substitute for: > > [^\w\s] > > If that works, you probably won't have any empty title_sort values, > but in general you can control the sorting of records without values > in schema.xml with the sortMissingLast attribute, see: > > https://solr.apache.org/guide/8_8/field-type-definitions-and-properties.html > > Andrew. > > > On 11/05/2022 08:37, ?? ??? wrote: >> >> Hello, again. >> >> We?ve tried as Andrew kindly suggested. >> >> However, it didn?t work as well as expected? >> >> We think using ?clean_for_sort; IndexerCommon? may interfere when >> ?title? is set to ?title_sort?. >> >> ?clean_for_sort? looks eliminating anything except alphabets and >> numbers when sorting. >> >> It would affect not only Japanese character but also any non-alphabet >> characters, such as Hangul or Cyrillic, we suppose. >> >> We also wonder what order is applied when ?title_sort? is empty. >> >> >> >> Thanks, >> >> Hitomi >> >> Hitomi Matsuyama, Audiovisual Archivist >> >> Nakanoshima Museum of Art, Osaka >> >> 4-3-1 Nakanoshima, Kita-ku >> >> Osaka 530-0005 JAPAN >> >> tel. +81 (0)6 64 79 05 58 >> >> email. matsuyama-h at nakka-art.jp >> >> *From:*archivesspace_users_group-bounces at lyralists.lyrasis.org >> *On Behalf >> Of *Andrew Morrison >> *Sent:* Thursday, April 28, 2022 8:46 PM >> *To:* archivesspace_users_group at lyralists.lyrasis.org >> *Subject:* Re: [Archivesspace_Users_Group] PUI Ordering and Sorting Issue >> >> I forgot to mention that you probably have to re-index after changing >> schema.xml and reloading the core. >> >> Andrew. >> >> On 28/04/2022 10:51, ?? ???wrote: >> >> Thanks again Andrew! >> >> We?ll try applying what you gave to our current AS. >> >> Hitomi >> >> *From:*archivesspace_users_group-bounces at lyralists.lyrasis.org >> >> >> *On Behalf Of *Andrew Morrison >> *Sent:* Thursday, April 28, 2022 6:09 PM >> *To:* archivesspace_users_group at lyralists.lyrasis.org >> *Subject:* Re: [Archivesspace_Users_Group] PUI Ordering and >> Sorting Issue >> >> If you're using the schema.xml that came with ArchivesSpace 3.0.1 >> in your external Solr 8.11, then it will still define the >> "sort_icu" fieldType as an instance of the solr.TextField class. >> If you look below that, there is a commented-out alternative >> fieldType definition which is an instance of >> solr.ICUCollationField. ArchivesSpace 3.2.0 has changed to that >> (because it no longer has to support the previously-built-in Solr >> 4.10) but you don't need to upgrade to it, you can just edit your >> schema.xml, then reload the Solr core. See the link in my >> previous email for help on how to set that up to be optimized for >> Japanese characters. >> >> Andrew. >> >> On 28/04/2022 09:44, ?? ??? wrote: >> >> Thank you Andrew! >> >> Our IT says we?ve already been using an external Solr 8.11 >> with ArchivesSpace 3.0.1, not the one built-in. >> >> We?re thinking of upgrading our AS to 3.2.0. Do you think we >> will get a better result? >> >> Hitomi >> >> *From:*archivesspace_users_group-bounces at lyralists.lyrasis.org >> >> >> *On Behalf Of *Andrew Morrison >> *Sent:* Thursday, April 28, 2022 4:47 PM >> *To:* archivesspace_users_group at lyralists.lyrasis.org >> *Subject:* Re: [Archivesspace_Users_Group] PUI Ordering and >> Sorting Issue >> >> Are you using the built-in Solr search engine that comes with >> ArchivesSpace 3.0.1? If so, your sorting problems could be >> because it uses a very old version, because newer ones aren't >> compatible with the method of embedding it in a bigger >> application. But there is the option to configure >> ArchivesSpace to use an external Solr service: >> >> https://archivesspace.github.io/tech-docs/provisioning/solr.html >> >> That allows you to run a more up-to-date version, which would >> enable use of the solr.ICUCollationField class for sort >> fields. That can be adjusted to sort different languages >> according to their own sorting rules, as described here: >> >> https://solr.apache.org/guide/8_11/language-analysis.html#unicode-collation >> >> ArchivesSpace 3.2.0 removes the built-in Solr, so running an >> external Solr service will be necessary if you upgrade in the >> future. >> >> As for adding the option to sort on identifiers, I don't >> think there is a configuration option or simple interface for >> adding them. But it would probably be possible to develop a >> plug-in to override certain Ruby methods in the core code to >> do it. >> >> Andrew. >> >> On 27/04/2022 11:04, ?? ???wrote: >> >> Hello all, >> >> We?ve been stuck in the ?ordering and sorting? issue in >> [~/repositories/resources]. Our AS is version 3.0.1. >> >> Presumably, because we use Japanese Character, our >> resource list cannot be displayed in a right, >> alphabetical order when sorted by Title. >> >> Could we add Identifier to the category of sorting; >> Relevance/Title(Asc/Desc)/Year(Asc/Desc), as alternative? >> >> We?d very much appreciate you helping solve our issue! >> >> All the best, >> >> Hitomi Matsuyama, Audiovisual Archivist >> >> Nakanoshima Museum of Art, Osaka >> >> 4-3-1 Nakanoshima, Kita-ku >> >> Osaka 530-0005 JAPAN >> >> tel. +81 (0)6 64 79 05 58 >> >> email. matsuyama-h at nakka-art.jp >> >> >> >> >> >> >> _______________________________________________ >> >> Archivesspace_Users_Group mailing list >> >> Archivesspace_Users_Group at lyralists.lyrasis.org >> >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> >> >> >> >> _______________________________________________ >> >> Archivesspace_Users_Group mailing list >> >> Archivesspace_Users_Group at lyralists.lyrasis.org >> >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> >> >> >> _______________________________________________ >> >> Archivesspace_Users_Group mailing list >> >> Archivesspace_Users_Group at lyralists.lyrasis.org >> >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> >> >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > _______________________________________________ > 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: From hanstra at nd.edu Wed May 11 09:30:51 2022 From: hanstra at nd.edu (Tom Hanstra) Date: Wed, 11 May 2022 09:30:51 -0400 Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 In-Reply-To: References: Message-ID: Thanks again for your help. Late yesterday, both indexes indicated completion so I thought maybe things were going to be OK. Consequently, I did not do much in terms of testing. This morning, the logs again had errors, however. In the logs, I found this error in the indexer log: I, [2022-05-10T21:36:07.181427 #30003] INFO -- : Thread-2890: Staff Indexer [2022-05-10 21:36:07 -0400] Index round complete I, [2022-05-10T21:36:37.182006 #30003] INFO -- : Thread-2890: Staff Indexer [2022-05-10 21:36:37 -0400] Running index round E, [2022-05-10T21:36:37.283423 #30003] ERROR -- : Thread-2890: uri:classloader:/jsonmodel_client.rb:493:in `all' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:154:in `run_index_round' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:283:in `run' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/main.rb:32:in `block in main' E, [2022-05-10T21:36:37.284431 #30003] ERROR -- : Thread-2890: # wrote: > Indexing can also fail at the commit stage, not related to any one record. > That is when ArchivesSpace tells Solr to transfer changes made in memory to > storage. It does that at several points in the indexing process, but the > longest one is at the end of the PUI indexer's run. If, because you've got > a lot of records, or slow storage on your Solr server, it takes longer it > respond than the value of AppConfig[:indexer_solr_timeout_seconds], it will > start all over again, and potentially go into a loop. The workaround is to > increase the timeout. > > > You might not notice you've got enough records to cause this until you do > a full re-index, or someone edits something linked to most or all records > (e.g. a repository, or a very widely-used subject), triggering the > re-indexing of most of the system's records. > > > Andrew. > > > > On 10/05/2022 22:06, Blake Carver wrote: > > 1x1 would mean setting both records_per_thread and thread_count to 1. > Having loglevel on debug and running at 1x1, you'll be able to see exactly > which thing is being indexed as it happens, and when it crashes, you'll see > what it was working through at the time. > > PUI will always take longer, and a VERY long time 1x1, but unless you're > sure which indexer is crashing, I'd switch them both up. > > You can just `grep Indexed archivesspace.out` after it's running and watch > those numbers. As long as they're going up, all is well. > > It is also possible that it will finish without crashing running so slow > as well. I've seen that happen with LARGE records. > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org > > on behalf of > Tom Hanstra > *Sent:* Tuesday, May 10, 2022 4:15 PM > *To:* Archivesspace Users Group > > > *Subject:* Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > Thanks, Blake. > > Turns out we did add quite a few records recently, so maybe there was > something in there that it did not like all that much. > > How can you tell which record it is choking on? Is that your "1x1" > suggestion? Or does the DEBUG option make that more clear? I have my > indexing set to: > > AppConfig[:indexer_records_per_thread] = 25 > AppConfig[:indexer_thread_count] = 2 > > for both PUI and Staff records. I believe you are suggesting it would most > easily be found using 1 and 1? I can see where that could take a long > time. But it if is going to choke over and over on the same record, then > that may be the best way to address it. > > Do you think if I just did staff indexing without PUI, that it would be > identified faster? Or could it pass the staff side but then die on PUI > later? > > I hope to try some of these ideas after hours today, so if you can confirm > that I've got the right idea, that would help. > > Tom > > > On Tue, May 10, 2022 at 2:17 PM Blake Carver > wrote: > > > Is this possible? > > Short answer, Yes, it's possible your indexer is starting over. > > Long answer. This can be tricky to figure out. Something is wrong, the > indexer never wants to do that. Sometimes "something" "bad" gets into > ArchivesSpace and the indexer will just crash and start over. The problem > is the "something" can be anything and the "bad" can be hard to figure out. > The more stuff you have in your DB, the harder it is to figure out. > > First, I'd make sure this is happening. Your logs should make it obvious. > You might see some FATAL errors just before it starts over. You MIGHT be > able to narrow it down from that. That is, what group of records had that > error in the logs? Maybe that narrows it down enough. You just got lucky! > > I don't think I've ever been so lucky. What I'd do next is set your > loglevel to DEBUG and restart. If you're feeling lucky or just impatient or > both, leave the indexer speed as is. You'll get more details out of the > logs and you should be able to narrow it down better. Ideally, you want to > run the indexers at 1x1, which means it could take forrreeevverrrrr to get > back around to the crash again. If you're lucky, it'll crash on a record, > you'll go look at that record, the problem will be obvious, and there will > be much rejoicing. With it running 1x1 you should see exactly what's > causing the fail. If it's not crashing on the same record every time.... > ugh. That's an even longer answer. > > > > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Tom > Hanstra > *Sent:* Tuesday, May 10, 2022 10:23 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > I don't look at the logs a lot unless there are issues with ArchivesSpace, > so maybe this is something normal. But, after a restart due to some > complaints about database connectivity, it looks like our ArchivesSpace > instance has decided to do a full reindex. The index log sure looks as if > it is starting from scratch and running through the indexing of both PUI > and Staff indexes. > > Is this possible? Is it something that happens periodically and I just > did not notice it? Nothing has changed in my data directory, so I don't see > any reason for indexing to occur. Yet that is what the logs show. > > If it is doing this for some reason, and knowing that we restart > periodically, it seems like we will get into a loop where indexing just > keeps happening all the time. Also, it would be helpful to understand what > caused this to happen. > > Any thoughts or experiences from those who have run this for longer would > be appreciated. I'd like to understand if it would be a good idea to clear > the data directory and perform a full index over the weekend rather than an > unexpected and possibly never ending round in the background. > > Thanks, > Tom > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > > _______________________________________________ > Archivesspace_Users_Group mailing listArchivesspace_Users_Group at lyralists.lyrasis.orghttp://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -- *Tom Hanstra* *Sr. Systems Administrator* hanstra at nd.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake.carver at lyrasis.org Thu May 12 08:59:37 2022 From: blake.carver at lyrasis.org (Blake Carver) Date: Thu, 12 May 2022 12:59:37 +0000 Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 In-Reply-To: References: Message-ID: > Could it be that we added a big record which is now having issues being extracted. Or a corrupted record which is causing such issues? I don't think so? It could be, but those errors make me think there's something else going on with the DB, or maybe the network between the application and DB server? I'm not really sure what the problem is, but it seems more like a hardware/network/server issue than an ArchivesSpace issue. I can't be sure, but those errors don't look like ArchivesSpace troubles to me. Those are pretty common errors, so I'd do some searching around to see what you can find to troubleshoot. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Tom Hanstra Sent: Wednesday, May 11, 2022 9:30 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Thanks again for your help. Late yesterday, both indexes indicated completion so I thought maybe things were going to be OK. Consequently, I did not do much in terms of testing. This morning, the logs again had errors, however. In the logs, I found this error in the indexer log: I, [2022-05-10T21:36:07.181427 #30003] INFO -- : Thread-2890: Staff Indexer [2022-05-10 21:36:07 -0400] Index round complete I, [2022-05-10T21:36:37.182006 #30003] INFO -- : Thread-2890: Staff Indexer [2022-05-10 21:36:37 -0400] Running index round E, [2022-05-10T21:36:37.283423 #30003] ERROR -- : Thread-2890: uri:classloader:/jsonmodel_client.rb:493:in `all' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:154:in `run_index_round' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:283:in `run' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/main.rb:32:in `block in main' E, [2022-05-10T21:36:37.284431 #30003] ERROR -- : Thread-2890: #> wrote: Indexing can also fail at the commit stage, not related to any one record. That is when ArchivesSpace tells Solr to transfer changes made in memory to storage. It does that at several points in the indexing process, but the longest one is at the end of the PUI indexer's run. If, because you've got a lot of records, or slow storage on your Solr server, it takes longer it respond than the value of AppConfig[:indexer_solr_timeout_seconds], it will start all over again, and potentially go into a loop. The workaround is to increase the timeout. You might not notice you've got enough records to cause this until you do a full re-index, or someone edits something linked to most or all records (e.g. a repository, or a very widely-used subject), triggering the re-indexing of most of the system's records. Andrew. On 10/05/2022 22:06, Blake Carver wrote: 1x1 would mean setting both records_per_thread and thread_count to 1. Having loglevel on debug and running at 1x1, you'll be able to see exactly which thing is being indexed as it happens, and when it crashes, you'll see what it was working through at the time. PUI will always take longer, and a VERY long time 1x1, but unless you're sure which indexer is crashing, I'd switch them both up. You can just `grep Indexed archivesspace.out` after it's running and watch those numbers. As long as they're going up, all is well. It is also possible that it will finish without crashing running so slow as well. I've seen that happen with LARGE records. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Tom Hanstra Sent: Tuesday, May 10, 2022 4:15 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Thanks, Blake. Turns out we did add quite a few records recently, so maybe there was something in there that it did not like all that much. How can you tell which record it is choking on? Is that your "1x1" suggestion? Or does the DEBUG option make that more clear? I have my indexing set to: AppConfig[:indexer_records_per_thread] = 25 AppConfig[:indexer_thread_count] = 2 for both PUI and Staff records. I believe you are suggesting it would most easily be found using 1 and 1? I can see where that could take a long time. But it if is going to choke over and over on the same record, then that may be the best way to address it. Do you think if I just did staff indexing without PUI, that it would be identified faster? Or could it pass the staff side but then die on PUI later? I hope to try some of these ideas after hours today, so if you can confirm that I've got the right idea, that would help. Tom On Tue, May 10, 2022 at 2:17 PM Blake Carver > wrote: > Is this possible? Short answer, Yes, it's possible your indexer is starting over. Long answer. This can be tricky to figure out. Something is wrong, the indexer never wants to do that. Sometimes "something" "bad" gets into ArchivesSpace and the indexer will just crash and start over. The problem is the "something" can be anything and the "bad" can be hard to figure out. The more stuff you have in your DB, the harder it is to figure out. First, I'd make sure this is happening. Your logs should make it obvious. You might see some FATAL errors just before it starts over. You MIGHT be able to narrow it down from that. That is, what group of records had that error in the logs? Maybe that narrows it down enough. You just got lucky! I don't think I've ever been so lucky. What I'd do next is set your loglevel to DEBUG and restart. If you're feeling lucky or just impatient or both, leave the indexer speed as is. You'll get more details out of the logs and you should be able to narrow it down better. Ideally, you want to run the indexers at 1x1, which means it could take forrreeevverrrrr to get back around to the crash again. If you're lucky, it'll crash on a record, you'll go look at that record, the problem will be obvious, and there will be much rejoicing. With it running 1x1 you should see exactly what's causing the fail. If it's not crashing on the same record every time.... ugh. That's an even longer answer. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Tuesday, May 10, 2022 10:23 AM To: Archivesspace Users Group > Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 I don't look at the logs a lot unless there are issues with ArchivesSpace, so maybe this is something normal. But, after a restart due to some complaints about database connectivity, it looks like our ArchivesSpace instance has decided to do a full reindex. The index log sure looks as if it is starting from scratch and running through the indexing of both PUI and Staff indexes. Is this possible? Is it something that happens periodically and I just did not notice it? Nothing has changed in my data directory, so I don't see any reason for indexing to occur. Yet that is what the logs show. If it is doing this for some reason, and knowing that we restart periodically, it seems like we will get into a loop where indexing just keeps happening all the time. Also, it would be helpful to understand what caused this to happen. Any thoughts or experiences from those who have run this for longer would be appreciated. I'd like to understand if it would be a good idea to clear the data directory and perform a full index over the weekend rather than an unexpected and possibly never ending round in the background. Thanks, Tom -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] -------------- next part -------------- An HTML attachment was scrubbed... URL: From Heidi.Pettitt at loras.edu Thu May 12 11:02:30 2022 From: Heidi.Pettitt at loras.edu (Heidi R. Pettitt) Date: Thu, 12 May 2022 15:02:30 +0000 Subject: [Archivesspace_Users_Group] Browser Access Not Working Message-ID: Hi All, My IT department is having trouble setting up ArchivesSpace and sent me the following details: The issue I'm having is I'm trying to access ArchivesSpace through a web browser by typing in Http://IP Address of my Archives Space server:8080. This is supposed to bring me to an Archives Space login in web page but it says it is unable to connect. When I enter the command netstat -an -p tcp | find "8080" at a command prompt, it is not showing anything which means port 8080 is not listening. I don't know what to do to get port 8080 to listen. Does anyone have any suggestions for what's going on and how to fix it? You can reply to this email and I'll forward the information to him or you can email him at kevin.kraus at loras.edu. Thanks, ~Heidi HEIDI PETTITT (she/her) Director of the Center for Dubuque History Access Services & Special Collections Librarian LORAS COLLEGE Library/Center for Dubuque History Miller Academic Resource Center 154 1450 Alta Vista Dubuque, IA 52001 O: 563.588.7873 Meet With Me! http://library.loras.edu/ CONFIDENTIALITY NOTICE: This email, including any attachments, is the property of Loras College. The information may be legally privileged and/or confidential and is intended solely for the use of the addressee. If you are not the intended recipient be advised that any unauthorized disclosure, copying, distribution or use of the contents herein is strictly prohibited. If you have received this message in error, please notify the sender immediately and destroy all electronic and hard copies of the communication, including attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christine.dibella at lyrasis.org Thu May 12 11:02:46 2022 From: christine.dibella at lyrasis.org (Christine Di Bella) Date: Thu, 12 May 2022 15:02:46 +0000 Subject: [Archivesspace_Users_Group] Take a Break with ArchivesSpace on Friday Message-ID: Dear ArchivesSpace users, After a one-week hiatus, our Friday break call returns this week. These casual open calls take place on zoom at 12pm ET on Fridays and don't have agendas or presentations. They're just an opportunity to connect, chat and recharge. Use this as a time to get help or talk about ArchivesSpace (or anything else) in an informal setting or have a beverage with other ArchivesSpace users during this stressful time. Whether you can attend once or plan to be there every Friday, these calls are open to everyone but registration is required to join. Register once to join any open call at https://lyrasis.zoom.us/meeting/register/tZcldOGuqjotE9cNSaa6j45issVCKrEQKQYv We seek to provide a welcoming, fun, and safe community experience for everyone. The full text of the code of conduct is available at https://archivesspace.org/archivesspace-code-of-conduct. Please email ArchivesSpaceHome at lyrasis.org with any questions. We hope to see you tomorrow! Christine Christine Di Bella ArchivesSpace Program Manager christine.dibella at lyrasis.org 800.999.8558 x2905 678-235-2905 [ASpaceOrgHomeMedium] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 13904 bytes Desc: image001.jpg URL: From ph448 at cam.ac.uk Thu May 12 15:59:54 2022 From: ph448 at cam.ac.uk (Peter Heiner) Date: Thu, 12 May 2022 19:59:54 +0000 Subject: [Archivesspace_Users_Group] Browser Access Not Working In-Reply-To: References: Message-ID: <20220512195953.ldlfszyz4nirt453@sparkly> Heidi R. Pettitt wrote on 2022-05-12 15:02:30: > Hi All, > > The issue I'm having is I'm trying to access ArchivesSpace through a web browser by typing in Http://IP Address of my Archives Space server:8080. This is supposed to bring me to an Archives Space login in web page but it says it is unable to connect. When I enter the command netstat -an -p tcp | find "8080" at a command prompt, it is not showing anything which means port 8080 is not listening. I don't know what to do to get port 8080 to listen. The intended effect of the command you posted is to search for the string 8080 anywhere in the output of the netstat command, however, on a Posix system 'find' searches for files, you'd want 'grep' to filter netstat's piped output. In any case, 'unable to connect' means that the connection could not be established, so netstat output is unlikely to be helpful. Verify each component of the full URL: scheme, IP address and port. Hope that helps, p From Jessica.Crouch at lyrasis.org Tue May 3 11:54:51 2022 From: Jessica.Crouch at lyrasis.org (Jessica Crouch) Date: Tue, 3 May 2022 15:54:51 +0000 Subject: [Archivesspace_Users_Group] Apply now for the second cohort of the ArchivesSpace Member Match program [deadline extended to May 20] In-Reply-To: References: Message-ID: Dear ArchivesSpace Users, The deadline to apply to participate in the ArchivesSpace Member Match program has been extended to next Friday, May 20th. The Member Match program is an initiative to engage the ArchivesSpace membership community, created and organized by the Member Engagement sub-team of the ArchivesSpace User Advisory Council, with support from the ArchivesSpace Community Engagement Coordinator. The program is intended to be a resource and venue for peer-to-peer support between ArchivesSpace members. For one, year-long term, participants will be matched with a member with whom they can receive and offer professional insight, advice, and camaraderie. The program will also offer participants the opportunity to engage in exclusive events and enlightening discussions about ArchivesSpace and its active user community. Thanks to valuable feedback from the first cohort of Member Match Participants, we?ve implemented the following updates to the program: * Monthly Listserv Discussion Topics * Each month, a member of the Member Engagement sub-team will reach out to the Member Match listserv to spur discussion and encourage continued engagement between matches. * Quarterly Member Match Meet-Ups * These will be opportunities for large group socializing as well as the potential for dedicated time to spend with matches in breakout rooms. * Option to participate in small group matches of 3 people Eligibility Any individual affiliated with an ArchivesSpace member organization is eligible to participate in the ArchivesSpace Member Match program and there is no limit to the number of individuals from a member organization that may participate. If you are unsure of your organization?s ArchivesSpace membership status, visit https://archivesspace.org/community/whos-using-archivesspace or email ArchivesSpaceHome at lyrasis.org. To Apply There is a short application to complete at https://airtable.com/shrDL4wQhc3gkBAlH Applications should be submitted by May 20th, 2022. Applicants will be notified of their matches no later than June 30th. To Learn More Visit the Member Match wiki: https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/2198568994/ArchivesSpace+Member+Match+Program Please feel free to direct any questions to ArchivesSpaceHome at lyrasis.org Sent on behalf of the ArchivesSpace Member Engagement sub-team Regina Carra, American Folk Art Museum Bailey Hoffner, University of Oklahoma Patrick Milhoan, University of Notre Dame Sarah Ponichtera, Seton Hall University Jessica Crouch, ArchivesSpace Community Engagement Coordinator Jessica Dowd Crouch Community Engagement Coordinator for ArchivesSpace jessica.crouch at lyrasis.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake.carver at lyrasis.org Fri May 13 10:04:09 2022 From: blake.carver at lyrasis.org (Blake Carver) Date: Fri, 13 May 2022 14:04:09 +0000 Subject: [Archivesspace_Users_Group] Browser Access Not Working In-Reply-To: References: Message-ID: That sounds like it's not running at all. Check the archivesspace.out file in the logs directory for errors. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Heidi R. Pettitt Sent: Thursday, May 12, 2022 11:02 AM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Browser Access Not Working Hi All, My IT department is having trouble setting up ArchivesSpace and sent me the following details: The issue I?m having is I?m trying to access ArchivesSpace through a web browser by typing in Http://IP Address of my Archives Space server:8080. This is supposed to bring me to an Archives Space login in web page but it says it is unable to connect. When I enter the command netstat -an -p tcp | find ?8080? at a command prompt, it is not showing anything which means port 8080 is not listening. I don?t know what to do to get port 8080 to listen. Does anyone have any suggestions for what?s going on and how to fix it? You can reply to this email and I?ll forward the information to him or you can email him at kevin.kraus at loras.edu. Thanks, ~Heidi HEIDI PETTITT (she/her) Director of the Center for Dubuque History Access Services & Special Collections Librarian LORAS COLLEGE Library/Center for Dubuque History Miller Academic Resource Center 154 1450 Alta Vista Dubuque, IA 52001 O: 563.588.7873 Meet With Me! http://library.loras.edu/ CONFIDENTIALITY NOTICE: This email, including any attachments, is the property of Loras College. The information may be legally privileged and/or confidential and is intended solely for the use of the addressee. If you are not the intended recipient be advised that any unauthorized disclosure, copying, distribution or use of the contents herein is strictly prohibited. If you have received this message in error, please notify the sender immediately and destroy all electronic and hard copies of the communication, including attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at virginia.edu Fri May 13 11:51:07 2022 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Fri, 13 May 2022 15:51:07 +0000 Subject: [Archivesspace_Users_Group] Browser Access Not Working In-Reply-To: References: Message-ID: <0AB76052-E26C-49CD-B193-17DCE6DA1F41@virginia.edu> Look at the log file for errors on startup. If this is a first install, then I would especially check for MySQL errors to make sure ASpace backend server is connecting to MySQL server. ( Did they or you edit the config.rb file and run setup-database.sh script, or are you just trying to get a test server running? ) On the server that?s running ArchivesSpace, try the command ?curl http://localhost:8089/' to access the backend server. ( sometimes ports are blocked from outside access by firewall settings. ) > On May 12, 2022, at 11:02 AM, Heidi R. Pettitt wrote: > > Hi All, > > My IT department is having trouble setting up ArchivesSpace and sent me the following details: > > The issue I?m having is I?m trying to access ArchivesSpace through a web browser by typing in Http://IP Address of my Archives Space server:8080. This is supposed to bring me to an Archives Space login in web page but it says it is unable to connect. When I enter the command netstat -an -p tcp | find ?8080? at a command prompt, it is not showing anything which means port 8080 is not listening. I don?t know what to do to get port 8080 to listen. > > Does anyone have any suggestions for what?s going on and how to fix it? You can reply to this email and I?ll forward the information to him or you can email him at kevin.kraus at loras.edu . > > Thanks, > > ~Heidi > > HEIDI PETTITT (she/her) > Director of the Center for Dubuque History > Access Services & Special Collections Librarian > > LORAS COLLEGE > Library/Center for Dubuque History > Miller Academic Resource Center 154 > 1450 Alta Vista > Dubuque, IA 52001 > O: 563.588.7873 > Meet With Me! > http://library.loras.edu/ > > > > CONFIDENTIALITY NOTICE: This email, including any attachments, is the property of Loras College. The information may be legally privileged and/or confidential and is intended solely for the use of the addressee. If you are not the intended recipient be advised that any unauthorized disclosure, copying, distribution or use of the contents herein is strictly prohibited. If you have received this message in error, please notify the sender immediately and destroy all electronic and hard copies of the communication, including attachments. _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3342 bytes Desc: not available URL: From kthompson at tsl.texas.gov Fri May 13 12:07:28 2022 From: kthompson at tsl.texas.gov (Kathleen Krause-Thompson) Date: Fri, 13 May 2022 16:07:28 +0000 Subject: [Archivesspace_Users_Group] Partial staff front-page loading Message-ID: About every 3 weeks I need to stop and restart Archivesspace in order to correct this issue with partial front-page loading. This causes staff to not be able to login to Archivesspace. What doesn't load are stylesheets, JavaScript, and form handler/s. Https protocol is intact. I'm considering a nightly cron job to do this stop/start process if there are no evening Archivesspace procedures running at that time. Any hints or tips would be appreciated. Thanks. Kathleen K Thompson Texas State Library & Archives -------------- next part -------------- An HTML attachment was scrubbed... URL: From Heidi.Pettitt at loras.edu Fri May 13 18:00:42 2022 From: Heidi.Pettitt at loras.edu (Heidi R. Pettitt) Date: Fri, 13 May 2022 22:00:42 +0000 Subject: [Archivesspace_Users_Group] Browser Access Not Working In-Reply-To: References: Message-ID: Thanks to everyone that has responded. Kevin added the following details this afternoon: I'm using the instructions linked below. I'm stuck on Step #11 which says to wait until you see port 8080 min a listening state and it never happens. Is there a step I'm missing? https://github.com/timpetro/archivesspace-install/blob/main/Install%20ArchivesSpace%20on%20Windows.txt Thanks, ~ Heidi From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Heidi R. Pettitt Sent: Thursday, May 12, 2022 10:03 AM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Browser Access Not Working Hi All, My IT department is having trouble setting up ArchivesSpace and sent me the following details: The issue I'm having is I'm trying to access ArchivesSpace through a web browser by typing in Http://IP Address of my Archives Space server:8080. This is supposed to bring me to an Archives Space login in web page but it says it is unable to connect. When I enter the command netstat -an -p tcp | find "8080" at a command prompt, it is not showing anything which means port 8080 is not listening. I don't know what to do to get port 8080 to listen. Does anyone have any suggestions for what's going on and how to fix it? You can reply to this email and I'll forward the information to him or you can email him at kevin.kraus at loras.edu. Thanks, ~Heidi HEIDI PETTITT (she/her) Director of the Center for Dubuque History Access Services & Special Collections Librarian LORAS COLLEGE Library/Center for Dubuque History Miller Academic Resource Center 154 1450 Alta Vista Dubuque, IA 52001 O: 563.588.7873 Meet With Me! http://library.loras.edu/ CONFIDENTIALITY NOTICE: This email, including any attachments, is the property of Loras College. The information may be legally privileged and/or confidential and is intended solely for the use of the addressee. If you are not the intended recipient be advised that any unauthorized disclosure, copying, distribution or use of the contents herein is strictly prohibited. If you have received this message in error, please notify the sender immediately and destroy all electronic and hard copies of the communication, including attachments. CONFIDENTIALITY NOTICE: This email, including any attachments, is the property of Loras College. The information may be legally privileged and/or confidential and is intended solely for the use of the addressee. If you are not the intended recipient be advised that any unauthorized disclosure, copying, distribution or use of the contents herein is strictly prohibited. If you have received this message in error, please notify the sender immediately and destroy all electronic and hard copies of the communication, including attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mweppler at csustan.edu Fri May 13 19:25:32 2022 From: mweppler at csustan.edu (Mary Weppler) Date: Fri, 13 May 2022 23:25:32 +0000 Subject: [Archivesspace_Users_Group] Moving/transferring an archival object as its own resource record Message-ID: Hello all! I am looking for a way to move an archival object (with child records) up to the first level as its own resource record. I know that I can transfer an archival object to an accession, but I've had information disappear when doing so and am hesitant to use this method. Thank you in advance for any help with this question! Mary Mary Weppler-Van Diver Library Faculty, Librarian & CA Special Collections and University Archives Email: mweppler at csustan.edu Phone: 209-664-6538 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.morrison at bodleian.ox.ac.uk Mon May 16 04:18:55 2022 From: andrew.morrison at bodleian.ox.ac.uk (Andrew Morrison) Date: Mon, 16 May 2022 09:18:55 +0100 Subject: [Archivesspace_Users_Group] Moving/transferring an archival object as its own resource record In-Reply-To: References: Message-ID: It would be possible to manually create a resource to replace the first archival object, then use the API to transfer all the archival objects descended from it to the new resource. Whether that is an option for you, or not, I don't know. An easier alternative, but one that would change all the PUI URLs of all the descendant archival objects, would be to export as EAD, rearrange that outside ArchivesSpace, then import it as a new resource. Andrew. On 14/05/2022 00:25, Mary Weppler wrote: > Hello all! > > I am looking for a way to move an archival object (with child records) > up to the first level as its own resource record.? I know that I can > transfer an archival object to an accession, but I've had information > disappear when doing so and am hesitant to use this method. > > Thank you in advance for any help with this question! > > Mary > > Mary Weppler-Van Diver > Library Faculty, Librarian & CA > > Special Collections and University Archives > > Email: mweppler at csustan.edu > Phone: 209-664-6538 > > _______________________________________________ > 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: From mweppler at csustan.edu Mon May 16 10:16:50 2022 From: mweppler at csustan.edu (Mary Weppler) Date: Mon, 16 May 2022 14:16:50 +0000 Subject: [Archivesspace_Users_Group] Moving/transferring an archival object as its own resource record In-Reply-To: References: Message-ID: Hello Andrew, Thank you very much for providing these solutions! I believe your first idea, to manually create the resource and then transfer the child record to the new resource, would work perfectly for our configuration. Thank you again!! Mary Mary Weppler-Van Diver Library Faculty, Librarian & CA Special Collections and University Archives Email: mweppler at csustan.edu Phone: 209-664-6538 ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Andrew Morrison Sent: Monday, May 16, 2022 1:18 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: Re: [Archivesspace_Users_Group] Moving/transferring an archival object as its own resource record CAUTION: This message originated from outside of Stanislaus State. Do not click on links or open attachments unless you recognize the sender and are expecting the message. It would be possible to manually create a resource to replace the first archival object, then use the API to transfer all the archival objects descended from it to the new resource. Whether that is an option for you, or not, I don't know. An easier alternative, but one that would change all the PUI URLs of all the descendant archival objects, would be to export as EAD, rearrange that outside ArchivesSpace, then import it as a new resource. Andrew. On 14/05/2022 00:25, Mary Weppler wrote: Hello all! I am looking for a way to move an archival object (with child records) up to the first level as its own resource record. I know that I can transfer an archival object to an accession, but I've had information disappear when doing so and am hesitant to use this method. Thank you in advance for any help with this question! Mary Mary Weppler-Van Diver Library Faculty, Librarian & CA Special Collections and University Archives Email: mweppler at csustan.edu Phone: 209-664-6538 _______________________________________________ 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: From karen.urbec at whoi.edu Mon May 16 10:34:27 2022 From: karen.urbec at whoi.edu (Karen Urbec) Date: Mon, 16 May 2022 14:34:27 +0000 Subject: [Archivesspace_Users_Group] collection editing reports? Message-ID: Hi Everyone, I have a question about running edit reports in ArchivesSpace. What I mean is, when looking at a large collection (with many series and items), is there a report I can run to see which items were last edited, and when, and by whom? thanks! Karen Karen Urbec (she/her) Institution Archivist, MBLWHOI Library Woods Hole Oceanographic Institution MS#8, phone:508-289-2269 https://orcid.org/0000-0001-6673-4478 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hanstra at nd.edu Mon May 16 10:43:16 2022 From: hanstra at nd.edu (Tom Hanstra) Date: Mon, 16 May 2022 10:43:16 -0400 Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 In-Reply-To: References: Message-ID: I've been monitoring logs and have run into a couple of instances where I receive this type of error: E, [2022-05-16T08:57:57.207392 #5273] ERROR -- : Thread-3962: Unhandled exception! E, [2022-05-16T08:57:57.207810 #5273] ERROR -- : invalid byte sequence in UTF-8 and then a lot of detail. Are these errors with data that should be addressed? I'm still in DEBUG mode in the backend log but it is not clear how to figure out which record(s) are being flagged. What am I looking for? Thanks, Tom On Thu, May 12, 2022 at 8:59 AM Blake Carver wrote: > > Could it be that we added a big record which is now having issues being > extracted. Or a corrupted record which is causing such issues? > > I don't think so? It could be, but those errors make me think there's > something else going on with the DB, or maybe the network between the > application and DB server? I'm not really sure what the problem is, but it > seems more like a hardware/network/server issue than an ArchivesSpace > issue. I can't be sure, but those errors don't look like ArchivesSpace > troubles to me. Those are pretty common errors, so I'd do some searching > around to see what you can find to troubleshoot. > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Tom > Hanstra > *Sent:* Wednesday, May 11, 2022 9:30 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > Thanks again for your help. > > Late yesterday, both indexes indicated completion so I thought maybe > things were going to be OK. Consequently, I did not do much in terms of > testing. > > This morning, the logs again had errors, however. In the logs, I found > this error in the indexer log: > > I, [2022-05-10T21:36:07.181427 #30003] INFO -- : Thread-2890: Staff > Indexer [2022-05-10 21:36:07 -0400] Index round complete > I, [2022-05-10T21:36:37.182006 #30003] INFO -- : Thread-2890: Staff > Indexer [2022-05-10 21:36:37 -0400] Running index round > E, [2022-05-10T21:36:37.283423 #30003] ERROR -- : Thread-2890: > uri:classloader:/jsonmodel_client.rb:493:in `all' > /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:154:in > `run_index_round' > /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:283:in > `run' > /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/main.rb:32:in > `block in main' > E, [2022-05-10T21:36:37.284431 #30003] ERROR -- : Thread-2890: > # conflict: Java::JavaSql::SQLNonTransientConnectionException: No operations > allowed after connection closed."]}} > > and in the backup log there were issues with timeouts retrieving a record: > > Java::ComMysqlCjJdbcExceptions::CommunicationsException: The last packet > successfully received from the server was 1,759 milliseconds ago. The last > packet sent successfully to the server was 28,849,143 milliseconds ago. is > longer than the server configured value of 'wait_timeout'. You should > consider either expiring and/or testing connection validity before use in > your application, increasing the server configured values for client > timeouts, or using the Connector/J connection property 'autoReconnect=true' > to avoid this problem. > > Could it be that we added a big record which is now having issues being > extracted. Or a corrupted record which is causing such issues? > > I've now restarted with the 1x1 and DEBUG on and only staff indexing and > it is still thinking indexing is complete. I'll keep things going this way > until we hit an error again and hopefully that will give additional > information. > > I'll also look into the "autoReconnect=true" piece, since we seem to have > a situation where, once this happens, nothing more works until a restart. > > Thanks again for any thoughts on this, > Tom > > On Wed, May 11, 2022 at 5:03 AM Andrew Morrison < > andrew.morrison at bodleian.ox.ac.uk> wrote: > > Indexing can also fail at the commit stage, not related to any one record. > That is when ArchivesSpace tells Solr to transfer changes made in memory to > storage. It does that at several points in the indexing process, but the > longest one is at the end of the PUI indexer's run. If, because you've got > a lot of records, or slow storage on your Solr server, it takes longer it > respond than the value of AppConfig[:indexer_solr_timeout_seconds], it will > start all over again, and potentially go into a loop. The workaround is to > increase the timeout. > > > You might not notice you've got enough records to cause this until you do > a full re-index, or someone edits something linked to most or all records > (e.g. a repository, or a very widely-used subject), triggering the > re-indexing of most of the system's records. > > > Andrew. > > > > On 10/05/2022 22:06, Blake Carver wrote: > > 1x1 would mean setting both records_per_thread and thread_count to 1. > Having loglevel on debug and running at 1x1, you'll be able to see exactly > which thing is being indexed as it happens, and when it crashes, you'll see > what it was working through at the time. > > PUI will always take longer, and a VERY long time 1x1, but unless you're > sure which indexer is crashing, I'd switch them both up. > > You can just `grep Indexed archivesspace.out` after it's running and watch > those numbers. As long as they're going up, all is well. > > It is also possible that it will finish without crashing running so slow > as well. I've seen that happen with LARGE records. > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org > > on behalf of > Tom Hanstra > *Sent:* Tuesday, May 10, 2022 4:15 PM > *To:* Archivesspace Users Group > > > *Subject:* Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > Thanks, Blake. > > Turns out we did add quite a few records recently, so maybe there was > something in there that it did not like all that much. > > How can you tell which record it is choking on? Is that your "1x1" > suggestion? Or does the DEBUG option make that more clear? I have my > indexing set to: > > AppConfig[:indexer_records_per_thread] = 25 > AppConfig[:indexer_thread_count] = 2 > > for both PUI and Staff records. I believe you are suggesting it would most > easily be found using 1 and 1? I can see where that could take a long > time. But it if is going to choke over and over on the same record, then > that may be the best way to address it. > > Do you think if I just did staff indexing without PUI, that it would be > identified faster? Or could it pass the staff side but then die on PUI > later? > > I hope to try some of these ideas after hours today, so if you can confirm > that I've got the right idea, that would help. > > Tom > > > On Tue, May 10, 2022 at 2:17 PM Blake Carver > wrote: > > > Is this possible? > > Short answer, Yes, it's possible your indexer is starting over. > > Long answer. This can be tricky to figure out. Something is wrong, the > indexer never wants to do that. Sometimes "something" "bad" gets into > ArchivesSpace and the indexer will just crash and start over. The problem > is the "something" can be anything and the "bad" can be hard to figure out. > The more stuff you have in your DB, the harder it is to figure out. > > First, I'd make sure this is happening. Your logs should make it obvious. > You might see some FATAL errors just before it starts over. You MIGHT be > able to narrow it down from that. That is, what group of records had that > error in the logs? Maybe that narrows it down enough. You just got lucky! > > I don't think I've ever been so lucky. What I'd do next is set your > loglevel to DEBUG and restart. If you're feeling lucky or just impatient or > both, leave the indexer speed as is. You'll get more details out of the > logs and you should be able to narrow it down better. Ideally, you want to > run the indexers at 1x1, which means it could take forrreeevverrrrr to get > back around to the crash again. If you're lucky, it'll crash on a record, > you'll go look at that record, the problem will be obvious, and there will > be much rejoicing. With it running 1x1 you should see exactly what's > causing the fail. If it's not crashing on the same record every time.... > ugh. That's an even longer answer. > > > > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Tom > Hanstra > *Sent:* Tuesday, May 10, 2022 10:23 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > I don't look at the logs a lot unless there are issues with ArchivesSpace, > so maybe this is something normal. But, after a restart due to some > complaints about database connectivity, it looks like our ArchivesSpace > instance has decided to do a full reindex. The index log sure looks as if > it is starting from scratch and running through the indexing of both PUI > and Staff indexes. > > Is this possible? Is it something that happens periodically and I just > did not notice it? Nothing has changed in my data directory, so I don't see > any reason for indexing to occur. Yet that is what the logs show. > > If it is doing this for some reason, and knowing that we restart > periodically, it seems like we will get into a loop where indexing just > keeps happening all the time. Also, it would be helpful to understand what > caused this to happen. > > Any thoughts or experiences from those who have run this for longer would > be appreciated. I'd like to understand if it would be a good idea to clear > the data directory and perform a full index over the weekend rather than an > unexpected and possibly never ending round in the background. > > Thanks, > Tom > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > > _______________________________________________ > Archivesspace_Users_Group mailing listArchivesspace_Users_Group at lyralists.lyrasis.orghttp://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -- *Tom Hanstra* *Sr. Systems Administrator* hanstra at nd.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From Corey.Schmidt at uga.edu Mon May 16 16:24:14 2022 From: Corey.Schmidt at uga.edu (Corey Schmidt) Date: Mon, 16 May 2022 20:24:14 +0000 Subject: [Archivesspace_Users_Group] collection editing reports? In-Reply-To: References: Message-ID: Karen, If you're running ArchivesSpace 3.2.0, you may be able to use the custom reports feature to get this info from the archival objects table, but someone else here might be able to confirm this as I haven't use it much myself. Attached links go to the Help Center. If you're not on 3.2.0, you could get that info by querying the SQL database, searching specifically in the archival_object table looking at the fields: last_modified_by and system_mtime, sorting those by system_mtime to see the most recent changes. The tricky bit is capturing ALL the archival objects (series, items, files, etc.) for that specific collection. Since you want to capture not just the top-level children (series), but all the items within those series recursively down, that means you have to build your query to look for archival objects whose parents and grandparents and up and up eventually link to that specific collection. In this case, you would be looking at the parent_id (the ASpace ID of the parent of the item you're looking at) and the root_record_id (the ID of the collection that ArchivesSpace assigned it, aka the end # of the URI repositories/2/resources/{root_record_id} fields. I know I've come across this issue before, but I can't remember if I've built a query that can do this. Let me know if this is something you want to pursue and I can dig around to see if I have something. Corey Corey Schmidt Special Collections Libraries | Project Management Librarian/Archivist Corey.Schmidt at uga.edu ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Karen Urbec Sent: Monday, May 16, 2022 10:34 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] collection editing reports? [EXTERNAL SENDER - PROCEED CAUTIOUSLY] Hi Everyone, I have a question about running edit reports in ArchivesSpace. What I mean is, when looking at a large collection (with many series and items), is there a report I can run to see which items were last edited, and when, and by whom? thanks! Karen Karen Urbec (she/her) Institution Archivist, MBLWHOI Library Woods Hole Oceanographic Institution MS#8, phone:508-289-2269 https://orcid.org/0000-0001-6673-4478 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brijmcla at iu.edu Mon May 16 16:49:05 2022 From: brijmcla at iu.edu (McLaughlin, Brianna Jean) Date: Mon, 16 May 2022 20:49:05 +0000 Subject: [Archivesspace_Users_Group] collection editing reports? In-Reply-To: References: Message-ID: Hi everyone, For what it's worth, I opened a ticket awhile back about having access to editorial provenance. Feel free to comment or vote if you think it would be helpful in your situation. https://archivesspace.atlassian.net/browse/ANW-1386 Thanks, Bri McLaughlin, she/her/hers Visiting Metadata Services Librarian Indiana University 812-856-3321 From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Corey Schmidt Sent: Monday, May 16, 2022 4:24 PM To: Archivesspace Users Group Subject: [External] Re: [Archivesspace_Users_Group] collection editing reports? This message was sent from a non-IU address. Please exercise caution when clicking links or opening attachments from external sources. Karen, If you're running ArchivesSpace 3.2.0, you may be able to use the custom reports feature to get this info from the archival objects table, but someone else here might be able to confirm this as I haven't use it much myself. Attached links go to the Help Center. If you're not on 3.2.0, you could get that info by querying the SQL database, searching specifically in the archival_object table looking at the fields: last_modified_by and system_mtime, sorting those by system_mtime to see the most recent changes. The tricky bit is capturing ALL the archival objects (series, items, files, etc.) for that specific collection. Since you want to capture not just the top-level children (series), but all the items within those series recursively down, that means you have to build your query to look for archival objects whose parents and grandparents and up and up eventually link to that specific collection. In this case, you would be looking at the parent_id (the ASpace ID of the parent of the item you're looking at) and the root_record_id (the ID of the collection that ArchivesSpace assigned it, aka the end # of the URI repositories/2/resources/{root_record_id} fields. I know I've come across this issue before, but I can't remember if I've built a query that can do this. Let me know if this is something you want to pursue and I can dig around to see if I have something. Corey Corey Schmidt Special Collections Libraries | Project Management Librarian/Archivist Corey.Schmidt at uga.edu ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Karen Urbec > Sent: Monday, May 16, 2022 10:34 AM To: archivesspace_users_group at lyralists.lyrasis.org > Subject: [Archivesspace_Users_Group] collection editing reports? [EXTERNAL SENDER - PROCEED CAUTIOUSLY] Hi Everyone, I have a question about running edit reports in ArchivesSpace. What I mean is, when looking at a large collection (with many series and items), is there a report I can run to see which items were last edited, and when, and by whom? thanks! Karen Karen Urbec (she/her) Institution Archivist, MBLWHOI Library Woods Hole Oceanographic Institution MS#8, phone:508-289-2269 https://orcid.org/0000-0001-6673-4478 -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake.carver at lyrasis.org Mon May 16 17:19:11 2022 From: blake.carver at lyrasis.org (Blake Carver) Date: Mon, 16 May 2022 21:19:11 +0000 Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 In-Reply-To: References: Message-ID: That could be it, looks like some kind of "funny" character ArchivesSpace doesn't like in there probably. Do the "Indexed x of x whatever " numbers start over right there in the log? You should see what record it was working on just before there. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Tom Hanstra Sent: Monday, May 16, 2022 10:43 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 I've been monitoring logs and have run into a couple of instances where I receive this type of error: E, [2022-05-16T08:57:57.207392 #5273] ERROR -- : Thread-3962: Unhandled exception! E, [2022-05-16T08:57:57.207810 #5273] ERROR -- : invalid byte sequence in UTF-8 and then a lot of detail. Are these errors with data that should be addressed? I'm still in DEBUG mode in the backend log but it is not clear how to figure out which record(s) are being flagged. What am I looking for? Thanks, Tom On Thu, May 12, 2022 at 8:59 AM Blake Carver > wrote: > Could it be that we added a big record which is now having issues being extracted. Or a corrupted record which is causing such issues? I don't think so? It could be, but those errors make me think there's something else going on with the DB, or maybe the network between the application and DB server? I'm not really sure what the problem is, but it seems more like a hardware/network/server issue than an ArchivesSpace issue. I can't be sure, but those errors don't look like ArchivesSpace troubles to me. Those are pretty common errors, so I'd do some searching around to see what you can find to troubleshoot. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Wednesday, May 11, 2022 9:30 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Thanks again for your help. Late yesterday, both indexes indicated completion so I thought maybe things were going to be OK. Consequently, I did not do much in terms of testing. This morning, the logs again had errors, however. In the logs, I found this error in the indexer log: I, [2022-05-10T21:36:07.181427 #30003] INFO -- : Thread-2890: Staff Indexer [2022-05-10 21:36:07 -0400] Index round complete I, [2022-05-10T21:36:37.182006 #30003] INFO -- : Thread-2890: Staff Indexer [2022-05-10 21:36:37 -0400] Running index round E, [2022-05-10T21:36:37.283423 #30003] ERROR -- : Thread-2890: uri:classloader:/jsonmodel_client.rb:493:in `all' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:154:in `run_index_round' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:283:in `run' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/main.rb:32:in `block in main' E, [2022-05-10T21:36:37.284431 #30003] ERROR -- : Thread-2890: #> wrote: Indexing can also fail at the commit stage, not related to any one record. That is when ArchivesSpace tells Solr to transfer changes made in memory to storage. It does that at several points in the indexing process, but the longest one is at the end of the PUI indexer's run. If, because you've got a lot of records, or slow storage on your Solr server, it takes longer it respond than the value of AppConfig[:indexer_solr_timeout_seconds], it will start all over again, and potentially go into a loop. The workaround is to increase the timeout. You might not notice you've got enough records to cause this until you do a full re-index, or someone edits something linked to most or all records (e.g. a repository, or a very widely-used subject), triggering the re-indexing of most of the system's records. Andrew. On 10/05/2022 22:06, Blake Carver wrote: 1x1 would mean setting both records_per_thread and thread_count to 1. Having loglevel on debug and running at 1x1, you'll be able to see exactly which thing is being indexed as it happens, and when it crashes, you'll see what it was working through at the time. PUI will always take longer, and a VERY long time 1x1, but unless you're sure which indexer is crashing, I'd switch them both up. You can just `grep Indexed archivesspace.out` after it's running and watch those numbers. As long as they're going up, all is well. It is also possible that it will finish without crashing running so slow as well. I've seen that happen with LARGE records. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Tom Hanstra Sent: Tuesday, May 10, 2022 4:15 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Thanks, Blake. Turns out we did add quite a few records recently, so maybe there was something in there that it did not like all that much. How can you tell which record it is choking on? Is that your "1x1" suggestion? Or does the DEBUG option make that more clear? I have my indexing set to: AppConfig[:indexer_records_per_thread] = 25 AppConfig[:indexer_thread_count] = 2 for both PUI and Staff records. I believe you are suggesting it would most easily be found using 1 and 1? I can see where that could take a long time. But it if is going to choke over and over on the same record, then that may be the best way to address it. Do you think if I just did staff indexing without PUI, that it would be identified faster? Or could it pass the staff side but then die on PUI later? I hope to try some of these ideas after hours today, so if you can confirm that I've got the right idea, that would help. Tom On Tue, May 10, 2022 at 2:17 PM Blake Carver > wrote: > Is this possible? Short answer, Yes, it's possible your indexer is starting over. Long answer. This can be tricky to figure out. Something is wrong, the indexer never wants to do that. Sometimes "something" "bad" gets into ArchivesSpace and the indexer will just crash and start over. The problem is the "something" can be anything and the "bad" can be hard to figure out. The more stuff you have in your DB, the harder it is to figure out. First, I'd make sure this is happening. Your logs should make it obvious. You might see some FATAL errors just before it starts over. You MIGHT be able to narrow it down from that. That is, what group of records had that error in the logs? Maybe that narrows it down enough. You just got lucky! I don't think I've ever been so lucky. What I'd do next is set your loglevel to DEBUG and restart. If you're feeling lucky or just impatient or both, leave the indexer speed as is. You'll get more details out of the logs and you should be able to narrow it down better. Ideally, you want to run the indexers at 1x1, which means it could take forrreeevverrrrr to get back around to the crash again. If you're lucky, it'll crash on a record, you'll go look at that record, the problem will be obvious, and there will be much rejoicing. With it running 1x1 you should see exactly what's causing the fail. If it's not crashing on the same record every time.... ugh. That's an even longer answer. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Tuesday, May 10, 2022 10:23 AM To: Archivesspace Users Group > Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 I don't look at the logs a lot unless there are issues with ArchivesSpace, so maybe this is something normal. But, after a restart due to some complaints about database connectivity, it looks like our ArchivesSpace instance has decided to do a full reindex. The index log sure looks as if it is starting from scratch and running through the indexing of both PUI and Staff indexes. Is this possible? Is it something that happens periodically and I just did not notice it? Nothing has changed in my data directory, so I don't see any reason for indexing to occur. Yet that is what the logs show. If it is doing this for some reason, and knowing that we restart periodically, it seems like we will get into a loop where indexing just keeps happening all the time. Also, it would be helpful to understand what caused this to happen. Any thoughts or experiences from those who have run this for longer would be appreciated. I'd like to understand if it would be a good idea to clear the data directory and perform a full index over the weekend rather than an unexpected and possibly never ending round in the background. Thanks, Tom -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake.carver at lyrasis.org Mon May 16 17:20:30 2022 From: blake.carver at lyrasis.org (Blake Carver) Date: Mon, 16 May 2022 21:20:30 +0000 Subject: [Archivesspace_Users_Group] Browser Access Not Working In-Reply-To: References: Message-ID: That sounds like it's not running at all. Check the archivesspace.out file in the logs directory for errors. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Heidi R. Pettitt Sent: Friday, May 13, 2022 6:00 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Browser Access Not Working Thanks to everyone that has responded. Kevin added the following details this afternoon: I?m using the instructions linked below. I?m stuck on Step #11 which says to wait until you see port 8080 min a listening state and it never happens. Is there a step I?m missing? https://github.com/timpetro/archivesspace-install/blob/main/Install%20ArchivesSpace%20on%20Windows.txt Thanks, ~ Heidi From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Heidi R. Pettitt Sent: Thursday, May 12, 2022 10:03 AM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Browser Access Not Working Hi All, My IT department is having trouble setting up ArchivesSpace and sent me the following details: The issue I?m having is I?m trying to access ArchivesSpace through a web browser by typing in Http://IP Address of my Archives Space server:8080. This is supposed to bring me to an Archives Space login in web page but it says it is unable to connect. When I enter the command netstat -an -p tcp | find ?8080? at a command prompt, it is not showing anything which means port 8080 is not listening. I don?t know what to do to get port 8080 to listen. Does anyone have any suggestions for what?s going on and how to fix it? You can reply to this email and I?ll forward the information to him or you can email him at kevin.kraus at loras.edu. Thanks, ~Heidi HEIDI PETTITT (she/her) Director of the Center for Dubuque History Access Services & Special Collections Librarian LORAS COLLEGE Library/Center for Dubuque History Miller Academic Resource Center 154 1450 Alta Vista Dubuque, IA 52001 O: 563.588.7873 Meet With Me! http://library.loras.edu/ CONFIDENTIALITY NOTICE: This email, including any attachments, is the property of Loras College. The information may be legally privileged and/or confidential and is intended solely for the use of the addressee. If you are not the intended recipient be advised that any unauthorized disclosure, copying, distribution or use of the contents herein is strictly prohibited. If you have received this message in error, please notify the sender immediately and destroy all electronic and hard copies of the communication, including attachments. CONFIDENTIALITY NOTICE: This email, including any attachments, is the property of Loras College. The information may be legally privileged and/or confidential and is intended solely for the use of the addressee. If you are not the intended recipient be advised that any unauthorized disclosure, copying, distribution or use of the contents herein is strictly prohibited. If you have received this message in error, please notify the sender immediately and destroy all electronic and hard copies of the communication, including attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.morrison at bodleian.ox.ac.uk Tue May 17 03:58:57 2022 From: andrew.morrison at bodleian.ox.ac.uk (Andrew Morrison) Date: Tue, 17 May 2022 08:58:57 +0100 Subject: [Archivesspace_Users_Group] collection editing reports? In-Reply-To: References: Message-ID: <10741a1d-d095-60ad-9fd4-9245f7371d58@bodleian.ox.ac.uk> You can enter something like the following in the simple search box in the staff interface: resource:"/repositories/2/resources/28" That will find all the archival objects in the resource with the ID of 28 (you need to have already selected whichever repository in your system has the ID of 2, otherwise it'll find nothing.) In your case, it'll find all the subrecords of this collection: http://archives.mblwhoilibrary.org/repositories/2/resources/28 Then sort by Modified-Descending to list the last-edited records first. The "Audit Information" column shows the when and whom of each record's creation and last modification. If that column isn't being displayed, you can select it in the "Search Columns" section of your User Preferences. Obviously it will not show any archival objects that have been deleted or moved to another resource. Nor will it tell you about changes made in any digital objects or containers which are linked to the archival objects. Andrew. On 16/05/2022 15:34, Karen Urbec wrote: > Hi Everyone, > I have a question about running edit reports in ArchivesSpace. What I > mean is, when looking at a large collection (with many series and > items), is there a report I can run to see which items were last > edited, and when, and by whom? > thanks! > Karen > > Karen Urbec (she/her) > > Institution Archivist, MBLWHOI Library > > Woods Hole Oceanographic Institution > > MS#8, phone:508-289-2269 > > https://orcid.org/0000-0001-6673-4478 > > > > _______________________________________________ > 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: From karen.urbec at whoi.edu Tue May 17 08:01:20 2022 From: karen.urbec at whoi.edu (Karen Urbec) Date: Tue, 17 May 2022 12:01:20 +0000 Subject: [Archivesspace_Users_Group] collection editing reports? In-Reply-To: <10741a1d-d095-60ad-9fd4-9245f7371d58@bodleian.ox.ac.uk> References: <10741a1d-d095-60ad-9fd4-9245f7371d58@bodleian.ox.ac.uk> Message-ID: thanks everyone! this is very helpful! ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Andrew Morrison Sent: Tuesday, May 17, 2022 3:58 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] collection editing reports? You can enter something like the following in the simple search box in the staff interface: resource:"/repositories/2/resources/28" That will find all the archival objects in the resource with the ID of 28 (you need to have already selected whichever repository in your system has the ID of 2, otherwise it'll find nothing.) In your case, it'll find all the subrecords of this collection: http://archives.mblwhoilibrary.org/repositories/2/resources/28 Then sort by Modified-Descending to list the last-edited records first. The "Audit Information" column shows the when and whom of each record's creation and last modification. If that column isn't being displayed, you can select it in the "Search Columns" section of your User Preferences. Obviously it will not show any archival objects that have been deleted or moved to another resource. Nor will it tell you about changes made in any digital objects or containers which are linked to the archival objects. Andrew. On 16/05/2022 15:34, Karen Urbec wrote: Hi Everyone, I have a question about running edit reports in ArchivesSpace. What I mean is, when looking at a large collection (with many series and items), is there a report I can run to see which items were last edited, and when, and by whom? thanks! Karen Karen Urbec (she/her) Institution Archivist, MBLWHOI Library Woods Hole Oceanographic Institution MS#8, phone:508-289-2269 https://orcid.org/0000-0001-6673-4478 _______________________________________________ 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: From Jessica.Crouch at lyrasis.org Tue May 17 12:16:27 2022 From: Jessica.Crouch at lyrasis.org (Jessica Crouch) Date: Tue, 17 May 2022 16:16:27 +0000 Subject: [Archivesspace_Users_Group] Upcoming Webinar: Using ArchivesSpace to create EAC-CPF records (90 minutes) In-Reply-To: References: <699EEA2C-4D25-4A19-8DB6-27C4BC2CD451@lyrasis.org> Message-ID: Dear ArchivesSpace users, There is still time to register for next week?s webinar on using ArchivesSpace to create EAC-CPF records. The next ArchivesSpace webinar will be a 90-minute learning opportunity on May 24th at 2:00pm ET/11:00am PT led by Regine Heberlein, Library IT Data Analyst at Princeton University, and Christine Di Bella, ArchivesSpace Program Manager, demonstrating how to create valid EAC-CPF records using ArchivesSpace and offering some tips and tricks for making the process easier within your repository. Originally scheduled for February 9th, this 90 minute learning opportunity has been postponed to May 24, 2022, at 2:00pm ET/11:00am PT. If you?ve already registered for this webinar, your registration has been transferred to this new date. If you need to cancel your registration, you can do so using the connection information provided via Zoom. Date: May 24, 2022 Time: 2:00pm ? 3:30pm ET (11:00am ? 12:30pm PT) Where: Zoom Registration: https://lyrasis.zoom.us/webinar/register/WN_e777kyjtQ6qjBMWeiiTWmg This webinar will be recorded and made available on the ArchivesSpace YouTube channel. Webinar description: The recent expansion of the agents module in ArchivesSpace greatly expanded the application?s support for the metadata standard Encoded Archival Context ? Corporate Bodies, Persons, and Families (EAC-CPF) and the potential for exchanging these records with other systems, including Social Networks and Archival Context (SNAC). Taking full advantage of this potential requires some work on the record creator?s part as ArchivesSpace?s requirements for creating agent records remain minimal. This learning opportunity will demonstrate how to create valid EAC-CPF records using ArchivesSpace and offer some tips and tricks for making the process easier within your repository. An open discussion and Q&A will follow. This learning opportunity introduces EAC-CPF in the context of ArchivesSpace but is not intended to be a full overview of the standard. Resources for learning more about EAC-CPF include: * Encoded Archival Standards: A Primer: https://www.youtube.com/watch?v=WYWQeBRnhz0 * EAC-CPF Community and Support page: https://eac.staatsbibliothek-berlin.de/community-and-mailinglist/ * EAC-CPF Tag Library: https://eac.staatsbibliothek-berlin.de/schemata-and-tag-library/ NOTE: This learning opportunity assumes basic knowledge of ArchivesSpace, including an understanding of agent records. If you do not have this, we recommend watching the videos of the Basics workshop series, available on YouTube at https://www.youtube.com/playlist?list=PL3cxupmXL7WiHyMc0uFmsCEIVOQmrI7FL. We will not be able to answer general questions about ArchivesSpace or specific questions about individual ArchivesSpace implementations during this session. Who should attend: Anyone interested in using ArchivesSpace to create valid EAC-CPF records. Please email ArchivesSpaceHome at lyrasis.org if you have any questions. Best, Jessica Jessica Dowd Crouch Community Engagement Coordinator for ArchivesSpace jessica.crouch at lyrasis.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From hanstra at nd.edu Wed May 18 15:21:38 2022 From: hanstra at nd.edu (Tom Hanstra) Date: Wed, 18 May 2022 15:21:38 -0400 Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 In-Reply-To: References: Message-ID: Blake and others, Overall, we went for a week or so with no errors in terms of re-indexing. I'm looking into some database timeouts which are occurring periodically (AS and our database server are in two different locations) but with the connection getting re-established, I can work to address that separately. But last night we did run into some errors which we are trying to track down. A couple of things: - Even though the config setting is for DEBUG, the indexer log is only showing INFO. Should there be more than that? - If the log says: I, [2022-05-17T22:27:11.756683 #5273] INFO -- : Thread-2890: Staff Indexer [2022-05-17 22:27:11 -0400] ~~~ Indexed 216 of 20898 archival_object records in repository UNDA immediately followed by an error, how do we determine which record that is in ArchivesSpace? We are not sure how to find the record which is indicated in the log. Thanks again, Tom On Mon, May 16, 2022 at 5:19 PM Blake Carver wrote: > That could be it, looks like some kind of "funny" character ArchivesSpace > doesn't like in there probably. Do the "Indexed x of x whatever " numbers > start over right there in the log? > You should see what record it was working on just before there. > > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Tom > Hanstra > *Sent:* Monday, May 16, 2022 10:43 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > I've been monitoring logs and have run into a couple of instances where I > receive this type of error: > > E, [2022-05-16T08:57:57.207392 #5273] ERROR -- : Thread-3962: Unhandled > exception! > E, [2022-05-16T08:57:57.207810 #5273] ERROR -- : > invalid byte sequence in UTF-8 > > and then a lot of detail. Are these errors with data that should be > addressed? I'm still in DEBUG mode in the backend log but it is not clear > how to figure out which record(s) are being flagged. What am I looking for? > > Thanks, > Tom > > On Thu, May 12, 2022 at 8:59 AM Blake Carver > wrote: > > > Could it be that we added a big record which is now having issues being > extracted. Or a corrupted record which is causing such issues? > > I don't think so? It could be, but those errors make me think there's > something else going on with the DB, or maybe the network between the > application and DB server? I'm not really sure what the problem is, but it > seems more like a hardware/network/server issue than an ArchivesSpace > issue. I can't be sure, but those errors don't look like ArchivesSpace > troubles to me. Those are pretty common errors, so I'd do some searching > around to see what you can find to troubleshoot. > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Tom > Hanstra > *Sent:* Wednesday, May 11, 2022 9:30 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > Thanks again for your help. > > Late yesterday, both indexes indicated completion so I thought maybe > things were going to be OK. Consequently, I did not do much in terms of > testing. > > This morning, the logs again had errors, however. In the logs, I found > this error in the indexer log: > > I, [2022-05-10T21:36:07.181427 #30003] INFO -- : Thread-2890: Staff > Indexer [2022-05-10 21:36:07 -0400] Index round complete > I, [2022-05-10T21:36:37.182006 #30003] INFO -- : Thread-2890: Staff > Indexer [2022-05-10 21:36:37 -0400] Running index round > E, [2022-05-10T21:36:37.283423 #30003] ERROR -- : Thread-2890: > uri:classloader:/jsonmodel_client.rb:493:in `all' > /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:154:in > `run_index_round' > /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:283:in > `run' > /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/main.rb:32:in > `block in main' > E, [2022-05-10T21:36:37.284431 #30003] ERROR -- : Thread-2890: > # conflict: Java::JavaSql::SQLNonTransientConnectionException: No operations > allowed after connection closed."]}} > > and in the backup log there were issues with timeouts retrieving a record: > > Java::ComMysqlCjJdbcExceptions::CommunicationsException: The last packet > successfully received from the server was 1,759 milliseconds ago. The last > packet sent successfully to the server was 28,849,143 milliseconds ago. is > longer than the server configured value of 'wait_timeout'. You should > consider either expiring and/or testing connection validity before use in > your application, increasing the server configured values for client > timeouts, or using the Connector/J connection property 'autoReconnect=true' > to avoid this problem. > > Could it be that we added a big record which is now having issues being > extracted. Or a corrupted record which is causing such issues? > > I've now restarted with the 1x1 and DEBUG on and only staff indexing and > it is still thinking indexing is complete. I'll keep things going this way > until we hit an error again and hopefully that will give additional > information. > > I'll also look into the "autoReconnect=true" piece, since we seem to have > a situation where, once this happens, nothing more works until a restart. > > Thanks again for any thoughts on this, > Tom > > On Wed, May 11, 2022 at 5:03 AM Andrew Morrison < > andrew.morrison at bodleian.ox.ac.uk> wrote: > > Indexing can also fail at the commit stage, not related to any one record. > That is when ArchivesSpace tells Solr to transfer changes made in memory to > storage. It does that at several points in the indexing process, but the > longest one is at the end of the PUI indexer's run. If, because you've got > a lot of records, or slow storage on your Solr server, it takes longer it > respond than the value of AppConfig[:indexer_solr_timeout_seconds], it will > start all over again, and potentially go into a loop. The workaround is to > increase the timeout. > > > You might not notice you've got enough records to cause this until you do > a full re-index, or someone edits something linked to most or all records > (e.g. a repository, or a very widely-used subject), triggering the > re-indexing of most of the system's records. > > > Andrew. > > > > On 10/05/2022 22:06, Blake Carver wrote: > > 1x1 would mean setting both records_per_thread and thread_count to 1. > Having loglevel on debug and running at 1x1, you'll be able to see exactly > which thing is being indexed as it happens, and when it crashes, you'll see > what it was working through at the time. > > PUI will always take longer, and a VERY long time 1x1, but unless you're > sure which indexer is crashing, I'd switch them both up. > > You can just `grep Indexed archivesspace.out` after it's running and watch > those numbers. As long as they're going up, all is well. > > It is also possible that it will finish without crashing running so slow > as well. I've seen that happen with LARGE records. > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org > > on behalf of > Tom Hanstra > *Sent:* Tuesday, May 10, 2022 4:15 PM > *To:* Archivesspace Users Group > > > *Subject:* Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > Thanks, Blake. > > Turns out we did add quite a few records recently, so maybe there was > something in there that it did not like all that much. > > How can you tell which record it is choking on? Is that your "1x1" > suggestion? Or does the DEBUG option make that more clear? I have my > indexing set to: > > AppConfig[:indexer_records_per_thread] = 25 > AppConfig[:indexer_thread_count] = 2 > > for both PUI and Staff records. I believe you are suggesting it would most > easily be found using 1 and 1? I can see where that could take a long > time. But it if is going to choke over and over on the same record, then > that may be the best way to address it. > > Do you think if I just did staff indexing without PUI, that it would be > identified faster? Or could it pass the staff side but then die on PUI > later? > > I hope to try some of these ideas after hours today, so if you can confirm > that I've got the right idea, that would help. > > Tom > > > On Tue, May 10, 2022 at 2:17 PM Blake Carver > wrote: > > > Is this possible? > > Short answer, Yes, it's possible your indexer is starting over. > > Long answer. This can be tricky to figure out. Something is wrong, the > indexer never wants to do that. Sometimes "something" "bad" gets into > ArchivesSpace and the indexer will just crash and start over. The problem > is the "something" can be anything and the "bad" can be hard to figure out. > The more stuff you have in your DB, the harder it is to figure out. > > First, I'd make sure this is happening. Your logs should make it obvious. > You might see some FATAL errors just before it starts over. You MIGHT be > able to narrow it down from that. That is, what group of records had that > error in the logs? Maybe that narrows it down enough. You just got lucky! > > I don't think I've ever been so lucky. What I'd do next is set your > loglevel to DEBUG and restart. If you're feeling lucky or just impatient or > both, leave the indexer speed as is. You'll get more details out of the > logs and you should be able to narrow it down better. Ideally, you want to > run the indexers at 1x1, which means it could take forrreeevverrrrr to get > back around to the crash again. If you're lucky, it'll crash on a record, > you'll go look at that record, the problem will be obvious, and there will > be much rejoicing. With it running 1x1 you should see exactly what's > causing the fail. If it's not crashing on the same record every time.... > ugh. That's an even longer answer. > > > > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Tom > Hanstra > *Sent:* Tuesday, May 10, 2022 10:23 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > I don't look at the logs a lot unless there are issues with ArchivesSpace, > so maybe this is something normal. But, after a restart due to some > complaints about database connectivity, it looks like our ArchivesSpace > instance has decided to do a full reindex. The index log sure looks as if > it is starting from scratch and running through the indexing of both PUI > and Staff indexes. > > Is this possible? Is it something that happens periodically and I just > did not notice it? Nothing has changed in my data directory, so I don't see > any reason for indexing to occur. Yet that is what the logs show. > > If it is doing this for some reason, and knowing that we restart > periodically, it seems like we will get into a loop where indexing just > keeps happening all the time. Also, it would be helpful to understand what > caused this to happen. > > Any thoughts or experiences from those who have run this for longer would > be appreciated. I'd like to understand if it would be a good idea to clear > the data directory and perform a full index over the weekend rather than an > unexpected and possibly never ending round in the background. > > Thanks, > Tom > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > > _______________________________________________ > Archivesspace_Users_Group mailing listArchivesspace_Users_Group at lyralists.lyrasis.orghttp://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -- *Tom Hanstra* *Sr. Systems Administrator* hanstra at nd.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From Corinne.Chatnik at nysed.gov Wed May 18 15:25:58 2022 From: Corinne.Chatnik at nysed.gov (Corinne Chatnik) Date: Wed, 18 May 2022 19:25:58 +0000 Subject: [Archivesspace_Users_Group] Errors Upgrading from 2.7.0 to 2.8.1 Message-ID: Hi, Trying to upgrade from 2.7.0 to 2.8.1 and we keep getting the same error repeated over and over for nearly every record and we don't know where to start looking. I've done a complete reindex and redid the database migration etc. The log file keeps repeating this: E, [2022-05-18T14:07:50.629287 #48326] ERROR -- : Thread-2902: Unhandled exception! E, [2022-05-18T14:07:50.630620 #48326] ERROR -- : comparison of NilClass with 0 failed org/jruby/RubyEnumerable.java:574:in `sort_by' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:347:in `find_by_participant' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:411:in `who_participates_with' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:545:in `related_records' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:170:in `find_subcontainer_barcodes' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:190:in `block in sequel_to_jsonmodel' org/jruby/RubyArray.java:1809:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:184:in `sequel_to_jsonmodel' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:336:in `block in resolve' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:335:in `block in resolve' org/jruby/RubyHash.java:1415:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:331:in `block in resolve' org/jruby/RubyGenerator.java:104:in `each' org/jruby/RubyEnumerator.java:396:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:247:in `block in fetch_records_by_uri' org/jruby/RubyHash.java:1415:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:241:in `fetch_records_by_uri' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:130:in `resolve_references' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:44:in `resolve_references' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/crud_helpers.rb:113:in `listing_response' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/crud_helpers.rb:68:in `handle_listing' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/controllers/archival_object.rb:97:in `block in ArchivesSpaceService' org/jruby/RubyBasicObject.java:2622:in `instance_eval' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:368:in `block in GET /repositories/:repo_id/archival_objects' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:105:in `block in open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:69:in `block in transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:204:in `_transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:179:in `block in transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/connection_pool/threaded.rb:91:in `hold' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/connecting.rb:270:in `synchronize' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:145:in `transaction' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:68:in `transaction' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:104:in `block in open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:101:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:426:in `block in DB' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:351:in `block in GET /repositories/:repo_id/archival_objects' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:319:in `block in GET /repositories/:repo_id/archival_objects' org/jruby/RubyMethod.java:115:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1635:in `block in compile!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:992:in `block in route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1011:in `route_eval' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:992:in `block in route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1040:in `block in process_route' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1038:in `process_route' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:990:in `block in route!' org/jruby/RubyArray.java:1809:in `each' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:989:in `route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1097:in `block in dispatch!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `block in invoke' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `invoke' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1094:in `dispatch!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:924:in `block in call!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `block in invoke' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `invoke' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:924:in `call!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:913:in `call' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:292:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/xss_header.rb:18:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/path_traversal.rb:16:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/json_csrf.rb:26:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/base.rb:50:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/base.rb:50:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/frame_options.rb:31:in `call' uri:classloader:/vendor/rack-2.2.3/rack/null_logger.rb:11:in `call' uri:classloader:/vendor/rack-2.2.3/rack/head.rb:12:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:194:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1957:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1502:in `block in call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1729:in `synchronize' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1502:in `call' uri:classloader:/vendor/rack-2.2.3/rack/urlmap.rb:74:in `block in call' org/jruby/RubyArray.java:1809:in `each' uri:classloader:/vendor/rack-2.2.3/rack/urlmap.rb:58:in `call' uri:classloader:/rack/handler/servlet.rb:22:in `call' Thanks! Corinne Chatnik Archivist Digital Strategies New York State Archives www.archives.nysed.gov | Corinne.Chatnik at nysed.gov Facebook | Twitter | New York Archives Magazine | YouTube Confidentiality Notice This email including all attachments is confidential and intended solely for the use of the individual or entity to which it is addressed. This communication may contain information that is protected from disclosure under State and/or Federal law. Please notify the sender immediately if you have received this communication in error and delete this email from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ron.VandenBranden at antwerpen.be Wed May 18 15:44:40 2022 From: Ron.VandenBranden at antwerpen.be (Ron Van den Branden) Date: Wed, 18 May 2022 19:44:40 +0000 Subject: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace Message-ID: <1bc9268864734e4b92ba20584ef975ff@antwerpen.be> Hi all, This is my first message to this group; apologies if this has been addressed before (tried my best researching the list archive at https://www.mail-archive.com/archivesspace_users_group at lyralists.lyrasis.org/). At my institution, we?re preparing a migration of data from a previous archival description system to ArchivesSpace. The previous system allowed for structured links between archival descriptions within the system. For example, resource A could point to resource B within the same system by means of a system identifier, which the system would resolve to a full link in the PUI. This is functioning in a similar way as Agents Links or Related Accessions sections in ArchivesSpace; only with a different record type (resources / archival objects instead of agents, resp. accessions). Please correct me if I?m wrong, but I don?t see an immediate equivalent mechanism in ArchivesSpace. This raises some questions: * Am I overlooking the obvious, and does ArchivesSpace provide a structured mechanism to point from a Resource / Archival Object to another Resource / Archival Object? * If not, I do see the External Documents section as a close fit, with the semantic drawback that these linked resources are not really external but rather internal. More substantially, though, External Documents only allows for a literal URL, which is less elegant, more error-prone, and less sustainable than the dynamically generated links provided via Agent Links or Related Accessions. * If not, is this something that?s on a development roadmap, or have others implemented this as a plug-in? Many thanks for your thoughts! Best, Ron Ron Van den Branden | functioneel analist - applicatiebeheerder Letterenhuis Stad Antwerpen | Talentontwikkeling en Vrijetijdsbeleving | Musea en Erfgoed Minderbroedersstraat 22, 2000 Antwerpen ? Grote Markt 1, 2000 Antwerpen gsm +32 0485 02 80 50 | tel. +32 3 222 93 30 letterenhuis.be | instagram | facebook Proclaimer Vergissen is menselijk. Dus als deze e-mail, samen met eventuele bijlagen, niet voor u bestemd is, vragen we u vriendelijk om dat te melden aan de afzender. Deze e-mail en de bijlagen zijn namelijk offici?le documenten van de stad Antwerpen. Ze kunnen vertrouwelijke of persoonlijke informatie bevatten. Als stad nemen we privacy heel serieus en willen we als een goede huisvader waken over de vertrouwelijkheid van documenten. Als u dit bericht per vergissing hebt ontvangen of ergens hebt gevonden, wees dan zo eerlijk om het meteen te verwijderen en het niet verder te verspreiden of te kopi?ren. -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake.carver at lyrasis.org Wed May 18 16:12:01 2022 From: blake.carver at lyrasis.org (Blake Carver) Date: Wed, 18 May 2022 20:12:01 +0000 Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 In-Reply-To: References: Message-ID: > - Even though the config setting is for DEBUG, the indexer log is only showing INFO. Should there be more than that? Yep. Something must not be quite right in the config, you should see DEBUG showing up in the logs. If it's running 1x1 AND on DEBUG you should see something better by the crash, you should be able to spot the record. I can't remember what exactly it looks like, but something like "indexed some/path/with/an/id/in/it/here" and then you can see the Resource or Archival Object ID in the line there. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Tom Hanstra Sent: Wednesday, May 18, 2022 3:21 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Blake and others, Overall, we went for a week or so with no errors in terms of re-indexing. I'm looking into some database timeouts which are occurring periodically (AS and our database server are in two different locations) but with the connection getting re-established, I can work to address that separately. But last night we did run into some errors which we are trying to track down. A couple of things: - Even though the config setting is for DEBUG, the indexer log is only showing INFO. Should there be more than that? - If the log says: I, [2022-05-17T22:27:11.756683 #5273] INFO -- : Thread-2890: Staff Indexer [2022-05-17 22:27:11 -0400] ~~~ Indexed 216 of 20898 archival_object records in repository UNDA immediately followed by an error, how do we determine which record that is in ArchivesSpace? We are not sure how to find the record which is indicated in the log. Thanks again, Tom On Mon, May 16, 2022 at 5:19 PM Blake Carver > wrote: That could be it, looks like some kind of "funny" character ArchivesSpace doesn't like in there probably. Do the "Indexed x of x whatever " numbers start over right there in the log? You should see what record it was working on just before there. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Monday, May 16, 2022 10:43 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 I've been monitoring logs and have run into a couple of instances where I receive this type of error: E, [2022-05-16T08:57:57.207392 #5273] ERROR -- : Thread-3962: Unhandled exception! E, [2022-05-16T08:57:57.207810 #5273] ERROR -- : invalid byte sequence in UTF-8 and then a lot of detail. Are these errors with data that should be addressed? I'm still in DEBUG mode in the backend log but it is not clear how to figure out which record(s) are being flagged. What am I looking for? Thanks, Tom On Thu, May 12, 2022 at 8:59 AM Blake Carver > wrote: > Could it be that we added a big record which is now having issues being extracted. Or a corrupted record which is causing such issues? I don't think so? It could be, but those errors make me think there's something else going on with the DB, or maybe the network between the application and DB server? I'm not really sure what the problem is, but it seems more like a hardware/network/server issue than an ArchivesSpace issue. I can't be sure, but those errors don't look like ArchivesSpace troubles to me. Those are pretty common errors, so I'd do some searching around to see what you can find to troubleshoot. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Wednesday, May 11, 2022 9:30 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Thanks again for your help. Late yesterday, both indexes indicated completion so I thought maybe things were going to be OK. Consequently, I did not do much in terms of testing. This morning, the logs again had errors, however. In the logs, I found this error in the indexer log: I, [2022-05-10T21:36:07.181427 #30003] INFO -- : Thread-2890: Staff Indexer [2022-05-10 21:36:07 -0400] Index round complete I, [2022-05-10T21:36:37.182006 #30003] INFO -- : Thread-2890: Staff Indexer [2022-05-10 21:36:37 -0400] Running index round E, [2022-05-10T21:36:37.283423 #30003] ERROR -- : Thread-2890: uri:classloader:/jsonmodel_client.rb:493:in `all' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:154:in `run_index_round' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:283:in `run' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/main.rb:32:in `block in main' E, [2022-05-10T21:36:37.284431 #30003] ERROR -- : Thread-2890: #> wrote: Indexing can also fail at the commit stage, not related to any one record. That is when ArchivesSpace tells Solr to transfer changes made in memory to storage. It does that at several points in the indexing process, but the longest one is at the end of the PUI indexer's run. If, because you've got a lot of records, or slow storage on your Solr server, it takes longer it respond than the value of AppConfig[:indexer_solr_timeout_seconds], it will start all over again, and potentially go into a loop. The workaround is to increase the timeout. You might not notice you've got enough records to cause this until you do a full re-index, or someone edits something linked to most or all records (e.g. a repository, or a very widely-used subject), triggering the re-indexing of most of the system's records. Andrew. On 10/05/2022 22:06, Blake Carver wrote: 1x1 would mean setting both records_per_thread and thread_count to 1. Having loglevel on debug and running at 1x1, you'll be able to see exactly which thing is being indexed as it happens, and when it crashes, you'll see what it was working through at the time. PUI will always take longer, and a VERY long time 1x1, but unless you're sure which indexer is crashing, I'd switch them both up. You can just `grep Indexed archivesspace.out` after it's running and watch those numbers. As long as they're going up, all is well. It is also possible that it will finish without crashing running so slow as well. I've seen that happen with LARGE records. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Tom Hanstra Sent: Tuesday, May 10, 2022 4:15 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Thanks, Blake. Turns out we did add quite a few records recently, so maybe there was something in there that it did not like all that much. How can you tell which record it is choking on? Is that your "1x1" suggestion? Or does the DEBUG option make that more clear? I have my indexing set to: AppConfig[:indexer_records_per_thread] = 25 AppConfig[:indexer_thread_count] = 2 for both PUI and Staff records. I believe you are suggesting it would most easily be found using 1 and 1? I can see where that could take a long time. But it if is going to choke over and over on the same record, then that may be the best way to address it. Do you think if I just did staff indexing without PUI, that it would be identified faster? Or could it pass the staff side but then die on PUI later? I hope to try some of these ideas after hours today, so if you can confirm that I've got the right idea, that would help. Tom On Tue, May 10, 2022 at 2:17 PM Blake Carver > wrote: > Is this possible? Short answer, Yes, it's possible your indexer is starting over. Long answer. This can be tricky to figure out. Something is wrong, the indexer never wants to do that. Sometimes "something" "bad" gets into ArchivesSpace and the indexer will just crash and start over. The problem is the "something" can be anything and the "bad" can be hard to figure out. The more stuff you have in your DB, the harder it is to figure out. First, I'd make sure this is happening. Your logs should make it obvious. You might see some FATAL errors just before it starts over. You MIGHT be able to narrow it down from that. That is, what group of records had that error in the logs? Maybe that narrows it down enough. You just got lucky! I don't think I've ever been so lucky. What I'd do next is set your loglevel to DEBUG and restart. If you're feeling lucky or just impatient or both, leave the indexer speed as is. You'll get more details out of the logs and you should be able to narrow it down better. Ideally, you want to run the indexers at 1x1, which means it could take forrreeevverrrrr to get back around to the crash again. If you're lucky, it'll crash on a record, you'll go look at that record, the problem will be obvious, and there will be much rejoicing. With it running 1x1 you should see exactly what's causing the fail. If it's not crashing on the same record every time.... ugh. That's an even longer answer. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Tuesday, May 10, 2022 10:23 AM To: Archivesspace Users Group > Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 I don't look at the logs a lot unless there are issues with ArchivesSpace, so maybe this is something normal. But, after a restart due to some complaints about database connectivity, it looks like our ArchivesSpace instance has decided to do a full reindex. The index log sure looks as if it is starting from scratch and running through the indexing of both PUI and Staff indexes. Is this possible? Is it something that happens periodically and I just did not notice it? Nothing has changed in my data directory, so I don't see any reason for indexing to occur. Yet that is what the logs show. If it is doing this for some reason, and knowing that we restart periodically, it seems like we will get into a loop where indexing just keeps happening all the time. Also, it would be helpful to understand what caused this to happen. Any thoughts or experiences from those who have run this for longer would be appreciated. I'd like to understand if it would be a good idea to clear the data directory and perform a full index over the weekend rather than an unexpected and possibly never ending round in the background. Thanks, Tom -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake.carver at lyrasis.org Wed May 18 16:13:45 2022 From: blake.carver at lyrasis.org (Blake Carver) Date: Wed, 18 May 2022 20:13:45 +0000 Subject: [Archivesspace_Users_Group] Errors Upgrading from 2.7.0 to 2.8.1 In-Reply-To: References: Message-ID: That looks pretty bad, not sure what it means, but I would start over, maybe something is missing or there's a bad plugin or some other mysterious thing has failed. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Corinne Chatnik Sent: Wednesday, May 18, 2022 3:25 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Errors Upgrading from 2.7.0 to 2.8.1 Hi, Trying to upgrade from 2.7.0 to 2.8.1 and we keep getting the same error repeated over and over for nearly every record and we don?t know where to start looking. I?ve done a complete reindex and redid the database migration etc. The log file keeps repeating this: E, [2022-05-18T14:07:50.629287 #48326] ERROR -- : Thread-2902: Unhandled exception! E, [2022-05-18T14:07:50.630620 #48326] ERROR -- : comparison of NilClass with 0 failed org/jruby/RubyEnumerable.java:574:in `sort_by' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:347:in `find_by_participant' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:411:in `who_participates_with' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:545:in `related_records' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:170:in `find_subcontainer_barcodes' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:190:in `block in sequel_to_jsonmodel' org/jruby/RubyArray.java:1809:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:184:in `sequel_to_jsonmodel' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:336:in `block in resolve' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:335:in `block in resolve' org/jruby/RubyHash.java:1415:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:331:in `block in resolve' org/jruby/RubyGenerator.java:104:in `each' org/jruby/RubyEnumerator.java:396:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:247:in `block in fetch_records_by_uri' org/jruby/RubyHash.java:1415:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:241:in `fetch_records_by_uri' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:130:in `resolve_references' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:44:in `resolve_references' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/crud_helpers.rb:113:in `listing_response' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/crud_helpers.rb:68:in `handle_listing' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/controllers/archival_object.rb:97:in `block in ArchivesSpaceService' org/jruby/RubyBasicObject.java:2622:in `instance_eval' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:368:in `block in GET /repositories/:repo_id/archival_objects' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:105:in `block in open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:69:in `block in transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:204:in `_transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:179:in `block in transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/connection_pool/threaded.rb:91:in `hold' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/connecting.rb:270:in `synchronize' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:145:in `transaction' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:68:in `transaction' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:104:in `block in open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:101:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:426:in `block in DB' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:351:in `block in GET /repositories/:repo_id/archival_objects' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:319:in `block in GET /repositories/:repo_id/archival_objects' org/jruby/RubyMethod.java:115:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1635:in `block in compile!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:992:in `block in route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1011:in `route_eval' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:992:in `block in route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1040:in `block in process_route' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1038:in `process_route' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:990:in `block in route!' org/jruby/RubyArray.java:1809:in `each' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:989:in `route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1097:in `block in dispatch!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `block in invoke' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `invoke' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1094:in `dispatch!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:924:in `block in call!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `block in invoke' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `invoke' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:924:in `call!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:913:in `call' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:292:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/xss_header.rb:18:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/path_traversal.rb:16:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/json_csrf.rb:26:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/base.rb:50:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/base.rb:50:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/frame_options.rb:31:in `call' uri:classloader:/vendor/rack-2.2.3/rack/null_logger.rb:11:in `call' uri:classloader:/vendor/rack-2.2.3/rack/head.rb:12:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:194:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1957:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1502:in `block in call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1729:in `synchronize' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1502:in `call' uri:classloader:/vendor/rack-2.2.3/rack/urlmap.rb:74:in `block in call' org/jruby/RubyArray.java:1809:in `each' uri:classloader:/vendor/rack-2.2.3/rack/urlmap.rb:58:in `call' uri:classloader:/rack/handler/servlet.rb:22:in `call' Thanks! Corinne Chatnik Archivist Digital Strategies New York State Archives www.archives.nysed.gov | Corinne.Chatnik at nysed.gov Facebook | Twitter | New York Archives Magazine | YouTube Confidentiality Notice This email including all attachments is confidential and intended solely for the use of the individual or entity to which it is addressed. This communication may contain information that is protected from disclosure under State and/or Federal law. Please notify the sender immediately if you have received this communication in error and delete this email from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahaywood at cca.qc.ca Wed May 18 16:49:53 2022 From: ahaywood at cca.qc.ca (Anna Haywood) Date: Wed, 18 May 2022 20:49:53 +0000 Subject: [Archivesspace_Users_Group] Items not showing up in search results filter References: Message-ID: Hello everyone, I am having some trouble with my search results filters. When I search by collection unique ID in ArchivesSpace and then filter by "archival object" on the left hand side, I receive an additional set of filters for "Level." Here I can filter by series, subseries, file, etc. However, for some time now, the level "item" does not show up as one of the filters. This is very odd because in my sandbox environment, the items does come up as an option in the Level filter. Both sandbox and production are on version 3.2.0. Does anyone have any theories about why this might be happening? Thanks in advance, Anna --- Anna Haywood Archiviste Archivist Centre Canadien d'Architecture Canadian Centre for Architecture 1920, rue Baile, Montr?al, Qu?bec, Canada, H3H 2S6 +1 5149397001x1368 cca.qc.ca Twitter | Instagram | Facebook | YouTube Comment pouvons-nous contribuer ? une approche plus collaborative du travail archivistique transnational? How can we contribute to a collaborative approach to transnational archival work? Inscrivez-vous pour recevoir de nos nouvelles. Sign up to get news from us. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.morrison at bodleian.ox.ac.uk Thu May 19 03:42:28 2022 From: andrew.morrison at bodleian.ox.ac.uk (Andrew Morrison) Date: Thu, 19 May 2022 08:42:28 +0100 Subject: [Archivesspace_Users_Group] Items not showing up in search results filter In-Reply-To: References: Message-ID: <1354732b-788b-6cb8-5f17-e84c29dad4d2@bodleian.ox.ac.uk> Presumably you are in the correct repository, otherwise your search for a particular collection wouldn't find anything. Is it a problem with just one specific collection, or all of them? If you don't do the search for a unique ID first, and instead just do a simple search for *, then filter to archival objects, do you still not get the "Item" option in Level facet? You could try a soft re-index, to rule out it being a problem with Solr being out-of-sync with MySQL: https://archivesspace.github.io/tech-docs/administration/indexes.html Andrew. On 18/05/2022 21:49, Anna Haywood wrote: > > Hello everyone, > > I am having some trouble with my search results filters. When I search > by collection unique ID in ArchivesSpace and then filter by ?archival > object? on the left hand side, I receive an additional set of filters > for ?Level.? Here I can filter by series, subseries, file, etc. > However, for some time now, the level ?item? does not show up as one > of the filters. This is very odd because in my sandbox environment, > the items does come up as an option in the Level filter. Both sandbox > and production are on version 3.2.0. > > Does anyone have any theories about why this might be happening? > > Thanks in advance, > > Anna > > --- > > *Anna Haywood > *Archiviste > Archivist > > *Centre Canadien d'Architecture > Canadian Centre for Architecture* > 1920, rue Baile, Montr?al, Qu?bec, Canada, H3H 2S6 > +1 5149397001x1368 > cca.qc.ca > > Twitter | Instagram > | Facebook > | YouTube > > > Comment pouvons-nous contribuer ? une approche plus collaborative du > travail archivistique transnational? > > How can we contribute to a collaborative approach to transnational > archival work? > > Inscrivez-vous > > pour recevoir de nos nouvelles. > Sign up > > to get news from us. > > > _______________________________________________ > 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: From brian.hoffman at lyrasis.org Thu May 19 07:52:28 2022 From: brian.hoffman at lyrasis.org (Brian Hoffman) Date: Thu, 19 May 2022 11:52:28 +0000 Subject: [Archivesspace_Users_Group] Errors Upgrading from 2.7.0 to 2.8.1 In-Reply-To: References: Message-ID: You could also try running this query in MySQL. If you get any results, that would likely be the problem: select id, aspace_relationship_position from top_container_link_rlshp where aspace_relationship_position is null; From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Blake Carver Date: Wednesday, May 18, 2022 at 4:13 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Errors Upgrading from 2.7.0 to 2.8.1 That looks pretty bad, not sure what it means, but I would start over, maybe something is missing or there's a bad plugin or some other mysterious thing has failed. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Corinne Chatnik Sent: Wednesday, May 18, 2022 3:25 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Errors Upgrading from 2.7.0 to 2.8.1 Hi, Trying to upgrade from 2.7.0 to 2.8.1 and we keep getting the same error repeated over and over for nearly every record and we don?t know where to start looking. I?ve done a complete reindex and redid the database migration etc. The log file keeps repeating this: E, [2022-05-18T14:07:50.629287 #48326] ERROR -- : Thread-2902: Unhandled exception! E, [2022-05-18T14:07:50.630620 #48326] ERROR -- : comparison of NilClass with 0 failed org/jruby/RubyEnumerable.java:574:in `sort_by' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:347:in `find_by_participant' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:411:in `who_participates_with' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:545:in `related_records' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:170:in `find_subcontainer_barcodes' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:190:in `block in sequel_to_jsonmodel' org/jruby/RubyArray.java:1809:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:184:in `sequel_to_jsonmodel' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:336:in `block in resolve' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:335:in `block in resolve' org/jruby/RubyHash.java:1415:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:331:in `block in resolve' org/jruby/RubyGenerator.java:104:in `each' org/jruby/RubyEnumerator.java:396:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:247:in `block in fetch_records_by_uri' org/jruby/RubyHash.java:1415:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:241:in `fetch_records_by_uri' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:130:in `resolve_references' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:44:in `resolve_references' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/crud_helpers.rb:113:in `listing_response' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/crud_helpers.rb:68:in `handle_listing' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/controllers/archival_object.rb:97:in `block in ArchivesSpaceService' org/jruby/RubyBasicObject.java:2622:in `instance_eval' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:368:in `block in GET /repositories/:repo_id/archival_objects' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:105:in `block in open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:69:in `block in transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:204:in `_transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:179:in `block in transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/connection_pool/threaded.rb:91:in `hold' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/connecting.rb:270:in `synchronize' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:145:in `transaction' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:68:in `transaction' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:104:in `block in open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:101:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:426:in `block in DB' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:351:in `block in GET /repositories/:repo_id/archival_objects' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:319:in `block in GET /repositories/:repo_id/archival_objects' org/jruby/RubyMethod.java:115:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1635:in `block in compile!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:992:in `block in route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1011:in `route_eval' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:992:in `block in route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1040:in `block in process_route' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1038:in `process_route' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:990:in `block in route!' org/jruby/RubyArray.java:1809:in `each' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:989:in `route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1097:in `block in dispatch!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `block in invoke' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `invoke' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1094:in `dispatch!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:924:in `block in call!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `block in invoke' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `invoke' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:924:in `call!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:913:in `call' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:292:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/xss_header.rb:18:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/path_traversal.rb:16:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/json_csrf.rb:26:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/base.rb:50:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/base.rb:50:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/frame_options.rb:31:in `call' uri:classloader:/vendor/rack-2.2.3/rack/null_logger.rb:11:in `call' uri:classloader:/vendor/rack-2.2.3/rack/head.rb:12:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:194:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1957:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1502:in `block in call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1729:in `synchronize' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1502:in `call' uri:classloader:/vendor/rack-2.2.3/rack/urlmap.rb:74:in `block in call' org/jruby/RubyArray.java:1809:in `each' uri:classloader:/vendor/rack-2.2.3/rack/urlmap.rb:58:in `call' uri:classloader:/rack/handler/servlet.rb:22:in `call' Thanks! Corinne Chatnik Archivist Digital Strategies New York State Archives www.archives.nysed.gov | Corinne.Chatnik at nysed.gov Facebook | Twitter | New York Archives Magazine | YouTube Confidentiality Notice This email including all attachments is confidential and intended solely for the use of the individual or entity to which it is addressed. This communication may contain information that is protected from disclosure under State and/or Federal law. Please notify the sender immediately if you have received this communication in error and delete this email from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hanstra at nd.edu Thu May 19 09:58:04 2022 From: hanstra at nd.edu (Tom Hanstra) Date: Thu, 19 May 2022 09:58:04 -0400 Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 In-Reply-To: References: Message-ID: Thanks again. So, I currently break up my logs into four different individual logs with these settings: ## Possible Log levels: debug, info, warn, error, fatal (severe only) # AppConfig[:frontend_log] = "/var/log/archivesspace/frontend.log" AppConfig[:frontend_log_level] = "debug" # AppConfig[:backend_log] = "/var/log/archivesspace/backend.log" AppConfig[:backend_log_level] = "debug" # AppConfig[:pui_log] = "/var/log/archivesspace/pui.log" AppConfig[:pui_log_level] = "debug" # AppConfig[:indexer_log] = "/var/log/archivesspace/indexer.log" AppConfig[:indexer_log_level] = "debug" In each of the other logs I see both INFO and DEBUG statements, sometimes a lot, other times fewer. But in the indexer.log file, I only see INFO statements, no DEBUG. But your suggestion above that the line is like "indexed ..." got me searching other logs and I found a couple of lines like this in my backend log: D, [2022-05-16T14:31:45.734159 #5273] DEBUG -- : Thread-4912: Responded with [200, {"Content-Type"=>"application/json", "Cache-Control"=>"private, must-revalidate, max-age=0", "Content-Length"=>"21295"}, ["{\"page_size\":1,\"first_page\":1,\"last_page\":1,\"this_page\":1,\"offset_first\":1,\"offset_last\":1,\"total_hits\":1,\"results\":[{\"id\":\"/repositories/2/archival_objects/1702566#pui\",\"uri\":\"/repositories/2/archival_objects/1702566\",\"title\":\"Brother Paul Hermit CSC not indexed.\",\"primary_type\":\"archival_object\",\"types\":[\"archival_object\",\"pui\",\"pui_archival... in 73ms Is this the type of thing I should continue to look for? Thanks, Tom On Wed, May 18, 2022 at 4:12 PM Blake Carver wrote: > > - Even though the config setting is for DEBUG, the indexer log is only > showing INFO. Should there be more than that? > > Yep. Something must not be quite right in the config, you should see DEBUG > showing up in the logs. > > If it's running 1x1 AND on DEBUG you should see something better by the > crash, you should be able to spot the record. I can't remember what exactly > it looks like, but something like "indexed some/path/with/an/id/in/it/here" > and then you can see the Resource or Archival Object ID in the line there. > > > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Tom > Hanstra > *Sent:* Wednesday, May 18, 2022 3:21 PM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > Blake and others, > > Overall, we went for a week or so with no errors in terms of re-indexing. > I'm looking into some database timeouts which are occurring periodically > (AS and our database server are in two different locations) but with the > connection getting re-established, I can work to address that separately. > > But last night we did run into some errors which we are trying to track > down. A couple of things: > > - Even though the config setting is for DEBUG, the indexer log is only > showing INFO. Should there be more than that? > > - If the log says: > > I, [2022-05-17T22:27:11.756683 #5273] INFO -- : Thread-2890: Staff > Indexer [2022-05-17 22:27:11 -0400] ~~~ Indexed 216 > of 20898 archival_object records in repository UNDA > > immediately followed by an error, how do we determine which record that is > in ArchivesSpace? We are not sure how to find the record which is > indicated in the log. > > Thanks again, > Tom > > > > On Mon, May 16, 2022 at 5:19 PM Blake Carver > wrote: > > That could be it, looks like some kind of "funny" character ArchivesSpace > doesn't like in there probably. Do the "Indexed x of x whatever " numbers > start over right there in the log? > You should see what record it was working on just before there. > > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Tom > Hanstra > *Sent:* Monday, May 16, 2022 10:43 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > I've been monitoring logs and have run into a couple of instances where I > receive this type of error: > > E, [2022-05-16T08:57:57.207392 #5273] ERROR -- : Thread-3962: Unhandled > exception! > E, [2022-05-16T08:57:57.207810 #5273] ERROR -- : > invalid byte sequence in UTF-8 > > and then a lot of detail. Are these errors with data that should be > addressed? I'm still in DEBUG mode in the backend log but it is not clear > how to figure out which record(s) are being flagged. What am I looking for? > > Thanks, > Tom > > On Thu, May 12, 2022 at 8:59 AM Blake Carver > wrote: > > > Could it be that we added a big record which is now having issues being > extracted. Or a corrupted record which is causing such issues? > > I don't think so? It could be, but those errors make me think there's > something else going on with the DB, or maybe the network between the > application and DB server? I'm not really sure what the problem is, but it > seems more like a hardware/network/server issue than an ArchivesSpace > issue. I can't be sure, but those errors don't look like ArchivesSpace > troubles to me. Those are pretty common errors, so I'd do some searching > around to see what you can find to troubleshoot. > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Tom > Hanstra > *Sent:* Wednesday, May 11, 2022 9:30 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > Thanks again for your help. > > Late yesterday, both indexes indicated completion so I thought maybe > things were going to be OK. Consequently, I did not do much in terms of > testing. > > This morning, the logs again had errors, however. In the logs, I found > this error in the indexer log: > > I, [2022-05-10T21:36:07.181427 #30003] INFO -- : Thread-2890: Staff > Indexer [2022-05-10 21:36:07 -0400] Index round complete > I, [2022-05-10T21:36:37.182006 #30003] INFO -- : Thread-2890: Staff > Indexer [2022-05-10 21:36:37 -0400] Running index round > E, [2022-05-10T21:36:37.283423 #30003] ERROR -- : Thread-2890: > uri:classloader:/jsonmodel_client.rb:493:in `all' > /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:154:in > `run_index_round' > /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:283:in > `run' > /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/main.rb:32:in > `block in main' > E, [2022-05-10T21:36:37.284431 #30003] ERROR -- : Thread-2890: > # conflict: Java::JavaSql::SQLNonTransientConnectionException: No operations > allowed after connection closed."]}} > > and in the backup log there were issues with timeouts retrieving a record: > > Java::ComMysqlCjJdbcExceptions::CommunicationsException: The last packet > successfully received from the server was 1,759 milliseconds ago. The last > packet sent successfully to the server was 28,849,143 milliseconds ago. is > longer than the server configured value of 'wait_timeout'. You should > consider either expiring and/or testing connection validity before use in > your application, increasing the server configured values for client > timeouts, or using the Connector/J connection property 'autoReconnect=true' > to avoid this problem. > > Could it be that we added a big record which is now having issues being > extracted. Or a corrupted record which is causing such issues? > > I've now restarted with the 1x1 and DEBUG on and only staff indexing and > it is still thinking indexing is complete. I'll keep things going this way > until we hit an error again and hopefully that will give additional > information. > > I'll also look into the "autoReconnect=true" piece, since we seem to have > a situation where, once this happens, nothing more works until a restart. > > Thanks again for any thoughts on this, > Tom > > On Wed, May 11, 2022 at 5:03 AM Andrew Morrison < > andrew.morrison at bodleian.ox.ac.uk> wrote: > > Indexing can also fail at the commit stage, not related to any one record. > That is when ArchivesSpace tells Solr to transfer changes made in memory to > storage. It does that at several points in the indexing process, but the > longest one is at the end of the PUI indexer's run. If, because you've got > a lot of records, or slow storage on your Solr server, it takes longer it > respond than the value of AppConfig[:indexer_solr_timeout_seconds], it will > start all over again, and potentially go into a loop. The workaround is to > increase the timeout. > > > You might not notice you've got enough records to cause this until you do > a full re-index, or someone edits something linked to most or all records > (e.g. a repository, or a very widely-used subject), triggering the > re-indexing of most of the system's records. > > > Andrew. > > > > On 10/05/2022 22:06, Blake Carver wrote: > > 1x1 would mean setting both records_per_thread and thread_count to 1. > Having loglevel on debug and running at 1x1, you'll be able to see exactly > which thing is being indexed as it happens, and when it crashes, you'll see > what it was working through at the time. > > PUI will always take longer, and a VERY long time 1x1, but unless you're > sure which indexer is crashing, I'd switch them both up. > > You can just `grep Indexed archivesspace.out` after it's running and watch > those numbers. As long as they're going up, all is well. > > It is also possible that it will finish without crashing running so slow > as well. I've seen that happen with LARGE records. > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org > > on behalf of > Tom Hanstra > *Sent:* Tuesday, May 10, 2022 4:15 PM > *To:* Archivesspace Users Group > > > *Subject:* Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > Thanks, Blake. > > Turns out we did add quite a few records recently, so maybe there was > something in there that it did not like all that much. > > How can you tell which record it is choking on? Is that your "1x1" > suggestion? Or does the DEBUG option make that more clear? I have my > indexing set to: > > AppConfig[:indexer_records_per_thread] = 25 > AppConfig[:indexer_thread_count] = 2 > > for both PUI and Staff records. I believe you are suggesting it would most > easily be found using 1 and 1? I can see where that could take a long > time. But it if is going to choke over and over on the same record, then > that may be the best way to address it. > > Do you think if I just did staff indexing without PUI, that it would be > identified faster? Or could it pass the staff side but then die on PUI > later? > > I hope to try some of these ideas after hours today, so if you can confirm > that I've got the right idea, that would help. > > Tom > > > On Tue, May 10, 2022 at 2:17 PM Blake Carver > wrote: > > > Is this possible? > > Short answer, Yes, it's possible your indexer is starting over. > > Long answer. This can be tricky to figure out. Something is wrong, the > indexer never wants to do that. Sometimes "something" "bad" gets into > ArchivesSpace and the indexer will just crash and start over. The problem > is the "something" can be anything and the "bad" can be hard to figure out. > The more stuff you have in your DB, the harder it is to figure out. > > First, I'd make sure this is happening. Your logs should make it obvious. > You might see some FATAL errors just before it starts over. You MIGHT be > able to narrow it down from that. That is, what group of records had that > error in the logs? Maybe that narrows it down enough. You just got lucky! > > I don't think I've ever been so lucky. What I'd do next is set your > loglevel to DEBUG and restart. If you're feeling lucky or just impatient or > both, leave the indexer speed as is. You'll get more details out of the > logs and you should be able to narrow it down better. Ideally, you want to > run the indexers at 1x1, which means it could take forrreeevverrrrr to get > back around to the crash again. If you're lucky, it'll crash on a record, > you'll go look at that record, the problem will be obvious, and there will > be much rejoicing. With it running 1x1 you should see exactly what's > causing the fail. If it's not crashing on the same record every time.... > ugh. That's an even longer answer. > > > > ------------------------------ > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org < > archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Tom > Hanstra > *Sent:* Tuesday, May 10, 2022 10:23 AM > *To:* Archivesspace Users Group < > archivesspace_users_group at lyralists.lyrasis.org> > *Subject:* [Archivesspace_Users_Group] (re)indexing in 2.8.1 > > I don't look at the logs a lot unless there are issues with ArchivesSpace, > so maybe this is something normal. But, after a restart due to some > complaints about database connectivity, it looks like our ArchivesSpace > instance has decided to do a full reindex. The index log sure looks as if > it is starting from scratch and running through the indexing of both PUI > and Staff indexes. > > Is this possible? Is it something that happens periodically and I just > did not notice it? Nothing has changed in my data directory, so I don't see > any reason for indexing to occur. Yet that is what the logs show. > > If it is doing this for some reason, and knowing that we restart > periodically, it seems like we will get into a loop where indexing just > keeps happening all the time. Also, it would be helpful to understand what > caused this to happen. > > Any thoughts or experiences from those who have run this for longer would > be appreciated. I'd like to understand if it would be a good idea to clear > the data directory and perform a full index over the weekend rather than an > unexpected and possibly never ending round in the background. > > Thanks, > Tom > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > > _______________________________________________ > Archivesspace_Users_Group mailing listArchivesspace_Users_Group at lyralists.lyrasis.orghttp://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > > > -- > *Tom Hanstra* > *Sr. Systems Administrator* > hanstra at nd.edu > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -- *Tom Hanstra* *Sr. Systems Administrator* hanstra at nd.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From Corinne.Chatnik at nysed.gov Thu May 19 13:21:57 2022 From: Corinne.Chatnik at nysed.gov (Corinne Chatnik) Date: Thu, 19 May 2022 17:21:57 +0000 Subject: [Archivesspace_Users_Group] Errors Upgrading from 2.7.0 to 2.8.1 In-Reply-To: References: Message-ID: That's exactly it, is this caused by the database migration script? I'm not sure what to do about it. It looks like its affecting almost every archival object. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Brian Hoffman Sent: Thursday, May 19, 2022 7:52:28 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Errors Upgrading from 2.7.0 to 2.8.1 You could also try running this query in MySQL. If you get any results, that would likely be the problem: select id, aspace_relationship_position from top_container_link_rlshp where aspace_relationship_position is null; From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Blake Carver Date: Wednesday, May 18, 2022 at 4:13 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] Errors Upgrading from 2.7.0 to 2.8.1 That looks pretty bad, not sure what it means, but I would start over, maybe something is missing or there's a bad plugin or some other mysterious thing has failed. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Corinne Chatnik Sent: Wednesday, May 18, 2022 3:25 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Errors Upgrading from 2.7.0 to 2.8.1 Hi, Trying to upgrade from 2.7.0 to 2.8.1 and we keep getting the same error repeated over and over for nearly every record and we don?t know where to start looking. I?ve done a complete reindex and redid the database migration etc. The log file keeps repeating this: E, [2022-05-18T14:07:50.629287 #48326] ERROR -- : Thread-2902: Unhandled exception! E, [2022-05-18T14:07:50.630620 #48326] ERROR -- : comparison of NilClass with 0 failed org/jruby/RubyEnumerable.java:574:in `sort_by' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:347:in `find_by_participant' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:411:in `who_participates_with' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:545:in `related_records' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:170:in `find_subcontainer_barcodes' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:190:in `block in sequel_to_jsonmodel' org/jruby/RubyArray.java:1809:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:184:in `sequel_to_jsonmodel' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:336:in `block in resolve' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:335:in `block in resolve' org/jruby/RubyHash.java:1415:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:331:in `block in resolve' org/jruby/RubyGenerator.java:104:in `each' org/jruby/RubyEnumerator.java:396:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:247:in `block in fetch_records_by_uri' org/jruby/RubyHash.java:1415:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:241:in `fetch_records_by_uri' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:130:in `resolve_references' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:44:in `resolve_references' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/crud_helpers.rb:113:in `listing_response' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/crud_helpers.rb:68:in `handle_listing' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/controllers/archival_object.rb:97:in `block in ArchivesSpaceService' org/jruby/RubyBasicObject.java:2622:in `instance_eval' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:368:in `block in GET /repositories/:repo_id/archival_objects' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:105:in `block in open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:69:in `block in transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:204:in `_transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:179:in `block in transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/connection_pool/threaded.rb:91:in `hold' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/connecting.rb:270:in `synchronize' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:145:in `transaction' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:68:in `transaction' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:104:in `block in open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:101:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:426:in `block in DB' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:351:in `block in GET /repositories/:repo_id/archival_objects' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:319:in `block in GET /repositories/:repo_id/archival_objects' org/jruby/RubyMethod.java:115:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1635:in `block in compile!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:992:in `block in route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1011:in `route_eval' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:992:in `block in route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1040:in `block in process_route' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1038:in `process_route' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:990:in `block in route!' org/jruby/RubyArray.java:1809:in `each' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:989:in `route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1097:in `block in dispatch!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `block in invoke' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `invoke' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1094:in `dispatch!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:924:in `block in call!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `block in invoke' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `invoke' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:924:in `call!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:913:in `call' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:292:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/xss_header.rb:18:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/path_traversal.rb:16:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/json_csrf.rb:26:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/base.rb:50:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/base.rb:50:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/frame_options.rb:31:in `call' uri:classloader:/vendor/rack-2.2.3/rack/null_logger.rb:11:in `call' uri:classloader:/vendor/rack-2.2.3/rack/head.rb:12:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:194:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1957:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1502:in `block in call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1729:in `synchronize' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1502:in `call' uri:classloader:/vendor/rack-2.2.3/rack/urlmap.rb:74:in `block in call' org/jruby/RubyArray.java:1809:in `each' uri:classloader:/vendor/rack-2.2.3/rack/urlmap.rb:58:in `call' uri:classloader:/rack/handler/servlet.rb:22:in `call' Thanks! Corinne Chatnik Archivist Digital Strategies New York State Archives www.archives.nysed.gov | Corinne.Chatnik at nysed.gov Facebook | Twitter | New York Archives Magazine | YouTube Confidentiality Notice This email including all attachments is confidential and intended solely for the use of the individual or entity to which it is addressed. This communication may contain information that is protected from disclosure under State and/or Federal law. Please notify the sender immediately if you have received this communication in error and delete this email from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Corinne.Chatnik at nysed.gov Thu May 19 13:43:06 2022 From: Corinne.Chatnik at nysed.gov (Corinne Chatnik) Date: Thu, 19 May 2022 17:43:06 +0000 Subject: [Archivesspace_Users_Group] Errors Upgrading from 2.7.0 to 2.8.1 In-Reply-To: References: Message-ID: Never mind, I fixed it. I set aspace_relationship_position to 0 instead of null. Really appreciate your help Brian! I never would have found that. Thanks! Corinne From: Corinne Chatnik Sent: Thursday, May 19, 2022 1:22 PM To: Archivesspace Users Group Subject: Re: Errors Upgrading from 2.7.0 to 2.8.1 That's exactly it, is this caused by the database migration script? I'm not sure what to do about it. It looks like its affecting almost every archival object. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Brian Hoffman > Sent: Thursday, May 19, 2022 7:52:28 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] Errors Upgrading from 2.7.0 to 2.8.1 You could also try running this query in MySQL. If you get any results, that would likely be the problem: select id, aspace_relationship_position from top_container_link_rlshp where aspace_relationship_position is null; From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Blake Carver > Date: Wednesday, May 18, 2022 at 4:13 PM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] Errors Upgrading from 2.7.0 to 2.8.1 That looks pretty bad, not sure what it means, but I would start over, maybe something is missing or there's a bad plugin or some other mysterious thing has failed. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Corinne Chatnik > Sent: Wednesday, May 18, 2022 3:25 PM To: Archivesspace Users Group > Subject: [Archivesspace_Users_Group] Errors Upgrading from 2.7.0 to 2.8.1 Hi, Trying to upgrade from 2.7.0 to 2.8.1 and we keep getting the same error repeated over and over for nearly every record and we don't know where to start looking. I've done a complete reindex and redid the database migration etc. The log file keeps repeating this: E, [2022-05-18T14:07:50.629287 #48326] ERROR -- : Thread-2902: Unhandled exception! E, [2022-05-18T14:07:50.630620 #48326] ERROR -- : comparison of NilClass with 0 failed org/jruby/RubyEnumerable.java:574:in `sort_by' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:347:in `find_by_participant' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:411:in `who_participates_with' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/mixins/relationships.rb:545:in `related_records' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:170:in `find_subcontainer_barcodes' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:190:in `block in sequel_to_jsonmodel' org/jruby/RubyArray.java:1809:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/top_container.rb:184:in `sequel_to_jsonmodel' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:336:in `block in resolve' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:335:in `block in resolve' org/jruby/RubyHash.java:1415:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:331:in `block in resolve' org/jruby/RubyGenerator.java:104:in `each' org/jruby/RubyEnumerator.java:396:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:247:in `block in fetch_records_by_uri' org/jruby/RubyHash.java:1415:in `each' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:241:in `fetch_records_by_uri' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:130:in `resolve_references' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/uri_resolver.rb:44:in `resolve_references' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/crud_helpers.rb:113:in `listing_response' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/crud_helpers.rb:68:in `handle_listing' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/controllers/archival_object.rb:97:in `block in ArchivesSpaceService' org/jruby/RubyBasicObject.java:2622:in `instance_eval' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:368:in `block in GET /repositories/:repo_id/archival_objects' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:105:in `block in open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:69:in `block in transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:204:in `_transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:179:in `block in transaction' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/connection_pool/threaded.rb:91:in `hold' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/connecting.rb:270:in `synchronize' /opt/archivesspace-2.8.1/gems/gems/sequel-5.9.0/lib/sequel/database/transactions.rb:145:in `transaction' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:68:in `transaction' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:104:in `block in open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:101:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/model/db.rb:426:in `block in DB' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:351:in `block in GET /repositories/:repo_id/archival_objects' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/request_context.rb:24:in `open' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/lib/rest.rb:319:in `block in GET /repositories/:repo_id/archival_objects' org/jruby/RubyMethod.java:115:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1635:in `block in compile!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:992:in `block in route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1011:in `route_eval' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:992:in `block in route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1040:in `block in process_route' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1038:in `process_route' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:990:in `block in route!' org/jruby/RubyArray.java:1809:in `each' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:989:in `route!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1097:in `block in dispatch!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `block in invoke' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `invoke' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1094:in `dispatch!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:924:in `block in call!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `block in invoke' org/jruby/RubyKernel.java:1189:in `catch' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `invoke' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:924:in `call!' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:913:in `call' /opt/archivesspace-2.8.1/data/tmp/jetty-0.0.0.0-8089-backend.war-_-any-/webapp/WEB-INF/app/main.rb:292:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/xss_header.rb:18:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/path_traversal.rb:16:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/json_csrf.rb:26:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/base.rb:50:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/base.rb:50:in `call' /opt/archivesspace-2.8.1/gems/gems/rack-protection-2.0.5/lib/rack/protection/frame_options.rb:31:in `call' uri:classloader:/vendor/rack-2.2.3/rack/null_logger.rb:11:in `call' uri:classloader:/vendor/rack-2.2.3/rack/head.rb:12:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:194:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1957:in `call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1502:in `block in call' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1729:in `synchronize' /opt/archivesspace-2.8.1/gems/gems/sinatra-2.0.5/lib/sinatra/base.rb:1502:in `call' uri:classloader:/vendor/rack-2.2.3/rack/urlmap.rb:74:in `block in call' org/jruby/RubyArray.java:1809:in `each' uri:classloader:/vendor/rack-2.2.3/rack/urlmap.rb:58:in `call' uri:classloader:/rack/handler/servlet.rb:22:in `call' Thanks! Corinne Chatnik Archivist Digital Strategies New York State Archives www.archives.nysed.gov | Corinne.Chatnik at nysed.gov Facebook | Twitter | New York Archives Magazine | YouTube Confidentiality Notice This email including all attachments is confidential and intended solely for the use of the individual or entity to which it is addressed. This communication may contain information that is protected from disclosure under State and/or Federal law. Please notify the sender immediately if you have received this communication in error and delete this email from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hawthorn_j at mitchell.edu Fri May 20 10:23:09 2022 From: hawthorn_j at mitchell.edu (John Hawthorn) Date: Fri, 20 May 2022 14:23:09 +0000 Subject: [Archivesspace_Users_Group] Permission to Post to Archivesspace List Message-ID: Just looking for permission to post to the list for queries on setting up Archivesspace server. Thank you, John Hawthorn Systems Administrator Mitchell College 437 Pequot Ave New London, CT 06320-4498 (860)701-7777 [https://community.mitchell.edu/image/Mitchell_College_email_logo_7_2015.jpg] -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jessica.Crouch at lyrasis.org Fri May 20 10:57:40 2022 From: Jessica.Crouch at lyrasis.org (Jessica Crouch) Date: Fri, 20 May 2022 14:57:40 +0000 Subject: [Archivesspace_Users_Group] Due today: Apply now for the second cohort of the ArchivesSpace Member Match program In-Reply-To: References: Message-ID: Dear ArchivesSpace Users, The deadline to apply to participate in the ArchivesSpace Member Match program is today, Friday, May 20th. The Member Match program is an initiative to engage the ArchivesSpace membership community, created and organized by the Member Engagement sub-team of the ArchivesSpace User Advisory Council, with support from the ArchivesSpace Community Engagement Coordinator. The program is intended to be a resource and venue for peer-to-peer support between ArchivesSpace members. For one, year-long term, participants will be matched with a member with whom they can receive and offer professional insight, advice, and camaraderie. The program will also offer participants the opportunity to engage in exclusive events and enlightening discussions about ArchivesSpace and its active user community. Thanks to valuable feedback from the first cohort of Member Match Participants, we?ve implemented the following updates to the program: * Monthly Listserv Discussion Topics * Each month, a member of the Member Engagement sub-team will reach out to the Member Match listserv to spur discussion and encourage continued engagement between matches. * Quarterly Member Match Meet-Ups * These will be opportunities for large group socializing as well as the potential for dedicated time to spend with matches in breakout rooms. * Option to participate in small group matches of 3 people Eligibility Any individual affiliated with an ArchivesSpace member organization is eligible to participate in the ArchivesSpace Member Match program and there is no limit to the number of individuals from a member organization that may participate. If you are unsure of your organization?s ArchivesSpace membership status, visit https://archivesspace.org/community/whos-using-archivesspace or email ArchivesSpaceHome at lyrasis.org. To Apply There is a short application to complete at https://airtable.com/shrDL4wQhc3gkBAlH Applications should be submitted by May 20th, 2022. Applicants will be notified of their matches no later than June 30th. To Learn More Visit the Member Match wiki: https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/2198568994/ArchivesSpace+Member+Match+Program Please feel free to direct any questions to ArchivesSpaceHome at lyrasis.org Sent on behalf of the ArchivesSpace Member Engagement sub-team Regina Carra, American Folk Art Museum Bailey Hoffner, University of Oklahoma Patrick Milhoan, University of Notre Dame Sarah Ponichtera, Seton Hall University Jessica Crouch, ArchivesSpace Community Engagement Coordinator Jessica Dowd Crouch Community Engagement Coordinator for ArchivesSpace jessica.crouch at lyrasis.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mweppler at csustan.edu Fri May 20 11:40:12 2022 From: mweppler at csustan.edu (Mary Weppler) Date: Fri, 20 May 2022 15:40:12 +0000 Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 In-Reply-To: References: Message-ID: Mary Weppler-Van Diver Library Faculty, Librarian & CA Special Collections and University Archives Email: mweppler at csustan.edu Phone: 209-664-6538 ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Tom Hanstra Sent: Thursday, May 19, 2022 6:58 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 CAUTION: This message originated from outside of Stanislaus State. Do not click on links or open attachments unless you recognize the sender and are expecting the message. Thanks again. So, I currently break up my logs into four different individual logs with these settings: ## Possible Log levels: debug, info, warn, error, fatal (severe only) # AppConfig[:frontend_log] = "/var/log/archivesspace/frontend.log" AppConfig[:frontend_log_level] = "debug" # AppConfig[:backend_log] = "/var/log/archivesspace/backend.log" AppConfig[:backend_log_level] = "debug" # AppConfig[:pui_log] = "/var/log/archivesspace/pui.log" AppConfig[:pui_log_level] = "debug" # AppConfig[:indexer_log] = "/var/log/archivesspace/indexer.log" AppConfig[:indexer_log_level] = "debug" In each of the other logs I see both INFO and DEBUG statements, sometimes a lot, other times fewer. But in the indexer.log file, I only see INFO statements, no DEBUG. But your suggestion above that the line is like "indexed ..." got me searching other logs and I found a couple of lines like this in my backend log: D, [2022-05-16T14:31:45.734159 #5273] DEBUG -- : Thread-4912: Responded with [200, {"Content-Type"=>"application/json", "Cache-Control"=>"private, must-revalidate, max-age=0", "Content-Length"=>"21295"}, ["{\"page_size\":1,\"first_page\":1,\"last_page\":1,\"this_page\":1,\"offset_first\":1,\"offset_last\":1,\"total_hits\":1,\"results\":[{\"id\":\"/repositories/2/archival_objects/1702566#pui\",\"uri\":\"/repositories/2/archival_objects/1702566\",\"title\":\"Brother Paul Hermit CSC not indexed.\",\"primary_type\":\"archival_object\",\"types\":[\"archival_object\",\"pui\",\"pui_archival... in 73ms Is this the type of thing I should continue to look for? Thanks, Tom On Wed, May 18, 2022 at 4:12 PM Blake Carver > wrote: > - Even though the config setting is for DEBUG, the indexer log is only showing INFO. Should there be more than that? Yep. Something must not be quite right in the config, you should see DEBUG showing up in the logs. If it's running 1x1 AND on DEBUG you should see something better by the crash, you should be able to spot the record. I can't remember what exactly it looks like, but something like "indexed some/path/with/an/id/in/it/here" and then you can see the Resource or Archival Object ID in the line there. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Wednesday, May 18, 2022 3:21 PM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Blake and others, Overall, we went for a week or so with no errors in terms of re-indexing. I'm looking into some database timeouts which are occurring periodically (AS and our database server are in two different locations) but with the connection getting re-established, I can work to address that separately. But last night we did run into some errors which we are trying to track down. A couple of things: - Even though the config setting is for DEBUG, the indexer log is only showing INFO. Should there be more than that? - If the log says: I, [2022-05-17T22:27:11.756683 #5273] INFO -- : Thread-2890: Staff Indexer [2022-05-17 22:27:11 -0400] ~~~ Indexed 216 of 20898 archival_object records in repository UNDA immediately followed by an error, how do we determine which record that is in ArchivesSpace? We are not sure how to find the record which is indicated in the log. Thanks again, Tom On Mon, May 16, 2022 at 5:19 PM Blake Carver > wrote: That could be it, looks like some kind of "funny" character ArchivesSpace doesn't like in there probably. Do the "Indexed x of x whatever " numbers start over right there in the log? You should see what record it was working on just before there. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Monday, May 16, 2022 10:43 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 I've been monitoring logs and have run into a couple of instances where I receive this type of error: E, [2022-05-16T08:57:57.207392 #5273] ERROR -- : Thread-3962: Unhandled exception! E, [2022-05-16T08:57:57.207810 #5273] ERROR -- : invalid byte sequence in UTF-8 and then a lot of detail. Are these errors with data that should be addressed? I'm still in DEBUG mode in the backend log but it is not clear how to figure out which record(s) are being flagged. What am I looking for? Thanks, Tom On Thu, May 12, 2022 at 8:59 AM Blake Carver > wrote: > Could it be that we added a big record which is now having issues being extracted. Or a corrupted record which is causing such issues? I don't think so? It could be, but those errors make me think there's something else going on with the DB, or maybe the network between the application and DB server? I'm not really sure what the problem is, but it seems more like a hardware/network/server issue than an ArchivesSpace issue. I can't be sure, but those errors don't look like ArchivesSpace troubles to me. Those are pretty common errors, so I'd do some searching around to see what you can find to troubleshoot. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Wednesday, May 11, 2022 9:30 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Thanks again for your help. Late yesterday, both indexes indicated completion so I thought maybe things were going to be OK. Consequently, I did not do much in terms of testing. This morning, the logs again had errors, however. In the logs, I found this error in the indexer log: I, [2022-05-10T21:36:07.181427 #30003] INFO -- : Thread-2890: Staff Indexer [2022-05-10 21:36:07 -0400] Index round complete I, [2022-05-10T21:36:37.182006 #30003] INFO -- : Thread-2890: Staff Indexer [2022-05-10 21:36:37 -0400] Running index round E, [2022-05-10T21:36:37.283423 #30003] ERROR -- : Thread-2890: uri:classloader:/jsonmodel_client.rb:493:in `all' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:154:in `run_index_round' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:283:in `run' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/main.rb:32:in `block in main' E, [2022-05-10T21:36:37.284431 #30003] ERROR -- : Thread-2890: #> wrote: Indexing can also fail at the commit stage, not related to any one record. That is when ArchivesSpace tells Solr to transfer changes made in memory to storage. It does that at several points in the indexing process, but the longest one is at the end of the PUI indexer's run. If, because you've got a lot of records, or slow storage on your Solr server, it takes longer it respond than the value of AppConfig[:indexer_solr_timeout_seconds], it will start all over again, and potentially go into a loop. The workaround is to increase the timeout. You might not notice you've got enough records to cause this until you do a full re-index, or someone edits something linked to most or all records (e.g. a repository, or a very widely-used subject), triggering the re-indexing of most of the system's records. Andrew. On 10/05/2022 22:06, Blake Carver wrote: 1x1 would mean setting both records_per_thread and thread_count to 1. Having loglevel on debug and running at 1x1, you'll be able to see exactly which thing is being indexed as it happens, and when it crashes, you'll see what it was working through at the time. PUI will always take longer, and a VERY long time 1x1, but unless you're sure which indexer is crashing, I'd switch them both up. You can just `grep Indexed archivesspace.out` after it's running and watch those numbers. As long as they're going up, all is well. It is also possible that it will finish without crashing running so slow as well. I've seen that happen with LARGE records. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Tom Hanstra Sent: Tuesday, May 10, 2022 4:15 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Thanks, Blake. Turns out we did add quite a few records recently, so maybe there was something in there that it did not like all that much. How can you tell which record it is choking on? Is that your "1x1" suggestion? Or does the DEBUG option make that more clear? I have my indexing set to: AppConfig[:indexer_records_per_thread] = 25 AppConfig[:indexer_thread_count] = 2 for both PUI and Staff records. I believe you are suggesting it would most easily be found using 1 and 1? I can see where that could take a long time. But it if is going to choke over and over on the same record, then that may be the best way to address it. Do you think if I just did staff indexing without PUI, that it would be identified faster? Or could it pass the staff side but then die on PUI later? I hope to try some of these ideas after hours today, so if you can confirm that I've got the right idea, that would help. Tom On Tue, May 10, 2022 at 2:17 PM Blake Carver > wrote: > Is this possible? Short answer, Yes, it's possible your indexer is starting over. Long answer. This can be tricky to figure out. Something is wrong, the indexer never wants to do that. Sometimes "something" "bad" gets into ArchivesSpace and the indexer will just crash and start over. The problem is the "something" can be anything and the "bad" can be hard to figure out. The more stuff you have in your DB, the harder it is to figure out. First, I'd make sure this is happening. Your logs should make it obvious. You might see some FATAL errors just before it starts over. You MIGHT be able to narrow it down from that. That is, what group of records had that error in the logs? Maybe that narrows it down enough. You just got lucky! I don't think I've ever been so lucky. What I'd do next is set your loglevel to DEBUG and restart. If you're feeling lucky or just impatient or both, leave the indexer speed as is. You'll get more details out of the logs and you should be able to narrow it down better. Ideally, you want to run the indexers at 1x1, which means it could take forrreeevverrrrr to get back around to the crash again. If you're lucky, it'll crash on a record, you'll go look at that record, the problem will be obvious, and there will be much rejoicing. With it running 1x1 you should see exactly what's causing the fail. If it's not crashing on the same record every time.... ugh. That's an even longer answer. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Tuesday, May 10, 2022 10:23 AM To: Archivesspace Users Group > Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 I don't look at the logs a lot unless there are issues with ArchivesSpace, so maybe this is something normal. But, after a restart due to some complaints about database connectivity, it looks like our ArchivesSpace instance has decided to do a full reindex. The index log sure looks as if it is starting from scratch and running through the indexing of both PUI and Staff indexes. Is this possible? Is it something that happens periodically and I just did not notice it? Nothing has changed in my data directory, so I don't see any reason for indexing to occur. Yet that is what the logs show. If it is doing this for some reason, and knowing that we restart periodically, it seems like we will get into a loop where indexing just keeps happening all the time. Also, it would be helpful to understand what caused this to happen. Any thoughts or experiences from those who have run this for longer would be appreciated. I'd like to understand if it would be a good idea to clear the data directory and perform a full index over the weekend rather than an unexpected and possibly never ending round in the background. Thanks, Tom -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake.carver at lyrasis.org Fri May 20 12:00:37 2022 From: blake.carver at lyrasis.org (Blake Carver) Date: Fri, 20 May 2022 16:00:37 +0000 Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 In-Reply-To: References: Message-ID: It should look something like these lines, where you should see "GET whatever" and then the crash is happening at the "GET" I've found it usually happens around the archival objects so "GET /repositories/2/archival_objects" whatever and then FATAL or maybe ERROR Sometimes running it 1x1 will cause it to stop crashing though. And on large sites it takes a heckuva long time to get through all the records. , [2022-05-19T13:32:55.617646 #93541] INFO -- : Thread-2952: Staff Indexer [2022-05-19 13:32:55 -0400] Indexed 1 records in 2 seconds D, [2022-05-19T13:32:55.700686 #93541] DEBUG -- : Thread-2960: GET /repositories/2/digital_objects?all_ids=true&modified_since=0 [session: #"search_indexer", :login_time=>2022-05-19 13:32:52 -0400, :expirable=>false}, @system_mtime=2022-05-19 17:32:52 UTC, @id="238c65ef0b6ba04ccf6120ce85df6d8daa77135ec9a972eaca6deb521c74714b">] I, [2022-05-19T13:32:57.817094 #93541] INFO -- : Thread-2952: Staff Indexer [2022-05-19 13:32:57 -0400] Indexed 1 records in 1 seconds D, [2022-05-19T13:32:57.899146 #93541] DEBUG -- : Thread-2960: GET /agents/people?all_ids=true&modified_since=0 [session: #"search_indexer", :login_time=>2022-05-19 13:32:52 -0400, :expirable=>false}, @system_mtime=2022-05-19 17:32:56 UTC, @id="238c65ef0b6ba04ccf6120ce85df6d8daa77135ec9a972eaca6deb521c74714b">] I, [2022-05-19T13:33:02.485591 #93541] INFO -- : Thread-2952: Staff Indexer [2022-05-19 13:33:02 -0400] ~~~ Indexed 1 of 1 classification records in repository Blake D, [2022-05-19T13:33:02.544059 #93541] DEBUG -- : Thread-2970: GET /repositories/2/classifications?id_set=1&resolve%5B%5D=location_profile&resolve%5B%5D=container_profile&resolve%5B%5D=container_locations&resolve%5B%5D=subjects&resolve%5B%5D=places&resolve%5B%5D=linked_agents&resolve%5B%5D=linked_records&resolve%5B%5D=classifications&resolve%5B%5D=digital_object&resolve%5B%5D=agent_representation&resolve%5B%5D=repository&resolve%5B%5D=repository%3A%3Aagent_representation&resolve%5B%5D=related_agents&resolve%5B%5D=top_container&resolve%5B%5D=top_container%3A%3Acontainer_profile&resolve%5B%5D=related_agents&resolve%5B%5D=records&resolve%5B%5D=collections&resolve%5B%5D=surveyed_by&resolve%5B%5D=reviewer&resolve%5B%5D=creator&resolve%5B%5D=related_accessions [session: #"search_indexer", :login_time=>2022-05-19 13:32:52 -0400, :expirable=>false}, @system_mtime=2022-05-19 17:33:01 UTC, @id="238c65ef0b6ba04ccf6120ce85df6d8daa77135ec9a972eaca6deb521c74714b">] D, [2022-05-19T13:33:02.568091 #93541] DEBUG -- : Thread-2970: Post-processed params: {"id_set"=>[1], "resolve"=>["location_profile", "container_profile", "container_locations", "subjects", "places", "linked_agents", "linked_records", "classifications", "digital_object", "agent_representation", "repository", "repository::agent_representation", "related_agents", "top_container", "top_container::container_profile", "related_agents", "records", "collections", "surveyed_by", "reviewer", "creator", "related_accessions"], "repo_id"=>2, "modified_since"=>0, "sort_field"=>:id, "sort_direction"=>:asc} D, [2022-05-19T13:33:23.296930 #93541] DEBUG -- : Thread-2970: GET /repositories/2/archival_objects?all_ids=true&modified_since=0 [session: #"search_indexer", :login_time=>2022-05-19 13:33:22 -0400, :expirable=>false}, @system_mtime=2022-05-19 17:33:22 UTC, @id="28669392a202b2532b3e9029ee3582888c889fe2c43b697ad61b04d6adfca7c3">] D, [2022-05-19T13:33:23.310005 #93541] DEBUG -- : Thread-2970: Post-processed params: {"all_ids"=>true, "modified_since"=>0, "repo_id"=>2, "sort_field"=>:id, "sort_direction"=>:asc} D, [2022-05-19T13:33:23.376931 #93541] DEBUG -- : Thread-2970: Responded with [200, {"Content-Type"=>"application/json", "Cache-Control"=>"private, must-revalidate, max-age=0", "Content-Length"=>"10"}, ["[1,2,3,4]\n"]]... in 104ms I, [2022-05-19T13:33:23.389366 #93541] INFO -- : Thread-3270: PUI Indexer [2022-05-19 13:33:23 -0400] ~~~ Indexed 4 of 4 archival_object records in repository Blake ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Tom Hanstra Sent: Thursday, May 19, 2022 9:58 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Thanks again. So, I currently break up my logs into four different individual logs with these settings: ## Possible Log levels: debug, info, warn, error, fatal (severe only) # AppConfig[:frontend_log] = "/var/log/archivesspace/frontend.log" AppConfig[:frontend_log_level] = "debug" # AppConfig[:backend_log] = "/var/log/archivesspace/backend.log" AppConfig[:backend_log_level] = "debug" # AppConfig[:pui_log] = "/var/log/archivesspace/pui.log" AppConfig[:pui_log_level] = "debug" # AppConfig[:indexer_log] = "/var/log/archivesspace/indexer.log" AppConfig[:indexer_log_level] = "debug" In each of the other logs I see both INFO and DEBUG statements, sometimes a lot, other times fewer. But in the indexer.log file, I only see INFO statements, no DEBUG. But your suggestion above that the line is like "indexed ..." got me searching other logs and I found a couple of lines like this in my backend log: D, [2022-05-16T14:31:45.734159 #5273] DEBUG -- : Thread-4912: Responded with [200, {"Content-Type"=>"application/json", "Cache-Control"=>"private, must-revalidate, max-age=0", "Content-Length"=>"21295"}, ["{\"page_size\":1,\"first_page\":1,\"last_page\":1,\"this_page\":1,\"offset_first\":1,\"offset_last\":1,\"total_hits\":1,\"results\":[{\"id\":\"/repositories/2/archival_objects/1702566#pui\",\"uri\":\"/repositories/2/archival_objects/1702566\",\"title\":\"Brother Paul Hermit CSC not indexed.\",\"primary_type\":\"archival_object\",\"types\":[\"archival_object\",\"pui\",\"pui_archival... in 73ms Is this the type of thing I should continue to look for? Thanks, Tom On Wed, May 18, 2022 at 4:12 PM Blake Carver > wrote: > - Even though the config setting is for DEBUG, the indexer log is only showing INFO. Should there be more than that? Yep. Something must not be quite right in the config, you should see DEBUG showing up in the logs. If it's running 1x1 AND on DEBUG you should see something better by the crash, you should be able to spot the record. I can't remember what exactly it looks like, but something like "indexed some/path/with/an/id/in/it/here" and then you can see the Resource or Archival Object ID in the line there. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Wednesday, May 18, 2022 3:21 PM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Blake and others, Overall, we went for a week or so with no errors in terms of re-indexing. I'm looking into some database timeouts which are occurring periodically (AS and our database server are in two different locations) but with the connection getting re-established, I can work to address that separately. But last night we did run into some errors which we are trying to track down. A couple of things: - Even though the config setting is for DEBUG, the indexer log is only showing INFO. Should there be more than that? - If the log says: I, [2022-05-17T22:27:11.756683 #5273] INFO -- : Thread-2890: Staff Indexer [2022-05-17 22:27:11 -0400] ~~~ Indexed 216 of 20898 archival_object records in repository UNDA immediately followed by an error, how do we determine which record that is in ArchivesSpace? We are not sure how to find the record which is indicated in the log. Thanks again, Tom On Mon, May 16, 2022 at 5:19 PM Blake Carver > wrote: That could be it, looks like some kind of "funny" character ArchivesSpace doesn't like in there probably. Do the "Indexed x of x whatever " numbers start over right there in the log? You should see what record it was working on just before there. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Monday, May 16, 2022 10:43 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 I've been monitoring logs and have run into a couple of instances where I receive this type of error: E, [2022-05-16T08:57:57.207392 #5273] ERROR -- : Thread-3962: Unhandled exception! E, [2022-05-16T08:57:57.207810 #5273] ERROR -- : invalid byte sequence in UTF-8 and then a lot of detail. Are these errors with data that should be addressed? I'm still in DEBUG mode in the backend log but it is not clear how to figure out which record(s) are being flagged. What am I looking for? Thanks, Tom On Thu, May 12, 2022 at 8:59 AM Blake Carver > wrote: > Could it be that we added a big record which is now having issues being extracted. Or a corrupted record which is causing such issues? I don't think so? It could be, but those errors make me think there's something else going on with the DB, or maybe the network between the application and DB server? I'm not really sure what the problem is, but it seems more like a hardware/network/server issue than an ArchivesSpace issue. I can't be sure, but those errors don't look like ArchivesSpace troubles to me. Those are pretty common errors, so I'd do some searching around to see what you can find to troubleshoot. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Wednesday, May 11, 2022 9:30 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Thanks again for your help. Late yesterday, both indexes indicated completion so I thought maybe things were going to be OK. Consequently, I did not do much in terms of testing. This morning, the logs again had errors, however. In the logs, I found this error in the indexer log: I, [2022-05-10T21:36:07.181427 #30003] INFO -- : Thread-2890: Staff Indexer [2022-05-10 21:36:07 -0400] Index round complete I, [2022-05-10T21:36:37.182006 #30003] INFO -- : Thread-2890: Staff Indexer [2022-05-10 21:36:37 -0400] Running index round E, [2022-05-10T21:36:37.283423 #30003] ERROR -- : Thread-2890: uri:classloader:/jsonmodel_client.rb:493:in `all' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:154:in `run_index_round' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/lib/periodic_indexer.rb:283:in `run' /home/app/archivesspace/data/tmp/jetty-0.0.0.0-8091-indexer.war-_aspace-indexer-any-/webapp/WEB-INF/app/main.rb:32:in `block in main' E, [2022-05-10T21:36:37.284431 #30003] ERROR -- : Thread-2890: #> wrote: Indexing can also fail at the commit stage, not related to any one record. That is when ArchivesSpace tells Solr to transfer changes made in memory to storage. It does that at several points in the indexing process, but the longest one is at the end of the PUI indexer's run. If, because you've got a lot of records, or slow storage on your Solr server, it takes longer it respond than the value of AppConfig[:indexer_solr_timeout_seconds], it will start all over again, and potentially go into a loop. The workaround is to increase the timeout. You might not notice you've got enough records to cause this until you do a full re-index, or someone edits something linked to most or all records (e.g. a repository, or a very widely-used subject), triggering the re-indexing of most of the system's records. Andrew. On 10/05/2022 22:06, Blake Carver wrote: 1x1 would mean setting both records_per_thread and thread_count to 1. Having loglevel on debug and running at 1x1, you'll be able to see exactly which thing is being indexed as it happens, and when it crashes, you'll see what it was working through at the time. PUI will always take longer, and a VERY long time 1x1, but unless you're sure which indexer is crashing, I'd switch them both up. You can just `grep Indexed archivesspace.out` after it's running and watch those numbers. As long as they're going up, all is well. It is also possible that it will finish without crashing running so slow as well. I've seen that happen with LARGE records. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Tom Hanstra Sent: Tuesday, May 10, 2022 4:15 PM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] (re)indexing in 2.8.1 Thanks, Blake. Turns out we did add quite a few records recently, so maybe there was something in there that it did not like all that much. How can you tell which record it is choking on? Is that your "1x1" suggestion? Or does the DEBUG option make that more clear? I have my indexing set to: AppConfig[:indexer_records_per_thread] = 25 AppConfig[:indexer_thread_count] = 2 for both PUI and Staff records. I believe you are suggesting it would most easily be found using 1 and 1? I can see where that could take a long time. But it if is going to choke over and over on the same record, then that may be the best way to address it. Do you think if I just did staff indexing without PUI, that it would be identified faster? Or could it pass the staff side but then die on PUI later? I hope to try some of these ideas after hours today, so if you can confirm that I've got the right idea, that would help. Tom On Tue, May 10, 2022 at 2:17 PM Blake Carver > wrote: > Is this possible? Short answer, Yes, it's possible your indexer is starting over. Long answer. This can be tricky to figure out. Something is wrong, the indexer never wants to do that. Sometimes "something" "bad" gets into ArchivesSpace and the indexer will just crash and start over. The problem is the "something" can be anything and the "bad" can be hard to figure out. The more stuff you have in your DB, the harder it is to figure out. First, I'd make sure this is happening. Your logs should make it obvious. You might see some FATAL errors just before it starts over. You MIGHT be able to narrow it down from that. That is, what group of records had that error in the logs? Maybe that narrows it down enough. You just got lucky! I don't think I've ever been so lucky. What I'd do next is set your loglevel to DEBUG and restart. If you're feeling lucky or just impatient or both, leave the indexer speed as is. You'll get more details out of the logs and you should be able to narrow it down better. Ideally, you want to run the indexers at 1x1, which means it could take forrreeevverrrrr to get back around to the crash again. If you're lucky, it'll crash on a record, you'll go look at that record, the problem will be obvious, and there will be much rejoicing. With it running 1x1 you should see exactly what's causing the fail. If it's not crashing on the same record every time.... ugh. That's an even longer answer. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org > on behalf of Tom Hanstra > Sent: Tuesday, May 10, 2022 10:23 AM To: Archivesspace Users Group > Subject: [Archivesspace_Users_Group] (re)indexing in 2.8.1 I don't look at the logs a lot unless there are issues with ArchivesSpace, so maybe this is something normal. But, after a restart due to some complaints about database connectivity, it looks like our ArchivesSpace instance has decided to do a full reindex. The index log sure looks as if it is starting from scratch and running through the indexing of both PUI and Staff indexes. Is this possible? Is it something that happens periodically and I just did not notice it? Nothing has changed in my data directory, so I don't see any reason for indexing to occur. Yet that is what the logs show. If it is doing this for some reason, and knowing that we restart periodically, it seems like we will get into a loop where indexing just keeps happening all the time. Also, it would be helpful to understand what caused this to happen. Any thoughts or experiences from those who have run this for longer would be appreciated. I'd like to understand if it would be a good idea to clear the data directory and perform a full index over the weekend rather than an unexpected and possibly never ending round in the background. Thanks, Tom -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] _______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group at lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -- Tom Hanstra Sr. Systems Administrator hanstra at nd.edu [https://ci3.googleusercontent.com/mail-sig/AIorK4wQjvBdM9TFi5bR5RBsq_1dY3HTxh-Kg_4W690bwTCSKeVGyazMoj0wdmkNgJ0kfjeRnparhiw] -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jessica.Crouch at lyrasis.org Fri May 20 12:03:35 2022 From: Jessica.Crouch at lyrasis.org (Jessica Crouch) Date: Fri, 20 May 2022 16:03:35 +0000 Subject: [Archivesspace_Users_Group] Permission to Post to Archivesspace List In-Reply-To: References: Message-ID: Hi John, Feel free to post any questions you have about getting started with ArchivesSpace. This group has a wealth of experience to draw from. And as a reminder, all ArchivesSpace members are entitled to technical support, including support installing ArchivesSpace. If you?d like to get a tech support ticket started, email the program team at ArchivesSpaceHome at lyrasis.org. Best, Jessica Jessica Dowd Crouch Community Engagement Coordinator for ArchivesSpace jessica.crouch at lyrasis.org From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of John Hawthorn Date: Friday, May 20, 2022 at 7:23 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] Permission to Post to Archivesspace List Just looking for permission to post to the list for queries on setting up Archivesspace server. Thank you, John Hawthorn Systems Administrator Mitchell College 437 Pequot Ave New London, CT 06320-4498 (860)701-7777 [https://community.mitchell.edu/image/Mitchell_College_email_logo_7_2015.jpg] -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfrieldsmith at sandiego.edu Fri May 20 17:57:53 2022 From: sfrieldsmith at sandiego.edu (Sarah Frieldsmith) Date: Fri, 20 May 2022 14:57:53 -0700 Subject: [Archivesspace_Users_Group] ASpace Website/URL setting(s)? Message-ID: Would really appreciate any help. First timer here. Set up database (MariaDB), set up tables, set up solr, and created the solr core. Ran the AS install and *can* successfully access ports via curl. I don't know where to put our external URL information, so I can actually visit the site(s). In looking at other ASpace sites, none of them have "public" as part of their URL (per the tech-docs instructions). We're using Ansible to control nginx. Our public URL is/should be: archivesspace-2022.sandiego.edu (I realize that's not ideal, but that is what has been assigned and I'm just trying to get ASpace going at this point.) If anyone knows what should go in the config file and what needs to go to Ansible, I'd be super grateful! *Sarah Frieldsmith* *Systems Librarian* University of San Diego sfrieldsmith at sandiego.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake.carver at lyrasis.org Fri May 20 21:36:07 2022 From: blake.carver at lyrasis.org (Blake Carver) Date: Sat, 21 May 2022 01:36:07 +0000 Subject: [Archivesspace_Users_Group] ASpace Website/URL setting(s)? In-Reply-To: References: Message-ID: The techdocs do have nginx settings here: https://archivesspace.github.io/tech-docs/provisioning/https.html#Nginx If something's not clear, let me know. ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Sarah Frieldsmith Sent: Friday, May 20, 2022 5:57 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] ASpace Website/URL setting(s)? Would really appreciate any help. First timer here. Set up database (MariaDB), set up tables, set up solr, and created the solr core. Ran the AS install and *can* successfully access ports via curl. I don't know where to put our external URL information, so I can actually visit the site(s). In looking at other ASpace sites, none of them have "public" as part of their URL (per the tech-docs instructions). We're using Ansible to control nginx. Our public URL is/should be: archivesspace-2022.sandiego.edu (I realize that's not ideal, but that is what has been assigned and I'm just trying to get ASpace going at this point.) If anyone knows what should go in the config file and what needs to go to Ansible, I'd be super grateful! Sarah Frieldsmith Systems Librarian University of San Diego sfrieldsmith at sandiego.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at virginia.edu Mon May 23 14:37:14 2022 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Mon, 23 May 2022 18:37:14 +0000 Subject: [Archivesspace_Users_Group] Issue with gems extensions ( sassc, bindex, ... ) on Mac with 3.2.0 Message-ID: I usually test out migrations and local plugins on my Mac laptop first before installing on a test server. I ran into a couple of issues with 3.2.0 release. Using the release downloaded from https://github.com/archivesspace/archivesspace/releases/tag/v3.2.0 Backend and frontend appeared to work and communicate with the separately installed Solr instance however the PUI gave system errors from the bundler relating to sassc-2.4.0 Looking at the log file, there were a number of messages about that and other gems: Ignoring bindex-0.8.1 because its extensions are not built. Try: gem pristine bindex --version 0.8.1 Ignoring llhttp-ffi-0.3.1 because its extensions are not built. Try: gem pristine llhttp-ffi --version 0.3.1 Ignoring sassc-2.4.0 because its extensions are not built. Try: gem pristine sassc --version 2.4.0 I attempted to run ?gem pristine? after setting GEM_HOME, which seemed to do something, but didn?t fix the issue. ( Doing these sorts of fixes are a bit confusing due to the way that JRuby is packaged in ArchivesSpace, so I may not have been doing it correctly. ) I finally tried building my own distribution from GitHub tag v3.2.0, and unpacking that zip file and running it appears to work ( so far! Still indexing PUI ) So I?m guessing that there is something in these gem extensions that is architecture or java version specific and the distributions on GitHub are not universal. We may require a fixup script that runs the bundler similar to the way it?s done in initialize-plugins script. Has anyone else run into this issue ? ? Steve Majewski -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3342 bytes Desc: not available URL: From sdm7g at virginia.edu Mon May 23 14:42:31 2022 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Mon, 23 May 2022 18:42:31 +0000 Subject: [Archivesspace_Users_Group] 3.2.0 not clearing jetty directories from /data/tmp In-Reply-To: References: Message-ID: I just noticed this testing migration to 3.2.0 on my laptop, but I though it had something to do with how I started or stopped server while tracing other errors I was encountering. ( See my other message about problems with Gem extensions. ) ? Steve > On Mar 11, 2022, at 2:14 AM, Neal Fitzgerald wrote: > > Hi All > > Has anyone else noticed that the temporary 'jetty-0_0_0_0-808x...war' directories in /data/tmp are not being cleared in 3.2.0? It seems to create a new set at each restart. Also asadmin doesn't have permissions to these directories anymore in 3.2.0. > > Is there some config setting I am missing? Is it safe just to clear these directories periodically? > > I already have 3.6Gb of /tmp files on my test 3.2.0 machine (admittedly after a lot of restarts re-installing and testing our PUI customisations) > > Cheers > > Neal Fitzgerald > > State Library of Victoria, Australia > > Neal Fitzgerald | Senior Specialist, Library Systems & Digital Preservation | Collection Development & Description > State Library Victoria | 328 Swanston Street | Melbourne VIC 3000 > T +61 3 8664 7103 | nfitzgerald at slv.vic.gov.au > slv.vic.gov.au > > > > > > This message and any attachment is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please delete all copies of the message and its attachments and notify the sender immediately. Thank you. > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3342 bytes Desc: not available URL: From sdm7g at virginia.edu Mon May 23 14:49:26 2022 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Mon, 23 May 2022 18:49:26 +0000 Subject: [Archivesspace_Users_Group] 3.2.0 not clearing jetty directories from /data/tmp In-Reply-To: References: Message-ID: <89D35EB1-307B-4570-9E41-9B36E9331627@virginia.edu> But yes, it?s safe to delete those /tmp directories when you shutdown and restart. I assume the temp files are owned by whoever starts up the server. So the archivesspace.sh startup script would be the place to insert a command to remove the existing temp files before starting. > On May 23, 2022, at 2:42 PM, Majewski, Steven Dennis (sdm7g) wrote: > > > I just noticed this testing migration to 3.2.0 on my laptop, but I though it had something to do with how I started or stopped server while tracing other errors I was encountering. > ( See my other message about problems with Gem extensions. ) > > ? Steve > > >> On Mar 11, 2022, at 2:14 AM, Neal Fitzgerald > wrote: >> >> Hi All >> >> Has anyone else noticed that the temporary 'jetty-0_0_0_0-808x...war' directories in /data/tmp are not being cleared in 3.2.0? It seems to create a new set at each restart. Also asadmin doesn't have permissions to these directories anymore in 3.2.0. >> >> Is there some config setting I am missing? Is it safe just to clear these directories periodically? >> >> I already have 3.6Gb of /tmp files on my test 3.2.0 machine (admittedly after a lot of restarts re-installing and testing our PUI customisations) >> >> Cheers >> >> Neal Fitzgerald >> >> State Library of Victoria, Australia >> >> Neal Fitzgerald | Senior Specialist, Library Systems & Digital Preservation | Collection Development & Description >> State Library Victoria | 328 Swanston Street | Melbourne VIC 3000 >> T +61 3 8664 7103 | nfitzgerald at slv.vic.gov.au >> slv.vic.gov.au >> >> >> >> >> >> This message and any attachment is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please delete all copies of the message and its attachments and notify the sender immediately. Thank you. >> _______________________________________________ >> Archivesspace_Users_Group mailing list >> Archivesspace_Users_Group at lyralists.lyrasis.org >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3342 bytes Desc: not available URL: From Scott.Renton at ed.ac.uk Tue May 24 11:42:41 2022 From: Scott.Renton at ed.ac.uk (RENTON Scott) Date: Tue, 24 May 2022 15:42:41 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace backups on 3.2 failing Message-ID: Hi folks I upgraded an instance to v.3.2.0 on Friday, but notice that backups are failing (to do with the new external SOLR?). This is using /apps/archivesspace/scripts/backup.sh --mysqldump --output ${BACKUP_DIR}/archivesspace_backup_$DATE.zip as normal. Has the script changed substantially? We were on 2.8.1 previously. Error looks like this: Loading ArchivesSpace configuration file from path: /apps/archivesspace/config/config.rb WARNING: The parameter 'pui_email_delivery_method' was already set WARNING: The parameter 'pui_email_perform_deliveries' was already set WARNING: The parameter 'pui_email_raise_delivery_errors' was already set Loading ArchivesSpace configuration file from path: /apps/archivesspace/config/config.rb WARNING: The parameter 'pui_email_delivery_method' was already set WARNING: The parameter 'pui_email_perform_deliveries' was already set WARNING: The parameter 'pui_email_raise_delivery_errors' was already set 2022-05-24 14:32:48 +0100: Writing backup to /apps/backups/archivesspace_backup_220524_143245.zip ERROR: Solr snapshot failed (Solr snapshot failed: Problem when getting snapshot details: Error 404 Not Found

HTTP ERROR 404 Not Found

URI:/replication
STATUS:404
MESSAGE:Not Found
SERVLET:-
Otherwise the SOLR seems to be working fine, so I'm assuming my config is ok: AppConfig[:solr_url] = "http://localhost:8983/solr/archivesspace" AppConfig[:solr_verify_checksums] = false AppConfig[:data_directory] = File.join("/apps/solr/server/solr/archivesspace/data") I did wonder if it was the location of the data_directory that was the issue- it had been away from the solr core, but even after repointing that (above), I get the above error. Cheers Scott ========== Scott Renton Digital Library Development & Systems Floor F East Argyle House 515219 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.morrison at bodleian.ox.ac.uk Tue May 24 11:56:18 2022 From: andrew.morrison at bodleian.ox.ac.uk (Andrew Morrison) Date: Tue, 24 May 2022 16:56:18 +0100 Subject: [Archivesspace_Users_Group] ArchivesSpace backups on 3.2 failing In-Reply-To: References: Message-ID: Does your external Solr's "archivesspace" core define a requestHandler whose class is "solr.ReplicationHandler" in its solrconfig.xml? Is the name "/replication"? Andrew. On 24/05/2022 16:42, RENTON Scott wrote: > Hi folks > > I upgraded an instance to v.3.2.0 on Friday, but notice that backups > are failing (to do with the new external SOLR?). This is using > > /apps/archivesspace/scripts/backup.sh > --mysqldump--output${BACKUP_DIR}/archivesspace_backup_$DATE.zip > > > as normal. Has the script changed substantially? We were on 2.8.1 > previously. > > Error looks like this: > > Loading ArchivesSpace configuration file from path: > /apps/archivesspace/config/config.rb > > WARNING: The parameter 'pui_email_delivery_method' was already set > > WARNING: The parameter 'pui_email_perform_deliveries' was already set > > WARNING: The parameter 'pui_email_raise_delivery_errors' was already set > > Loading ArchivesSpace configuration file from path: > /apps/archivesspace/config/config.rb > > WARNING: The parameter 'pui_email_delivery_method' was already set > > WARNING: The parameter 'pui_email_perform_deliveries' was already set > > WARNING: The parameter 'pui_email_raise_delivery_errors' was already set > > 2022-05-24 14:32:48 +0100: Writing backup to > /apps/backups/archivesspace_backup_220524_143245.zip > > ERROR: Solr snapshot failed (Solr snapshot failed: Problem when > getting snapshot details: > > > > > > Error 404 Not Found > > > >

HTTP ERROR 404 Not Found

> > > > > > > > > > > >
URI:/replication
STATUS:404
MESSAGE:Not Found
SERVLET:-
> > > > Otherwise the SOLR seems to be working fine, so I'm assuming my config > is ok: > > AppConfig[:solr_url] = "http://localhost:8983/solr/archivesspace" > > AppConfig[:solr_verify_checksums] = false > > AppConfig[:data_directory] = > File.join("/apps/solr/server/solr/archivesspace/data") > > > > I did wonder if it was the location of the data_directory that was the > issue- it had been away from the solr core, but even after repointing > that (above), I get the above error. > > Cheers > Scott > > > ========== > > Scott Renton > > Digital Library Development & Systems > > Floor F East > > Argyle House > > 515219 > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. Is e buidheann > carthannais a th? ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, > ?ireamh cl?raidh SC005336. > > _______________________________________________ > 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: From Scott.Renton at ed.ac.uk Tue May 24 12:30:37 2022 From: Scott.Renton at ed.ac.uk (RENTON Scott) Date: Tue, 24 May 2022 16:30:37 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace backups on 3.2 failing In-Reply-To: References: Message-ID: Thanks Andrew. Yeah, here it is (it's just the default solrconfig.xml from archivesspace) Cheers Scott ========== Scott Renton Digital Library Development & Systems Floor F East Argyle House 515219 ________________________________ From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Andrew Morrison Sent: 24 May 2022 16:56 To: archivesspace_users_group at lyralists.lyrasis.org Subject: Re: [Archivesspace_Users_Group] ArchivesSpace backups on 3.2 failing This email was sent to you by someone outside the University. You should only click on links or attachments if you are certain that the email is genuine and the content is safe. Does your external Solr's "archivesspace" core define a requestHandler whose class is "solr.ReplicationHandler" in its solrconfig.xml? Is the name "/replication"? Andrew. On 24/05/2022 16:42, RENTON Scott wrote: Hi folks I upgraded an instance to v.3.2.0 on Friday, but notice that backups are failing (to do with the new external SOLR?). This is using /apps/archivesspace/scripts/backup.sh --mysqldump --output ${BACKUP_DIR}/archivesspace_backup_$DATE.zip as normal. Has the script changed substantially? We were on 2.8.1 previously. Error looks like this: Loading ArchivesSpace configuration file from path: /apps/archivesspace/config/config.rb WARNING: The parameter 'pui_email_delivery_method' was already set WARNING: The parameter 'pui_email_perform_deliveries' was already set WARNING: The parameter 'pui_email_raise_delivery_errors' was already set Loading ArchivesSpace configuration file from path: /apps/archivesspace/config/config.rb WARNING: The parameter 'pui_email_delivery_method' was already set WARNING: The parameter 'pui_email_perform_deliveries' was already set WARNING: The parameter 'pui_email_raise_delivery_errors' was already set 2022-05-24 14:32:48 +0100: Writing backup to /apps/backups/archivesspace_backup_220524_143245.zip ERROR: Solr snapshot failed (Solr snapshot failed: Problem when getting snapshot details: Error 404 Not Found

HTTP ERROR 404 Not Found

URI:/replication
STATUS:404
MESSAGE:Not Found
SERVLET:-
Otherwise the SOLR seems to be working fine, so I'm assuming my config is ok: AppConfig[:solr_url] = "http://localhost:8983/solr/archivesspace" AppConfig[:solr_verify_checksums] = false AppConfig[:data_directory] = File.join("/apps/solr/server/solr/archivesspace/data") I did wonder if it was the location of the data_directory that was the issue- it had been away from the solr core, but even after repointing that (above), I get the above error. Cheers Scott ========== Scott Renton Digital Library Development & Systems Floor F East Argyle House 515219 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th? ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336. _______________________________________________ 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: From bandstraj at hope.edu Wed May 25 08:22:10 2022 From: bandstraj at hope.edu (Jon Bandstra) Date: Wed, 25 May 2022 08:22:10 -0400 Subject: [Archivesspace_Users_Group] Missing gems after upgrade to 3.2.0? Message-ID: Hello, I recently upgraded from 2.8.1 to 3.2.0. In the log file, I now see messages about two gems not loading at startup ? Ignoring llhttp-ffi-0.3.1 because its extensions are not built. Try: gem pristine llhttp-ffi --version 0.3.1 Ignoring unf_ext-0.0.8 because its extensions are not built. Try: gem pristine unf_ext --version 0.0.8 Any thoughts on what might be causing this? Did I miss a step in the upgrade process? This instance of ArchivesSpace is running on Ubuntu 18.04 with Solr 8.11.1 and Java 8 (OpenJDK). I don't know if it's related to the gems issue, but I'm also getting errors like the following ? INFO -- : Started GET "/check_session?uri=%2Frepositories%2F2%2Fresources%2F1417" FATAL -- : ActionController::RoutingError (No route matches [GET] "/check_session") FATAL -- : actionpack (5.2.5) lib/action_dispatch/middleware/debug_exceptions.rb:65:in `call' And for what it's worth, the backup.sh script is failing after the upgrade to 3.2.0. This might be the same issue that Scott Renton reported on the listserv yesterday. The script worked fine with version 2.8.1. (See attached files for more complete log listings.) Thanks, Jon Bandstra -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Loading ArchivesSpace configuration file from path: /data/archivesspace/config/config.rb Loading ArchivesSpace configuration file from path: /data/archivesspace/config/config.rb Loading ArchivesSpace configuration file from path: /data/archivesspace/config/config.rb May 21, 2022 12:00:21 PM org.eclipse.jetty.util.log.Log initialized INFO: Logging initialized @34833ms to org.eclipse.jetty.util.log.Slf4jLog May 21, 2022 12:00:24 PM org.eclipse.jetty.server.Server doStart INFO: jetty-9.4.44.v20210927; built: 2021-09-27T23:02:44.612Z; git: 8da83308eeca865e495e53ef315a249d63ba9332; jvm 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07 May 21, 2022 12:00:25 PM org.eclipse.jetty.server.session.DefaultSessionIdManager doStart INFO: DefaultSessionIdManager workerName=node0 May 21, 2022 12:00:25 PM org.eclipse.jetty.server.session.DefaultSessionIdManager doStart INFO: No SessionScavenger set, using defaults May 21, 2022 12:00:25 PM org.eclipse.jetty.server.session.HouseKeeper startScavenging INFO: node0 Scavenging every 660000ms May 21, 2022 12:00:25 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: INFO: jruby 9.2.12.0 (2.5.7) 2020-07-01 db01a49ba6 OpenJDK 64-Bit Server VM 25.312-b07 on 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07 +jit [linux-x86_64] May 21, 2022 12:00:25 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: INFO: using a shared (threadsafe!) runtime uri:classloader:/jruby/rack/response.rb:294: warning: constant ::Fixnum is deprecated uri:classloader:/jruby/rack/core_ext.rb:26: warning: constant ::NativeException is deprecated Loading ArchivesSpace configuration file from path: /data/archivesspace/config/config.rb ArchivesSpaceThreadDump: Touch the file '/data/archivesspace/thread_dump_backend.txt' to trigger a thread dump Loading class `com.mysql.jdbc.Driver'. This is deprecated. The new driver class is `com.mysql.cj.jdbc.Driver'. The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary. I, [2022-05-21T12:01:17.192612 #2085] INFO -- : Thread-2002: All tables checked and confirmed set to UTF-8. Nice job! I, [2022-05-21T12:01:19.494451 #2085] INFO -- : Thread-2002: Solr config checksum verification ok. I, [2022-05-21T12:01:24.861390 #2085] INFO -- : Thread-2002: Starting job scheduler /data/archivesspace-3.2.0/gems/gems/rufus-scheduler-2.0.24/lib/rufus/sc/cronline.rb:80: warning: constant ::Fixnum is deprecated I, [2022-05-21T12:01:26.180486 #2085] INFO -- : Thread-2002: Updating system preferences I, [2022-05-21T12:01:27.269734 #2085] INFO -- : Thread-2938: Starting background job thread 2 (2938) I, [2022-05-21T12:01:27.266176 #2085] INFO -- : Thread-2936: Starting background job thread 1 (2936) May 21, 2022 12:01:27 PM org.eclipse.jetty.server.handler.ContextHandler doStart INFO: Started o.e.j.w.WebAppContext at 4a50d04a{/,file:///data/archivesspace-3.2.0/data/tmp/jetty-0_0_0_0-8089-backend_war-_-any-5949703376216524638/webapp/,AVAILABLE}{/data/archivesspace/wars/backend.war} May 21, 2022 12:01:27 PM org.eclipse.jetty.server.AbstractConnector doStart INFO: Started ServerConnector at 5e5beb8a{HTTP/1.1, (http/1.1)}{0.0.0.0:8089} May 21, 2022 12:01:27 PM org.eclipse.jetty.server.Server doStart INFO: Started @100994ms May 21, 2022 12:01:27 PM org.eclipse.jetty.server.Server doStart INFO: jetty-9.4.44.v20210927; built: 2021-09-27T23:02:44.612Z; git: 8da83308eeca865e495e53ef315a249d63ba9332; jvm 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07 May 21, 2022 12:01:27 PM org.eclipse.jetty.server.session.DefaultSessionIdManager doStart INFO: DefaultSessionIdManager workerName=node0 May 21, 2022 12:01:27 PM org.eclipse.jetty.server.session.DefaultSessionIdManager doStart INFO: No SessionScavenger set, using defaults May 21, 2022 12:01:27 PM org.eclipse.jetty.server.session.HouseKeeper startScavenging INFO: node0 Scavenging every 600000ms May 21, 2022 12:01:27 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: INFO: jruby 9.2.12.0 (2.5.7) 2020-07-01 db01a49ba6 OpenJDK 64-Bit Server VM 25.312-b07 on 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07 +jit [linux-x86_64] May 21, 2022 12:01:27 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: INFO: using a shared (threadsafe!) runtime uri:classloader:/jruby/rack/response.rb:294: warning: constant ::Fixnum is deprecated uri:classloader:/jruby/rack/core_ext.rb:26: warning: constant ::NativeException is deprecated Loading ArchivesSpace configuration file from path: /data/archivesspace/config/config.rb Ignoring llhttp-ffi-0.3.1 because its extensions are not built. Try: gem pristine llhttp-ffi --version 0.3.1 Ignoring unf_ext-0.0.8 because its extensions are not built. Try: gem pristine unf_ext --version 0.0.8 ArchivesSpaceThreadDump: Touch the file '/data/archivesspace/thread_dump_indexer.txt' to trigger a thread dump I, [2022-05-21T12:01:38.386588 #2085] INFO -- : Thread-2954: Starting periodic indexer I, [2022-05-21T12:01:38.387815 #2085] INFO -- : Thread-2954: Starting PUI indexer I, [2022-05-21T12:01:38.391671 #2085] INFO -- : Thread-2956: Staff Indexer [2022-05-21 12:01:38 -0400] Running index round I, [2022-05-21T12:01:42.149343 #2085] INFO -- : Thread-2956: Staff Indexer [2022-05-21 12:01:42 -0400] Index round complete I, [2022-05-21T12:01:43.391530 #2085] INFO -- : Thread-2992: Starting realtime indexer for: http://localhost:8089 May 21, 2022 12:01:43 PM org.eclipse.jetty.server.handler.ContextHandler doStart INFO: Started o.e.j.w.WebAppContext at 66297b63{/aspace-indexer,file:///data/archivesspace-3.2.0/data/tmp/jetty-0_0_0_0-8091-indexer_war-_aspace-indexer-any-4130224190858803447/webapp/,AVAILABLE}{/data/archivesspace/wars/indexer.war} May 21, 2022 12:01:43 PM org.eclipse.jetty.server.AbstractConnector doStart INFO: Started ServerConnector at 40477d52{HTTP/1.1, (http/1.1)}{0.0.0.0:8091} May 21, 2022 12:01:43 PM org.eclipse.jetty.server.Server doStart INFO: Started @116666ms May 21, 2022 12:01:43 PM org.eclipse.jetty.server.Server doStart INFO: jetty-9.4.44.v20210927; built: 2021-09-27T23:02:44.612Z; git: 8da83308eeca865e495e53ef315a249d63ba9332; jvm 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07 May 21, 2022 12:01:44 PM org.eclipse.jetty.server.session.DefaultSessionIdManager doStart INFO: DefaultSessionIdManager workerName=node0 May 21, 2022 12:01:44 PM org.eclipse.jetty.server.session.DefaultSessionIdManager doStart INFO: No SessionScavenger set, using defaults May 21, 2022 12:01:44 PM org.eclipse.jetty.server.session.HouseKeeper startScavenging INFO: node0 Scavenging every 660000ms May 21, 2022 12:01:44 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: INFO: jruby 9.2.12.0 (2.5.7) 2020-07-01 db01a49ba6 OpenJDK 64-Bit Server VM 25.312-b07 on 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07 +jit [linux-x86_64] May 21, 2022 12:01:44 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: INFO: using a shared (threadsafe!) runtime uri:classloader:/jruby/rack/response.rb:294: warning: constant ::Fixnum is deprecated uri:classloader:/jruby/rack/core_ext.rb:26: warning: constant ::NativeException is deprecated Loading ArchivesSpace configuration file from path: /data/archivesspace/config/config.rb DEPRECATION WARNING: Sprockets method `register_engine` is deprecated. Please register a mime type using `register_mime_type` then use `register_compressor` or `register_transformer`. https://github.com/rails/sprockets/blob/master/guides/extending_sprockets.md#supporting-all-versions-of-sprockets-in-processors (called from block in Railtie at /data/archivesspace-3.2.0/gems/gems/less-rails-2.8.0/lib/less/rails/railtie.rb:16) DEPRECATION WARNING: You are using a deprecated processor interface Less::Rails::ImportProcessor. Please update your processor interface: https://github.com/rails/sprockets/blob/master/guides/extending_sprockets.md#supporting-all-versions-of-sprockets-in-processors (called from block in Railtie at /data/archivesspace-3.2.0/gems/gems/less-rails-2.8.0/lib/less/rails/railtie.rb:21) ArchivesSpaceThreadDump: Touch the file '/data/archivesspace/thread_dump_frontend.txt' to trigger a thread dump Found repository menu items for plug-ins: ["lcnaf"] WARNING: The parameter 'frontend_prefix' is now deprecated. Please use 'frontend_proxy_prefix' instead. May 21, 2022 12:02:04 PM org.eclipse.jetty.server.handler.ContextHandler doStart INFO: Started o.e.j.w.WebAppContext at 65f85228{/,file:///data/archivesspace-3.2.0/data/tmp/jetty-0_0_0_0-8080-frontend_war-_-any-3601918747138881450/webapp/,AVAILABLE}{/data/archivesspace/wars/frontend.war} May 21, 2022 12:02:04 PM org.eclipse.jetty.server.handler.ContextHandler doStart INFO: Started o.e.j.s.h.ContextHandler at 98be09f{/assets,null,AVAILABLE} May 21, 2022 12:02:04 PM org.eclipse.jetty.server.AbstractConnector doStart INFO: Started ServerConnector at 3a8a2089{HTTP/1.1, (http/1.1)}{0.0.0.0:8080} May 21, 2022 12:02:04 PM org.eclipse.jetty.server.Server doStart INFO: Started @137509ms May 21, 2022 12:02:04 PM org.eclipse.jetty.server.Server doStart INFO: jetty-9.4.44.v20210927; built: 2021-09-27T23:02:44.612Z; git: 8da83308eeca865e495e53ef315a249d63ba9332; jvm 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07 May 21, 2022 12:02:05 PM org.eclipse.jetty.server.session.DefaultSessionIdManager doStart INFO: DefaultSessionIdManager workerName=node0 May 21, 2022 12:02:05 PM org.eclipse.jetty.server.session.DefaultSessionIdManager doStart INFO: No SessionScavenger set, using defaults May 21, 2022 12:02:05 PM org.eclipse.jetty.server.session.HouseKeeper startScavenging INFO: node0 Scavenging every 600000ms May 21, 2022 12:02:05 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: INFO: jruby 9.2.12.0 (2.5.7) 2020-07-01 db01a49ba6 OpenJDK 64-Bit Server VM 25.312-b07 on 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07 +jit [linux-x86_64] May 21, 2022 12:02:05 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: INFO: using a shared (threadsafe!) runtime uri:classloader:/jruby/rack/response.rb:294: warning: constant ::Fixnum is deprecated uri:classloader:/jruby/rack/core_ext.rb:26: warning: constant ::NativeException is deprecated Loading ArchivesSpace configuration file from path: /data/archivesspace/config/config.rb I, [2022-05-21T12:02:08.393367 #2085] INFO -- : Thread-3232: PUI Indexer [2022-05-21 12:02:08 -0400] Running index round I, [2022-05-21T12:02:09.844515 #2085] INFO -- : Thread-3232: PUI Indexer [2022-05-21 12:02:09 -0400] Index round complete I, [2022-05-21T12:02:12.150698 #2085] INFO -- : Thread-2956: Staff Indexer [2022-05-21 12:02:12 -0400] Running index round ArchivesSpaceThreadDump: Touch the file '/data/archivesspace/thread_dump_pui.txt' to trigger a thread dump I, [2022-05-21T12:02:14.283535 #2085] INFO -- : Thread-2956: Staff Indexer [2022-05-21 12:02:14 -0400] Index round complete May 21, 2022 12:02:17 PM org.eclipse.jetty.server.handler.ContextHandler doStart INFO: Started o.e.j.w.WebAppContext at 59c81e46{/,file:///data/archivesspace-3.2.0/data/tmp/jetty-0_0_0_0-8081-public_war-_-any-1544133269053956886/webapp/,AVAILABLE}{/data/archivesspace/wars/public.war} May 21, 2022 12:02:17 PM org.eclipse.jetty.server.handler.ContextHandler doStart INFO: Started o.e.j.s.h.ContextHandler at 3ae8f170{/assets,null,AVAILABLE} May 21, 2022 12:02:17 PM org.eclipse.jetty.server.AbstractConnector doStart INFO: Started ServerConnector at a9d3bd0{HTTP/1.1, (http/1.1)}{0.0.0.0:8081} May 21, 2022 12:02:17 PM org.eclipse.jetty.server.Server doStart INFO: Started @150605ms May 21, 2022 12:02:17 PM org.eclipse.jetty.server.Server doStart INFO: jetty-9.4.44.v20210927; built: 2021-09-27T23:02:44.612Z; git: 8da83308eeca865e495e53ef315a249d63ba9332; jvm 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07 May 21, 2022 12:02:17 PM org.eclipse.jetty.server.handler.ContextHandler doStart INFO: Started o.e.j.s.h.ContextHandler at 35fbebc7{/archivesspace,null,AVAILABLE} May 21, 2022 12:02:17 PM org.eclipse.jetty.server.AbstractConnector doStart INFO: Started ServerConnector at 60513bea{HTTP/1.1, (http/1.1)}{0.0.0.0:8888} May 21, 2022 12:02:17 PM org.eclipse.jetty.server.Server doStart INFO: Started @150651ms May 21, 2022 12:02:17 PM org.eclipse.jetty.server.Server doStart INFO: jetty-9.4.44.v20210927; built: 2021-09-27T23:02:44.612Z; git: 8da83308eeca865e495e53ef315a249d63ba9332; jvm 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07 May 21, 2022 12:02:17 PM org.eclipse.jetty.server.session.DefaultSessionIdManager doStart INFO: DefaultSessionIdManager workerName=node0 May 21, 2022 12:02:17 PM org.eclipse.jetty.server.session.DefaultSessionIdManager doStart INFO: No SessionScavenger set, using defaults May 21, 2022 12:02:17 PM org.eclipse.jetty.server.session.HouseKeeper startScavenging INFO: node0 Scavenging every 660000ms May 21, 2022 12:02:17 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: INFO: jruby 9.2.12.0 (2.5.7) 2020-07-01 db01a49ba6 OpenJDK 64-Bit Server VM 25.312-b07 on 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07 +jit [linux-x86_64] May 21, 2022 12:02:17 PM org.eclipse.jetty.server.handler.ContextHandler$Context log INFO: INFO: using a shared (threadsafe!) runtime uri:classloader:/jruby/rack/response.rb:294: warning: constant ::Fixnum is deprecated uri:classloader:/jruby/rack/core_ext.rb:26: warning: constant ::NativeException is deprecated Loading ArchivesSpace configuration file from path: /data/archivesspace/config/config.rb Ignoring llhttp-ffi-0.3.1 because its extensions are not built. Try: gem pristine llhttp-ffi --version 0.3.1 ArchivesSpaceThreadDump: Touch the file '/data/archivesspace/thread_dump_oai.txt' to trigger a thread dump May 21, 2022 12:02:19 PM org.eclipse.jetty.server.handler.ContextHandler doStart INFO: Started o.e.j.w.WebAppContext at 7bdfb1c0{/,file:///data/archivesspace-3.2.0/data/tmp/jetty-0_0_0_0-8082-oai_war-_-any-3645928830000807543/webapp/,AVAILABLE}{/data/archivesspace/wars/oai.war} May 21, 2022 12:02:19 PM org.eclipse.jetty.server.AbstractConnector doStart INFO: Started ServerConnector at 62963fb0{HTTP/1.1, (http/1.1)}{0.0.0.0:8082} May 21, 2022 12:02:19 PM org.eclipse.jetty.server.Server doStart INFO: Started @152526ms ************************************************************ Welcome to ArchivesSpace! You can now point your browser to http://localhost:8080 ************************************************************ -------------- next part -------------- I, [2022-05-24T16:04:04.828418 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Started GET "/repositories/2/resources/627" for 209.140.248.64 at 2022-05-24 16:04:04 -0400 I, [2022-05-24T16:04:04.831302 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Processing by ResourcesController#show as HTML I, [2022-05-24T16:04:04.831558 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Parameters: {"repo_slug"=>"2", "slug_or_id"=>"627"} I, [2022-05-24T16:04:04.889879 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendering resources/show.html.erb within layouts/application I, [2022-05-24T16:04:04.890748 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_idbadge.html.erb (0.3ms) I, [2022-05-24T16:04:04.892169 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_cite_page_action.html.erb (0.9ms) I, [2022-05-24T16:04:04.909929 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_request_hiddens.html.erb (17.3ms) I, [2022-05-24T16:04:04.910342 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered /data/archivesspace/plugins/local/public/views/shared/_request_page_action.html.erb (17.9ms) I, [2022-05-24T16:04:04.911758 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_print_page_action.html.erb (1.1ms) I, [2022-05-24T16:04:04.912227 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_staff_link_action.html.erb (0.2ms) I, [2022-05-24T16:04:04.912324 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_page_actions.html.erb (21.3ms) I, [2022-05-24T16:04:04.912787 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_breadcrumbs.html.erb (0.3ms) I, [2022-05-24T16:04:04.913464 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered resources/_resource_tab.erb (0.3ms) I, [2022-05-24T16:04:04.913957 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered resources/_resource_tab.erb (0.2ms) I, [2022-05-24T16:04:04.914418 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered resources/_resource_tab.erb (0.2ms) I, [2022-05-24T16:04:04.914521 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered resources/_resource_alltabs.erb (1.6ms) I, [2022-05-24T16:04:04.914809 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_digital.html.erb (0.1ms) I, [2022-05-24T16:04:04.915251 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_single_note.html.erb (0.1ms) I, [2022-05-24T16:04:04.915617 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_dates.html.erb (0.1ms) I, [2022-05-24T16:04:04.916093 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_metadata_rights_declarations.html.erb (0.1ms) I, [2022-05-24T16:04:04.918938 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_multi_notes.html.erb (0.1ms) I, [2022-05-24T16:04:04.919583 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered resources/_finding_aid.html.erb (0.4ms) I, [2022-05-24T16:04:04.919917 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_accordion_panel.html.erb (0.1ms) I, [2022-05-24T16:04:04.920811 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered repositories/_full_repo.html.erb (0.4ms) I, [2022-05-24T16:04:04.920907 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered repositories/_repository_details.html.erb (0.8ms) I, [2022-05-24T16:04:04.921186 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_accordion_panel.html.erb (0.1ms) I, [2022-05-24T16:04:04.922839 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_record_innards.html.erb (7.8ms) I, [2022-05-24T16:04:04.924307 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_search_collection_form.html.erb (1.1ms) I, [2022-05-24T16:04:04.925058 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_children_tree.html.erb (0.5ms) I, [2022-05-24T16:04:04.925595 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered cite/_modal_body.html.erb (0.2ms) I, [2022-05-24T16:04:04.926057 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_modal.html.erb (0.2ms) I, [2022-05-24T16:04:04.943780 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_request_hiddens.html.erb (17.2ms) I, [2022-05-24T16:04:04.945200 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_request_form.html.erb (18.9ms) I, [2022-05-24T16:04:04.945901 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_modal.html.erb (0.3ms) I, [2022-05-24T16:04:04.946096 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_modal_actions.html.erb (20.8ms) I, [2022-05-24T16:04:04.946202 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered resources/show.html.erb within layouts/application (56.2ms) I, [2022-05-24T16:04:04.956048 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_metadata.html.erb (8.0ms) I, [2022-05-24T16:04:04.957514 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendering /data/archivesspace/plugins/local/public/views/layout_head.html.erb I, [2022-05-24T16:04:04.957929 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered /data/archivesspace/plugins/local/public/views/layout_head.html.erb (0.3ms) I, [2022-05-24T16:04:04.958401 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered shared/_skipnav.html.erb (0.2ms) I, [2022-05-24T16:04:04.958607 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered /data/archivesspace/plugins/local/public/views/shared/_header.html.erb (0.0ms) I, [2022-05-24T16:04:04.959207 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered /data/archivesspace/plugins/local/public/views/shared/_navigation.html.erb (0.4ms) I, [2022-05-24T16:04:04.959587 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Rendered /data/archivesspace/plugins/local/public/views/shared/_footer.html.erb (0.1ms) I, [2022-05-24T16:04:04.960025 #2085] INFO -- : [dc4d7078-d533-4a46-82f2-e1b1ac6ef886] Completed 200 OK in 128ms (Views: 71.2ms) I, [2022-05-24T16:04:05.322137 #2085] INFO -- : [098354da-8504-470f-80c3-cd433ba799ec] Started GET "/repositories/2/resources/627/tree/root" for 209.140.248.64 at 2022-05-24 16:04:05 -0400 I, [2022-05-24T16:04:05.324649 #2085] INFO -- : [098354da-8504-470f-80c3-cd433ba799ec] Processing by ResourcesController#tree_root as JSON I, [2022-05-24T16:04:05.324836 #2085] INFO -- : [098354da-8504-470f-80c3-cd433ba799ec] Parameters: {"rid"=>"2", "id"=>"627"} I, [2022-05-24T16:04:05.348841 #2085] INFO -- : [098354da-8504-470f-80c3-cd433ba799ec] Completed 200 OK in 24ms (Views: 0.7ms) I, [2022-05-24T16:04:05.384589 #2085] INFO -- : [71884c45-04f0-4ec8-af8e-a477d422724d] Started GET "/check_session?uri=%2Frepositories%2F2%2Fresources%2F627" for 209.140.248.64 at 2022-05-24 16:04:05 -0400 F, [2022-05-24T16:04:05.386062 #2085] FATAL -- : [71884c45-04f0-4ec8-af8e-a477d422724d] F, [2022-05-24T16:04:05.386172 #2085] FATAL -- : [71884c45-04f0-4ec8-af8e-a477d422724d] ActionController::RoutingError (No route matches [GET] "/check_session"): F, [2022-05-24T16:04:05.386200 #2085] FATAL -- : [71884c45-04f0-4ec8-af8e-a477d422724d] F, [2022-05-24T16:04:05.386236 #2085] FATAL -- : [71884c45-04f0-4ec8-af8e-a477d422724d] actionpack (5.2.5) lib/action_dispatch/middleware/debug_exceptions.rb:65:in `call' [71884c45-04f0-4ec8-af8e-a477d422724d] actionpack (5.2.5) lib/action_dispatch/middleware/show_exceptions.rb:33:in `call' [71884c45-04f0-4ec8-af8e-a477d422724d] railties (5.2.5) lib/rails/rack/logger.rb:38:in `call_app' [71884c45-04f0-4ec8-af8e-a477d422724d] railties (5.2.5) lib/rails/rack/logger.rb:26:in `block in call' [71884c45-04f0-4ec8-af8e-a477d422724d] activesupport (5.2.5) lib/active_support/tagged_logging.rb:71:in `block in tagged' [71884c45-04f0-4ec8-af8e-a477d422724d] activesupport (5.2.5) lib/active_support/tagged_logging.rb:28:in `tagged' [71884c45-04f0-4ec8-af8e-a477d422724d] activesupport (5.2.5) lib/active_support/tagged_logging.rb:71:in `tagged' [71884c45-04f0-4ec8-af8e-a477d422724d] railties (5.2.5) lib/rails/rack/logger.rb:26:in `call' [71884c45-04f0-4ec8-af8e-a477d422724d] actionpack (5.2.5) lib/action_dispatch/middleware/remote_ip.rb:81:in `call' [71884c45-04f0-4ec8-af8e-a477d422724d] actionpack (5.2.5) lib/action_dispatch/middleware/request_id.rb:27:in `call' [71884c45-04f0-4ec8-af8e-a477d422724d] rack (2.2.3) lib/rack/method_override.rb:24:in `call' [71884c45-04f0-4ec8-af8e-a477d422724d] rack (2.2.3) lib/rack/runtime.rb:22:in `call' [71884c45-04f0-4ec8-af8e-a477d422724d] activesupport (5.2.5) lib/active_support/cache/strategy/local_cache_middleware.rb:29:in `call' [71884c45-04f0-4ec8-af8e-a477d422724d] actionpack (5.2.5) lib/action_dispatch/middleware/executor.rb:14:in `call' [71884c45-04f0-4ec8-af8e-a477d422724d] actionpack (5.2.5) lib/action_dispatch/middleware/static.rb:127:in `call' [71884c45-04f0-4ec8-af8e-a477d422724d] rack (2.2.3) lib/rack/sendfile.rb:110:in `call' [71884c45-04f0-4ec8-af8e-a477d422724d] railties (5.2.5) lib/rails/engine.rb:524:in `call' [71884c45-04f0-4ec8-af8e-a477d422724d] uri:classloader:/rack/handler/servlet.rb:22:in `call' I, [2022-05-24T16:04:05.405428 #2085] INFO -- : [fecf474a-6271-426a-8653-a6e48b7c200c] Started GET "/repositories/2/resources/627/tree/node?node=%2Frepositories%2F2%2Fresources%2F627" for 209.140.248.64 at 2022-05-24 16:04:05 -0400 I, [2022-05-24T16:04:05.407331 #2085] INFO -- : [fecf474a-6271-426a-8653-a6e48b7c200c] Processing by ResourcesController#tree_node as JSON I, [2022-05-24T16:04:05.407446 #2085] INFO -- : [fecf474a-6271-426a-8653-a6e48b7c200c] Parameters: {"node"=>"/repositories/2/resources/627", "rid"=>"2", "id"=>"627"} I, [2022-05-24T16:04:05.424340 #2085] INFO -- : [fecf474a-6271-426a-8653-a6e48b7c200c] Completed 404 Not Found in 17ms (Views: 0.5ms) -------------- next part -------------- Loading ArchivesSpace configuration file from path: /data/archivesspace/config/config.rb Loading ArchivesSpace configuration file from path: /data/archivesspace/config/config.rb Loading ArchivesSpace configuration file from path: /data/archivesspace/config/config.rb 2022-05-25 08:18:16 -0400: Writing backup to /var/tmp/archivesspace-2022-05-25.zip ERROR: Solr snapshot failed (Solr snapshot failed: Problem when getting snapshot details: Error 404 Not Found

HTTP ERROR 404 Not Found

URI:/replication
STATUS:404
MESSAGE:Not Found
SERVLET:-
: ["uri:classloader:/solr_snapshotter.rb:48:in `last_snapshot_status'", "uri:classloader:/solr_snapshotter.rb:99:in `do_snapshot'", "uri:classloader:/solr_snapshotter.rb:62:in `block in snapshot'", "uri:classloader:/solr_snapshotter.rb:60:in `snapshot'", "../launcher/backup/lib/backup.rb:124:in `backup'", "../launcher/backup/lib/backup.rb:176:in `main'", "../launcher/backup/lib/backup.rb:180:in `
'"]) - attempt 0 From Corey.Schmidt at uga.edu Wed May 25 08:56:44 2022 From: Corey.Schmidt at uga.edu (Corey Schmidt) Date: Wed, 25 May 2022 12:56:44 +0000 Subject: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace In-Reply-To: <1bc9268864734e4b92ba20584ef975ff@antwerpen.be> References: <1bc9268864734e4b92ba20584ef975ff@antwerpen.be> Message-ID: Hey Ron, Glad to see you reaching out! I?m not sure if others have emailed you regarding this, so I?ll put in my 2 cents worth. ? From what I understand, there is no mechanism within ArchivesSpace that provides a structured ?Agents/Related Accessions? type link from one resource to another, nor one archival object to another. ? Have you considered using the ?Related Materials? note ()? The advantage with this is the note is made specifically for related materials either within the repository or without and you don?t need a full URL, just the ArchivesSpace ID if you?re using the PUI, like so: Related Collection title. The problem with this is you have to enter the info by hand, which is error prone (we?ve scheduled a yearly ?data audit? to help us catch errors like these). ? I don?t know of any institution that has developed a plugin, nor is this on the roadmap I think. Nevertheless, you can submit a JIRA ticket for this feature (how to do that linked here) ? explaining how you want it to work with as much detail as possible. The Development Priority Team will then determine if the ArchivesSpace development team or community can/should prioritize it in future releases. The more attention a ticket gets (comments, clarifications, etc.) the more likely it is to be implemented (great YouTube video here about the process). I hope this is helpful, but if you?d like to talk more about it, feel free to email me: Corey.Schmidt at uga.edu. To everyone on the listserv, please feel free to correct any of this info if it?s incorrect/misleading. Sincerely, Corey Corey Schmidt Special Collections Libraries | Project Management Librarian/Archivist 300 S Hull St | Athens, GA 30605 Corey.Schmidt at uga.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Ron Van den Branden Sent: Wednesday, May 18, 2022 3:45 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace [EXTERNAL SENDER - PROCEED CAUTIOUSLY] Hi all, This is my first message to this group; apologies if this has been addressed before (tried my best researching the list archive at https://www.mail-archive.com/archivesspace_users_group at lyralists.lyrasis.org/). At my institution, we?re preparing a migration of data from a previous archival description system to ArchivesSpace. The previous system allowed for structured links between archival descriptions within the system. For example, resource A could point to resource B within the same system by means of a system identifier, which the system would resolve to a full link in the PUI. This is functioning in a similar way as Agents Links or Related Accessions sections in ArchivesSpace; only with a different record type (resources / archival objects instead of agents, resp. accessions). Please correct me if I?m wrong, but I don?t see an immediate equivalent mechanism in ArchivesSpace. This raises some questions: * Am I overlooking the obvious, and does ArchivesSpace provide a structured mechanism to point from a Resource / Archival Object to another Resource / Archival Object? * If not, I do see the External Documents section as a close fit, with the semantic drawback that these linked resources are not really external but rather internal. More substantially, though, External Documents only allows for a literal URL, which is less elegant, more error-prone, and less sustainable than the dynamically generated links provided via Agent Links or Related Accessions. * If not, is this something that?s on a development roadmap, or have others implemented this as a plug-in? Many thanks for your thoughts! Best, Ron Ron Van den Branden | functioneel analist - applicatiebeheerder Letterenhuis Stad Antwerpen | Talentontwikkeling en Vrijetijdsbeleving | Musea en Erfgoed Minderbroedersstraat 22, 2000 Antwerpen ? Grote Markt 1, 2000 Antwerpen gsm +32 0485 02 80 50 | tel. +32 3 222 93 30 letterenhuis.be | instagram | facebook Proclaimer Vergissen is menselijk. Dus als deze e-mail, samen met eventuele bijlagen, niet voor u bestemd is, vragen we u vriendelijk om dat te melden aan de afzender. Deze e-mail en de bijlagen zijn namelijk offici?le documenten van de stad Antwerpen. Ze kunnen vertrouwelijke of persoonlijke informatie bevatten. Als stad nemen we privacy heel serieus en willen we als een goede huisvader waken over de vertrouwelijkheid van documenten. Als u dit bericht per vergissing hebt ontvangen of ergens hebt gevonden, wees dan zo eerlijk om het meteen te verwijderen en het niet verder te verspreiden of te kopi?ren. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ron.VandenBranden at antwerpen.be Wed May 25 10:04:58 2022 From: Ron.VandenBranden at antwerpen.be (Ron Van den Branden) Date: Wed, 25 May 2022 14:04:58 +0000 Subject: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace In-Reply-To: References: <1bc9268864734e4b92ba20584ef975ff@antwerpen.be> Message-ID: Hi Corey, Many thanks for your helpful reply! In our current data, these structured links are indeed connected to a field that maps to in ArchivesSpace, so that?s indeed the destination we had in mind. Your example for embedding ArchivesSpace-internal links via the ArchivesSpace ID for a @href attribute was really helpful and finally made me get it working in the test instance, great! That?s a useful mechanism, though I fully agree the manual input process is brittle, even with the (limited) ?mixed content? completion help. In order to make the most semantic sense, as you exemplified with the example, our colleagues and volunteers describing the archives would have to be knowledgeable of XML syntax rules, and the suitable EAD structures for the information they?d want to enter. Yet, even if a new structured resource-to-resource link field would be too far off the implementation horizon, perhaps a general improvement for adding such internal cross-links in text fields in a more guided way could be of interest. I?ll think about it! Finally, your data audit remark sounds intriguing and -considering the amount of data cleanup this data migration project has confronted us with- a vital part of best practice. Would you mind elaborating on that, or pointing me to any available documentation? Best, Ron Van: archivesspace_users_group-bounces at lyralists.lyrasis.org Namens Corey Schmidt Verzonden: woensdag 25 mei 2022 14:57 Aan: Archivesspace Users Group Onderwerp: Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace Hey Ron, Glad to see you reaching out! I?m not sure if others have emailed you regarding this, so I?ll put in my 2 cents worth. * From what I understand, there is no mechanism within ArchivesSpace that provides a structured ?Agents/Related Accessions? type link from one resource to another, nor one archival object to another. * Have you considered using the ?Related Materials? note ()? The advantage with this is the note is made specifically for related materials either within the repository or without and you don?t need a full URL, just the ArchivesSpace ID if you?re using the PUI, like so: Related Collection title. The problem with this is you have to enter the info by hand, which is error prone (we?ve scheduled a yearly ?data audit? to help us catch errors like these). * I don?t know of any institution that has developed a plugin, nor is this on the roadmap I think. Nevertheless, you can submit a JIRA ticket for this feature (how to do that linked here) ? explaining how you want it to work with as much detail as possible. The Development Priority Team will then determine if the ArchivesSpace development team or community can/should prioritize it in future releases. The more attention a ticket gets (comments, clarifications, etc.) the more likely it is to be implemented (great YouTube video here about the process). I hope this is helpful, but if you?d like to talk more about it, feel free to email me: Corey.Schmidt at uga.edu. To everyone on the listserv, please feel free to correct any of this info if it?s incorrect/misleading. Sincerely, Corey Corey Schmidt Special Collections Libraries | Project Management Librarian/Archivist 300 S Hull St | Athens, GA 30605 Corey.Schmidt at uga.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org > On Behalf Of Ron Van den Branden Sent: Wednesday, May 18, 2022 3:45 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace [EXTERNAL SENDER - PROCEED CAUTIOUSLY] Hi all, This is my first message to this group; apologies if this has been addressed before (tried my best researching the list archive at https://www.mail-archive.com/archivesspace_users_group at lyralists.lyrasis.org/). At my institution, we?re preparing a migration of data from a previous archival description system to ArchivesSpace. The previous system allowed for structured links between archival descriptions within the system. For example, resource A could point to resource B within the same system by means of a system identifier, which the system would resolve to a full link in the PUI. This is functioning in a similar way as Agents Links or Related Accessions sections in ArchivesSpace; only with a different record type (resources / archival objects instead of agents, resp. accessions). Please correct me if I?m wrong, but I don?t see an immediate equivalent mechanism in ArchivesSpace. This raises some questions: * Am I overlooking the obvious, and does ArchivesSpace provide a structured mechanism to point from a Resource / Archival Object to another Resource / Archival Object? * If not, I do see the External Documents section as a close fit, with the semantic drawback that these linked resources are not really external but rather internal. More substantially, though, External Documents only allows for a literal URL, which is less elegant, more error-prone, and less sustainable than the dynamically generated links provided via Agent Links or Related Accessions. * If not, is this something that?s on a development roadmap, or have others implemented this as a plug-in? Many thanks for your thoughts! Best, Ron Ron Van den Branden | functioneel analist - applicatiebeheerder Letterenhuis Stad Antwerpen | Talentontwikkeling en Vrijetijdsbeleving | Musea en Erfgoed Minderbroedersstraat 22, 2000 Antwerpen ? Grote Markt 1, 2000 Antwerpen gsm +32 0485 02 80 50 | tel. +32 3 222 93 30 letterenhuis.be | instagram | facebook Proclaimer Vergissen is menselijk. Dus als deze e-mail, samen met eventuele bijlagen, niet voor u bestemd is, vragen we u vriendelijk om dat te melden aan de afzender. Deze e-mail en de bijlagen zijn namelijk offici?le documenten van de stad Antwerpen. Ze kunnen vertrouwelijke of persoonlijke informatie bevatten. Als stad nemen we privacy heel serieus en willen we als een goede huisvader waken over de vertrouwelijkheid van documenten. Als u dit bericht per vergissing hebt ontvangen of ergens hebt gevonden, wees dan zo eerlijk om het meteen te verwijderen en het niet verder te verspreiden of te kopi?ren. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory_nimer at byu.edu Wed May 25 11:15:00 2022 From: cory_nimer at byu.edu (Cory Nimer) Date: Wed, 25 May 2022 15:15:00 +0000 Subject: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace In-Reply-To: References: <1bc9268864734e4b92ba20584ef975ff@antwerpen.be> Message-ID: Ron, I would agree that it would be preferable to have a more EAD3-friendly configuration for related materials notes, at least in order to reduce/remove the need for mixed content within these notes. I don't know if there is widespread interest in moving implementing something more like the Agents module's Sources subrecord or the Metadata Rights Declarations with their fields for recording a descriptive note and a URL separately. It looks like the project has already rejected the idea of being allowing linking between different records within the database, though (ANW-763; https://archivesspace.atlassian.net/browse/ANW-763). Best, Cory Nimer University Archivist Brigham Young University From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Ron Van den Branden Sent: Wednesday, May 25, 2022 10:05 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace Hi Corey, Many thanks for your helpful reply! In our current data, these structured links are indeed connected to a field that maps to in ArchivesSpace, so that?s indeed the destination we had in mind. Your example for embedding ArchivesSpace-internal links via the ArchivesSpace ID for a @href attribute was really helpful and finally made me get it working in the test instance, great! That?s a useful mechanism, though I fully agree the manual input process is brittle, even with the (limited) ?mixed content? completion help. In order to make the most semantic sense, as you exemplified with the example, our colleagues and volunteers describing the archives would have to be knowledgeable of XML syntax rules, and the suitable EAD structures for the information they?d want to enter. Yet, even if a new structured resource-to-resource link field would be too far off the implementation horizon, perhaps a general improvement for adding such internal cross-links in text fields in a more guided way could be of interest. I?ll think about it! Finally, your data audit remark sounds intriguing and -considering the amount of data cleanup this data migration project has confronted us with- a vital part of best practice. Would you mind elaborating on that, or pointing me to any available documentation? Best, Ron Van: archivesspace_users_group-bounces at lyralists.lyrasis.org > Namens Corey Schmidt Verzonden: woensdag 25 mei 2022 14:57 Aan: Archivesspace Users Group > Onderwerp: Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace Hey Ron, Glad to see you reaching out! I?m not sure if others have emailed you regarding this, so I?ll put in my 2 cents worth. * From what I understand, there is no mechanism within ArchivesSpace that provides a structured ?Agents/Related Accessions? type link from one resource to another, nor one archival object to another. * Have you considered using the ?Related Materials? note ()? The advantage with this is the note is made specifically for related materials either within the repository or without and you don?t need a full URL, just the ArchivesSpace ID if you?re using the PUI, like so: Related Collection title. The problem with this is you have to enter the info by hand, which is error prone (we?ve scheduled a yearly ?data audit? to help us catch errors like these). * I don?t know of any institution that has developed a plugin, nor is this on the roadmap I think. Nevertheless, you can submit a JIRA ticket for this feature (how to do that linked here) ? explaining how you want it to work with as much detail as possible. The Development Priority Team will then determine if the ArchivesSpace development team or community can/should prioritize it in future releases. The more attention a ticket gets (comments, clarifications, etc.) the more likely it is to be implemented (great YouTube video here about the process). I hope this is helpful, but if you?d like to talk more about it, feel free to email me: Corey.Schmidt at uga.edu. To everyone on the listserv, please feel free to correct any of this info if it?s incorrect/misleading. Sincerely, Corey Corey Schmidt Special Collections Libraries | Project Management Librarian/Archivist 300 S Hull St | Athens, GA 30605 Corey.Schmidt at uga.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org > On Behalf Of Ron Van den Branden Sent: Wednesday, May 18, 2022 3:45 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace [EXTERNAL SENDER - PROCEED CAUTIOUSLY] Hi all, This is my first message to this group; apologies if this has been addressed before (tried my best researching the list archive at https://www.mail-archive.com/archivesspace_users_group at lyralists.lyrasis.org/). At my institution, we?re preparing a migration of data from a previous archival description system to ArchivesSpace. The previous system allowed for structured links between archival descriptions within the system. For example, resource A could point to resource B within the same system by means of a system identifier, which the system would resolve to a full link in the PUI. This is functioning in a similar way as Agents Links or Related Accessions sections in ArchivesSpace; only with a different record type (resources / archival objects instead of agents, resp. accessions). Please correct me if I?m wrong, but I don?t see an immediate equivalent mechanism in ArchivesSpace. This raises some questions: * Am I overlooking the obvious, and does ArchivesSpace provide a structured mechanism to point from a Resource / Archival Object to another Resource / Archival Object? * If not, I do see the External Documents section as a close fit, with the semantic drawback that these linked resources are not really external but rather internal. More substantially, though, External Documents only allows for a literal URL, which is less elegant, more error-prone, and less sustainable than the dynamically generated links provided via Agent Links or Related Accessions. * If not, is this something that?s on a development roadmap, or have others implemented this as a plug-in? Many thanks for your thoughts! Best, Ron Ron Van den Branden | functioneel analist - applicatiebeheerder Letterenhuis Stad Antwerpen | Talentontwikkeling en Vrijetijdsbeleving | Musea en Erfgoed Minderbroedersstraat 22, 2000 Antwerpen ? Grote Markt 1, 2000 Antwerpen gsm +32 0485 02 80 50 | tel. +32 3 222 93 30 letterenhuis.be | instagram | facebook Proclaimer Vergissen is menselijk. Dus als deze e-mail, samen met eventuele bijlagen, niet voor u bestemd is, vragen we u vriendelijk om dat te melden aan de afzender. Deze e-mail en de bijlagen zijn namelijk offici?le documenten van de stad Antwerpen. Ze kunnen vertrouwelijke of persoonlijke informatie bevatten. Als stad nemen we privacy heel serieus en willen we als een goede huisvader waken over de vertrouwelijkheid van documenten. Als u dit bericht per vergissing hebt ontvangen of ergens hebt gevonden, wees dan zo eerlijk om het meteen te verwijderen en het niet verder te verspreiden of te kopi?ren. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Corey.Schmidt at uga.edu Wed May 25 11:28:57 2022 From: Corey.Schmidt at uga.edu (Corey Schmidt) Date: Wed, 25 May 2022 15:28:57 +0000 Subject: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace In-Reply-To: References: <1bc9268864734e4b92ba20584ef975ff@antwerpen.be> Message-ID: Ron, My pleasure! I?m glad the example helped get you going for your test instance. Thanks for the follow-up Cory. It?s a shame that functionality was rejected, but understandable. As you pointed out Ron, it?s still a brittle process, not helped by the fact that it?s sometimes difficult to ask colleagues/volunteers to familiarize themselves with XML syntax and EAD tags and attributes. If after considering improvements for internal cross-links you want to post a ticket and need/want help, just let me know! I?m happy to make suggestions and give a +1. Sure, after migrating to ArchivesSpace, we compiled a bunch of tests we did for checking our data. I wrote a python script to do the tests, create a spreadsheet with the results, email those results to our users, and I worked with our sysadmin to make a cron job to run the script once a year. It checks: ? controlled vocabularies for non-permitted terms ? resources/items with Component Unique IDs (we don?t use them) ? containers with no barcodes or indicators ? archival objects with multiple containers or digital objects ? archival objects falsely labeled as ?collection? level ? EAD-IDs (we make these in our EAD.xml exporter) ? duplicate subjects and agents ? archival objects on the same level but have different labels (i.e. a file and series on the same level together) ? XML errors ? URL errors With a little programming knowledge, you could modify this script or make one yourself. There?s also a number YouTube videos on data cleanup in ArchivesSpace: ArchivesSpace Data Cleanup Webinar: Tips, Tricks, and Tools, How to Make Technology Work for You In an ArchivesSpace Data Cleanup Project, Someday is Here! ArchivesSpace Projects for Working from Home. Corey From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Cory Nimer Sent: Wednesday, May 25, 2022 11:15 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace [EXTERNAL SENDER - PROCEED CAUTIOUSLY] Ron, I would agree that it would be preferable to have a more EAD3-friendly configuration for related materials notes, at least in order to reduce/remove the need for mixed content within these notes. I don't know if there is widespread interest in moving implementing something more like the Agents module's Sources subrecord or the Metadata Rights Declarations with their fields for recording a descriptive note and a URL separately. It looks like the project has already rejected the idea of being allowing linking between different records within the database, though (ANW-763; https://archivesspace.atlassian.net/browse/ANW-763). Best, Cory Nimer University Archivist Brigham Young University From: archivesspace_users_group-bounces at lyralists.lyrasis.org > On Behalf Of Ron Van den Branden Sent: Wednesday, May 25, 2022 10:05 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace Hi Corey, Many thanks for your helpful reply! In our current data, these structured links are indeed connected to a field that maps to in ArchivesSpace, so that?s indeed the destination we had in mind. Your example for embedding ArchivesSpace-internal links via the ArchivesSpace ID for a @href attribute was really helpful and finally made me get it working in the test instance, great! That?s a useful mechanism, though I fully agree the manual input process is brittle, even with the (limited) ?mixed content? completion help. In order to make the most semantic sense, as you exemplified with the example, our colleagues and volunteers describing the archives would have to be knowledgeable of XML syntax rules, and the suitable EAD structures for the information they?d want to enter. Yet, even if a new structured resource-to-resource link field would be too far off the implementation horizon, perhaps a general improvement for adding such internal cross-links in text fields in a more guided way could be of interest. I?ll think about it! Finally, your data audit remark sounds intriguing and -considering the amount of data cleanup this data migration project has confronted us with- a vital part of best practice. Would you mind elaborating on that, or pointing me to any available documentation? Best, Ron Van: archivesspace_users_group-bounces at lyralists.lyrasis.org > Namens Corey Schmidt Verzonden: woensdag 25 mei 2022 14:57 Aan: Archivesspace Users Group > Onderwerp: Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace Hey Ron, Glad to see you reaching out! I?m not sure if others have emailed you regarding this, so I?ll put in my 2 cents worth. * From what I understand, there is no mechanism within ArchivesSpace that provides a structured ?Agents/Related Accessions? type link from one resource to another, nor one archival object to another. * Have you considered using the ?Related Materials? note ()? The advantage with this is the note is made specifically for related materials either within the repository or without and you don?t need a full URL, just the ArchivesSpace ID if you?re using the PUI, like so: Related Collection title. The problem with this is you have to enter the info by hand, which is error prone (we?ve scheduled a yearly ?data audit? to help us catch errors like these). * I don?t know of any institution that has developed a plugin, nor is this on the roadmap I think. Nevertheless, you can submit a JIRA ticket for this feature (how to do that linked here) ? explaining how you want it to work with as much detail as possible. The Development Priority Team will then determine if the ArchivesSpace development team or community can/should prioritize it in future releases. The more attention a ticket gets (comments, clarifications, etc.) the more likely it is to be implemented (great YouTube video here about the process). I hope this is helpful, but if you?d like to talk more about it, feel free to email me: Corey.Schmidt at uga.edu. To everyone on the listserv, please feel free to correct any of this info if it?s incorrect/misleading. Sincerely, Corey Corey Schmidt Special Collections Libraries | Project Management Librarian/Archivist 300 S Hull St | Athens, GA 30605 Corey.Schmidt at uga.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org > On Behalf Of Ron Van den Branden Sent: Wednesday, May 18, 2022 3:45 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace [EXTERNAL SENDER - PROCEED CAUTIOUSLY] Hi all, This is my first message to this group; apologies if this has been addressed before (tried my best researching the list archive at https://www.mail-archive.com/archivesspace_users_group at lyralists.lyrasis.org/). At my institution, we?re preparing a migration of data from a previous archival description system to ArchivesSpace. The previous system allowed for structured links between archival descriptions within the system. For example, resource A could point to resource B within the same system by means of a system identifier, which the system would resolve to a full link in the PUI. This is functioning in a similar way as Agents Links or Related Accessions sections in ArchivesSpace; only with a different record type (resources / archival objects instead of agents, resp. accessions). Please correct me if I?m wrong, but I don?t see an immediate equivalent mechanism in ArchivesSpace. This raises some questions: * Am I overlooking the obvious, and does ArchivesSpace provide a structured mechanism to point from a Resource / Archival Object to another Resource / Archival Object? * If not, I do see the External Documents section as a close fit, with the semantic drawback that these linked resources are not really external but rather internal. More substantially, though, External Documents only allows for a literal URL, which is less elegant, more error-prone, and less sustainable than the dynamically generated links provided via Agent Links or Related Accessions. * If not, is this something that?s on a development roadmap, or have others implemented this as a plug-in? Many thanks for your thoughts! Best, Ron Ron Van den Branden | functioneel analist - applicatiebeheerder Letterenhuis Stad Antwerpen | Talentontwikkeling en Vrijetijdsbeleving | Musea en Erfgoed Minderbroedersstraat 22, 2000 Antwerpen ? Grote Markt 1, 2000 Antwerpen gsm +32 0485 02 80 50 | tel. +32 3 222 93 30 letterenhuis.be | instagram | facebook Proclaimer Vergissen is menselijk. Dus als deze e-mail, samen met eventuele bijlagen, niet voor u bestemd is, vragen we u vriendelijk om dat te melden aan de afzender. Deze e-mail en de bijlagen zijn namelijk offici?le documenten van de stad Antwerpen. Ze kunnen vertrouwelijke of persoonlijke informatie bevatten. Als stad nemen we privacy heel serieus en willen we als een goede huisvader waken over de vertrouwelijkheid van documenten. Als u dit bericht per vergissing hebt ontvangen of ergens hebt gevonden, wees dan zo eerlijk om het meteen te verwijderen en het niet verder te verspreiden of te kopi?ren. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at virginia.edu Wed May 25 11:41:56 2022 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Wed, 25 May 2022 15:41:56 +0000 Subject: [Archivesspace_Users_Group] Missing gems after upgrade to 3.2.0? In-Reply-To: References: Message-ID: <1ACF375F-2DD1-47A7-9E0E-0670468E659B@virginia.edu> I reported an issue with gem extensions in 3.2.0 in an earlier post. I had thought it may have had something to do with my testing on MacOS, as it appeared to get fixed by building my own release zip file on Mac, rather than using the release zip downloaded from GitHub, but I?m beginning to think that?s not the whole story. ? Steve M. > On May 25, 2022, at 8:22 AM, Jon Bandstra wrote: > > Hello, > > I recently upgraded from 2.8.1 to 3.2.0. > > In the log file, I now see messages about two gems not loading at startup ? > > Ignoring llhttp-ffi-0.3.1 because its extensions are not built. Try: gem pristine llhttp-ffi --version 0.3.1 > Ignoring unf_ext-0.0.8 because its extensions are not built. Try: gem pristine unf_ext --version 0.0.8 > > Any thoughts on what might be causing this? Did I miss a step in the upgrade process? > > This instance of ArchivesSpace is running on Ubuntu 18.04 with Solr 8.11.1 and Java 8 (OpenJDK). > > I don't know if it's related to the gems issue, but I'm also getting errors like the following ? > > INFO -- : Started GET "/check_session?uri=%2Frepositories%2F2%2Fresources%2F1417" > FATAL -- : ActionController::RoutingError (No route matches [GET] "/check_session") > FATAL -- : actionpack (5.2.5) lib/action_dispatch/middleware/debug_exceptions.rb:65:in `call' > > And for what it's worth, the backup.sh script is failing after the upgrade to 3.2.0. This might be the same issue that Scott Renton reported on the listserv yesterday. The script worked fine with version 2.8.1. > > (See attached files for more complete log listings.) > > Thanks, > Jon Bandstra > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3342 bytes Desc: not available URL: From mang.sun at rice.edu Wed May 25 12:54:19 2022 From: mang.sun at rice.edu (mang.sun at rice.edu) Date: Wed, 25 May 2022 11:54:19 -0500 Subject: [Archivesspace_Users_Group] error saving an Archival Object In-Reply-To: References: Message-ID: This issue is now also happening to our v2.7.1 aspace. Similar error message. But the way using the directive of #AppConfig[:resequence_on_startup] = True seemingly doesn't work. Is the directive still a valid one with v2.7.1? [image: image.png] Thank you. Mang Sun Rice U. On Thu, Feb 2, 2017 at 3:37 PM Noah Huffman wrote: > Robin, > > > > Here?s an unresolved JIRA issue describing this problem: > https://archivesspace.atlassian.net/browse/AR-1326 > > > > It tends to happen when you try to edit an archival object record that has > been transferred from another resource record. > > > > As far as I know, there are a couple of fixes for this: > > 1. Resequence your entire ASpace database. To do this, shut down > ASpace, modify config.rb (#AppConfig[:resequence_on_startup] = True), and > restart. Beware that resequencing a large database will take a long time, > but this should prevent the same error from occurring in other records. > > 2. Install this plugin that allows you to resequence only the > resource record where the error occurs: > https://github.com/archivesspace/resync > > > > -Noah > > > > *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto: > archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Wendler, > Robin King > *Sent:* Thursday, February 02, 2017 3:46 PM > *To:* archivesspace_users_group at lyralists.lyrasis.org > *Subject:* [Archivesspace_Users_Group] error saving an Archival Object > > > > Hello, ASpacers, > > When saving the archival object below, changed only by adding a > single space preceding ?Tours? in the title, we get the following error > message: > > > > [image: cid:image001.png at 01D27D70.E6CB7BB0] > > > > The same error usually occurs if we try to change other archival object > records attached to this resource record, but not always. One I was able to > change, but received the error when I tried to change it back. Another I > could change and change back without encountering the error. The resource > record itself can be changed. Any ideas about why this is happening and > what we can do to clear it up? > > > > Thanks for your thoughts, > > Robin > > > > Robin Wendler > > Library Technology Services > > Harvard University > > 90 Mt. Auburn St. > > Cambridge, MA 02138 > > 617-495-3724 > > r_wendler at harvard.edu > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 116837 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 18137 bytes Desc: not available URL: From brian.hoffman at lyrasis.org Thu May 26 07:20:16 2022 From: brian.hoffman at lyrasis.org (Brian Hoffman) Date: Thu, 26 May 2022 11:20:16 +0000 Subject: [Archivesspace_Users_Group] Issue with gems extensions ( sassc, bindex, ... ) on Mac with 3.2.0 In-Reply-To: References: Message-ID: Hi Steve, This is a known unresolved issue ? ArchivesSpace is built on Jruby, the premise being that it can sit entirely on the JVM and thus be portable as any Java app. But over the years various gems with extensions have crept into the application and broken that model ? in the case of the sassc gem, we have actually been copying over the gem that was built in the 2.8.1 release to all subsequent releases because for some reason that one seems to work on most systems. I think the proper solution would be to eliminate gems that depend on c extensions, and figuring out a way to do that is one of the objectives of our next Rails environment upgrade. Suggestions from those who are smarter than me on how to resolve this are most welcome. Brian From: archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of Majewski, Steven Dennis (sdm7g) Date: Monday, May 23, 2022 at 2:37 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Issue with gems extensions ( sassc, bindex, ... ) on Mac with 3.2.0 I usually test out migrations and local plugins on my Mac laptop first before installing on a test server. I ran into a couple of issues with 3.2.0 release. Using the release downloaded from https://github.com/archivesspace/archivesspace/releases/tag/v3.2.0 Backend and frontend appeared to work and communicate with the separately installed Solr instance however the PUI gave system errors from the bundler relating to sassc-2.4.0 Looking at the log file, there were a number of messages about that and other gems: Ignoring bindex-0.8.1 because its extensions are not built. Try: gem pristine bindex --version 0.8.1 Ignoring llhttp-ffi-0.3.1 because its extensions are not built. Try: gem pristine llhttp-ffi --version 0.3.1 Ignoring sassc-2.4.0 because its extensions are not built. Try: gem pristine sassc --version 2.4.0 I attempted to run ?gem pristine? after setting GEM_HOME, which seemed to do something, but didn?t fix the issue. ( Doing these sorts of fixes are a bit confusing due to the way that JRuby is packaged in ArchivesSpace, so I may not have been doing it correctly. ) I finally tried building my own distribution from GitHub tag v3.2.0, and unpacking that zip file and running it appears to work ( so far! Still indexing PUI ) So I?m guessing that there is something in these gem extensions that is architecture or java version specific and the distributions on GitHub are not universal. We may require a fixup script that runs the bundler similar to the way it?s done in initialize-plugins script. Has anyone else run into this issue ? ? Steve Majewski -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ivan.Allhiser at avila.edu Thu May 26 09:33:21 2022 From: Ivan.Allhiser at avila.edu (Allhiser, Ivan) Date: Thu, 26 May 2022 13:33:21 +0000 Subject: [Archivesspace_Users_Group] Unable to launch ArchivesSpaceService Message-ID: Hello all, Our previous system administrator set up ArchivesSpace 2.8.1 and we received a ticket that it needed to be re-indexed. None of us were even aware of what this server did. Before I could access it, the server needed to be rebooted. Once it came back up, I was unable to start the ArchivesSpaceServe. I am shown this error whenever I try (even with Powershell) "Windows could not start the ArchivesSpaceService on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 5." I've checked the System Event Long and I don't even see any events that show an attempt to start the service. We've checked the logs and honestly, I'm lost trying to swim through all this data. I don't see anything standing out that says there's an error. Has anyone encountered this before and know of a fix? Thank you for your time, Ivan Allhiser System Administrator Information Technology Services [Dining Services | Avila University] -------------- next part -------------- An HTML attachment was scrubbed... URL: From kate_bowers at harvard.edu Thu May 26 12:20:59 2022 From: kate_bowers at harvard.edu (Bowers, Kate A.) Date: Thu, 26 May 2022 16:20:59 +0000 Subject: [Archivesspace_Users_Group] Detailed data map for LCNAF plug-in? Message-ID: Does anyone know where I can find a list of exactly which fields from LCNAF authority records go into which fields in AS agent records if one implements the LCNAF plug-in? I've search git-hub and the AS wiki'd and AS help and I have not found details on exactly what the import does. Thanks! Kate -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ron.VandenBranden at antwerpen.be Thu May 26 12:23:30 2022 From: Ron.VandenBranden at antwerpen.be (Ron Van den Branden) Date: Thu, 26 May 2022 16:23:30 +0000 Subject: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace In-Reply-To: References: <1bc9268864734e4b92ba20584ef975ff@antwerpen.be> Message-ID: <9e3a3c869bf9423fa8bbfcb8df94d67f@antwerpen.be> Whoa, thanks for sharing both your code and those pointers, Corey! That?s study stuff for when the dust?ll have settle a bit. I?ll present the current option for internal linking in ArchivesSpace to our colleagues and IT partner; if this leads to structured suggestions for improvement, it would be great if that could result in a Jira ticket. Many thanks in advance for your support. Best, Ron Van: archivesspace_users_group-bounces at lyralists.lyrasis.org Namens Corey Schmidt Verzonden: woensdag 25 mei 2022 17:29 Aan: Archivesspace Users Group Onderwerp: Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace Ron, My pleasure! I?m glad the example helped get you going for your test instance. Thanks for the follow-up Cory. It?s a shame that functionality was rejected, but understandable. As you pointed out Ron, it?s still a brittle process, not helped by the fact that it?s sometimes difficult to ask colleagues/volunteers to familiarize themselves with XML syntax and EAD tags and attributes. If after considering improvements for internal cross-links you want to post a ticket and need/want help, just let me know! I?m happy to make suggestions and give a +1. Sure, after migrating to ArchivesSpace, we compiled a bunch of tests we did for checking our data. I wrote a python script to do the tests, create a spreadsheet with the results, email those results to our users, and I worked with our sysadmin to make a cron job to run the script once a year. It checks: * controlled vocabularies for non-permitted terms * resources/items with Component Unique IDs (we don?t use them) * containers with no barcodes or indicators * archival objects with multiple containers or digital objects * archival objects falsely labeled as ?collection? level * EAD-IDs (we make these in our EAD.xml exporter) * duplicate subjects and agents * archival objects on the same level but have different labels (i.e. a file and series on the same level together) * XML errors * URL errors With a little programming knowledge, you could modify this script or make one yourself. There?s also a number YouTube videos on data cleanup in ArchivesSpace: ArchivesSpace Data Cleanup Webinar: Tips, Tricks, and Tools, How to Make Technology Work for You In an ArchivesSpace Data Cleanup Project, Someday is Here! ArchivesSpace Projects for Working from Home. Corey From: archivesspace_users_group-bounces at lyralists.lyrasis.org > On Behalf Of Cory Nimer Sent: Wednesday, May 25, 2022 11:15 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace [EXTERNAL SENDER - PROCEED CAUTIOUSLY] Ron, I would agree that it would be preferable to have a more EAD3-friendly configuration for related materials notes, at least in order to reduce/remove the need for mixed content within these notes. I don't know if there is widespread interest in moving implementing something more like the Agents module's Sources subrecord or the Metadata Rights Declarations with their fields for recording a descriptive note and a URL separately. It looks like the project has already rejected the idea of being allowing linking between different records within the database, though (ANW-763; https://archivesspace.atlassian.net/browse/ANW-763). Best, Cory Nimer University Archivist Brigham Young University From: archivesspace_users_group-bounces at lyralists.lyrasis.org > On Behalf Of Ron Van den Branden Sent: Wednesday, May 25, 2022 10:05 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace Hi Corey, Many thanks for your helpful reply! In our current data, these structured links are indeed connected to a field that maps to in ArchivesSpace, so that?s indeed the destination we had in mind. Your example for embedding ArchivesSpace-internal links via the ArchivesSpace ID for a @href attribute was really helpful and finally made me get it working in the test instance, great! That?s a useful mechanism, though I fully agree the manual input process is brittle, even with the (limited) ?mixed content? completion help. In order to make the most semantic sense, as you exemplified with the example, our colleagues and volunteers describing the archives would have to be knowledgeable of XML syntax rules, and the suitable EAD structures for the information they?d want to enter. Yet, even if a new structured resource-to-resource link field would be too far off the implementation horizon, perhaps a general improvement for adding such internal cross-links in text fields in a more guided way could be of interest. I?ll think about it! Finally, your data audit remark sounds intriguing and -considering the amount of data cleanup this data migration project has confronted us with- a vital part of best practice. Would you mind elaborating on that, or pointing me to any available documentation? Best, Ron Van: archivesspace_users_group-bounces at lyralists.lyrasis.org > Namens Corey Schmidt Verzonden: woensdag 25 mei 2022 14:57 Aan: Archivesspace Users Group > Onderwerp: Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace Hey Ron, Glad to see you reaching out! I?m not sure if others have emailed you regarding this, so I?ll put in my 2 cents worth. * From what I understand, there is no mechanism within ArchivesSpace that provides a structured ?Agents/Related Accessions? type link from one resource to another, nor one archival object to another. * Have you considered using the ?Related Materials? note ()? The advantage with this is the note is made specifically for related materials either within the repository or without and you don?t need a full URL, just the ArchivesSpace ID if you?re using the PUI, like so: Related Collection title. The problem with this is you have to enter the info by hand, which is error prone (we?ve scheduled a yearly ?data audit? to help us catch errors like these). * I don?t know of any institution that has developed a plugin, nor is this on the roadmap I think. Nevertheless, you can submit a JIRA ticket for this feature (how to do that linked here) ? explaining how you want it to work with as much detail as possible. The Development Priority Team will then determine if the ArchivesSpace development team or community can/should prioritize it in future releases. The more attention a ticket gets (comments, clarifications, etc.) the more likely it is to be implemented (great YouTube video here about the process). I hope this is helpful, but if you?d like to talk more about it, feel free to email me: Corey.Schmidt at uga.edu. To everyone on the listserv, please feel free to correct any of this info if it?s incorrect/misleading. Sincerely, Corey Corey Schmidt Special Collections Libraries | Project Management Librarian/Archivist 300 S Hull St | Athens, GA 30605 Corey.Schmidt at uga.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org > On Behalf Of Ron Van den Branden Sent: Wednesday, May 18, 2022 3:45 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace [EXTERNAL SENDER - PROCEED CAUTIOUSLY] Hi all, This is my first message to this group; apologies if this has been addressed before (tried my best researching the list archive at https://www.mail-archive.com/archivesspace_users_group at lyralists.lyrasis.org/). At my institution, we?re preparing a migration of data from a previous archival description system to ArchivesSpace. The previous system allowed for structured links between archival descriptions within the system. For example, resource A could point to resource B within the same system by means of a system identifier, which the system would resolve to a full link in the PUI. This is functioning in a similar way as Agents Links or Related Accessions sections in ArchivesSpace; only with a different record type (resources / archival objects instead of agents, resp. accessions). Please correct me if I?m wrong, but I don?t see an immediate equivalent mechanism in ArchivesSpace. This raises some questions: * Am I overlooking the obvious, and does ArchivesSpace provide a structured mechanism to point from a Resource / Archival Object to another Resource / Archival Object? * If not, I do see the External Documents section as a close fit, with the semantic drawback that these linked resources are not really external but rather internal. More substantially, though, External Documents only allows for a literal URL, which is less elegant, more error-prone, and less sustainable than the dynamically generated links provided via Agent Links or Related Accessions. * If not, is this something that?s on a development roadmap, or have others implemented this as a plug-in? Many thanks for your thoughts! Best, Ron Ron Van den Branden | functioneel analist - applicatiebeheerder Letterenhuis Stad Antwerpen | Talentontwikkeling en Vrijetijdsbeleving | Musea en Erfgoed Minderbroedersstraat 22, 2000 Antwerpen ? Grote Markt 1, 2000 Antwerpen gsm +32 0485 02 80 50 | tel. +32 3 222 93 30 letterenhuis.be | instagram | facebook Proclaimer Vergissen is menselijk. Dus als deze e-mail, samen met eventuele bijlagen, niet voor u bestemd is, vragen we u vriendelijk om dat te melden aan de afzender. Deze e-mail en de bijlagen zijn namelijk offici?le documenten van de stad Antwerpen. Ze kunnen vertrouwelijke of persoonlijke informatie bevatten. Als stad nemen we privacy heel serieus en willen we als een goede huisvader waken over de vertrouwelijkheid van documenten. Als u dit bericht per vergissing hebt ontvangen of ergens hebt gevonden, wees dan zo eerlijk om het meteen te verwijderen en het niet verder te verspreiden of te kopi?ren. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jessica.Crouch at lyrasis.org Thu May 26 12:26:29 2022 From: Jessica.Crouch at lyrasis.org (Jessica Crouch) Date: Thu, 26 May 2022 16:26:29 +0000 Subject: [Archivesspace_Users_Group] Take a Break with ArchivesSpace goes on hiatus after May 27 In-Reply-To: References: <51F22031-BCF5-4F81-9E91-B2025697CEA9@lyrasis.org> Message-ID: ArchivesSpace users, Join us tomorrow for our final Break with ArchivesSpace before these breaks go on hiatus. We may revive the breaks in some form in the future, but until then we look forward to seeing you tomorrow. Thanks to everyone who has joined us at our standing Friday break calls. It?s been great reconnecting with so many familiar faces and getting to know so many new faces as well. We will host the final Break with ArchivesSpace this Friday (May 27th) via zoom at 12pm ET. There is no agenda or presentation developed for this call. We just want to provide an opportunity to connect, chat and recharge. Use this as a time to get help or talk about ArchivesSpace (or anything else) in an informal setting or just have a beverage with other ArchivesSpace users during this stressful time. Register to join at https://lyrasis.zoom.us/meeting/register/tZcldOGuqjotE9cNSaa6j45issVCKrEQKQYv We seek to provide a welcoming, fun, and safe community experience for everyone. The full text of the code of conduct is available at https://archivesspace.org/archivesspace-code-of-conduct. Please email ArchivesSpaceHome at lyrasis.org with any questions. We hope to see you tomorrow! Jessica Dowd Crouch Community Engagement Coordinator for ArchivesSpace jessica.crouch at lyrasis.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ron.VandenBranden at antwerpen.be Thu May 26 12:27:16 2022 From: Ron.VandenBranden at antwerpen.be (Ron Van den Branden) Date: Thu, 26 May 2022 16:27:16 +0000 Subject: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace In-Reply-To: References: <1bc9268864734e4b92ba20584ef975ff@antwerpen.be> Message-ID: Thanks for that pointer, Cory! I?m probably a tad late at that party to give my support, though it seems like a useful idea (from a user perspective). Best, Ron Van: archivesspace_users_group-bounces at lyralists.lyrasis.org Namens Cory Nimer Verzonden: woensdag 25 mei 2022 17:15 Aan: Archivesspace Users Group Onderwerp: Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace Ron, I would agree that it would be preferable to have a more EAD3-friendly configuration for related materials notes, at least in order to reduce/remove the need for mixed content within these notes. I don't know if there is widespread interest in moving implementing something more like the Agents module's Sources subrecord or the Metadata Rights Declarations with their fields for recording a descriptive note and a URL separately. It looks like the project has already rejected the idea of being allowing linking between different records within the database, though (ANW-763; https://archivesspace.atlassian.net/browse/ANW-763). Best, Cory Nimer University Archivist Brigham Young University From: archivesspace_users_group-bounces at lyralists.lyrasis.org > On Behalf Of Ron Van den Branden Sent: Wednesday, May 25, 2022 10:05 AM To: Archivesspace Users Group > Subject: Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace Hi Corey, Many thanks for your helpful reply! In our current data, these structured links are indeed connected to a field that maps to in ArchivesSpace, so that?s indeed the destination we had in mind. Your example for embedding ArchivesSpace-internal links via the ArchivesSpace ID for a @href attribute was really helpful and finally made me get it working in the test instance, great! That?s a useful mechanism, though I fully agree the manual input process is brittle, even with the (limited) ?mixed content? completion help. In order to make the most semantic sense, as you exemplified with the example, our colleagues and volunteers describing the archives would have to be knowledgeable of XML syntax rules, and the suitable EAD structures for the information they?d want to enter. Yet, even if a new structured resource-to-resource link field would be too far off the implementation horizon, perhaps a general improvement for adding such internal cross-links in text fields in a more guided way could be of interest. I?ll think about it! Finally, your data audit remark sounds intriguing and -considering the amount of data cleanup this data migration project has confronted us with- a vital part of best practice. Would you mind elaborating on that, or pointing me to any available documentation? Best, Ron Van: archivesspace_users_group-bounces at lyralists.lyrasis.org > Namens Corey Schmidt Verzonden: woensdag 25 mei 2022 14:57 Aan: Archivesspace Users Group > Onderwerp: Re: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace Hey Ron, Glad to see you reaching out! I?m not sure if others have emailed you regarding this, so I?ll put in my 2 cents worth. * From what I understand, there is no mechanism within ArchivesSpace that provides a structured ?Agents/Related Accessions? type link from one resource to another, nor one archival object to another. * Have you considered using the ?Related Materials? note ()? The advantage with this is the note is made specifically for related materials either within the repository or without and you don?t need a full URL, just the ArchivesSpace ID if you?re using the PUI, like so: Related Collection title. The problem with this is you have to enter the info by hand, which is error prone (we?ve scheduled a yearly ?data audit? to help us catch errors like these). * I don?t know of any institution that has developed a plugin, nor is this on the roadmap I think. Nevertheless, you can submit a JIRA ticket for this feature (how to do that linked here) ? explaining how you want it to work with as much detail as possible. The Development Priority Team will then determine if the ArchivesSpace development team or community can/should prioritize it in future releases. The more attention a ticket gets (comments, clarifications, etc.) the more likely it is to be implemented (great YouTube video here about the process). I hope this is helpful, but if you?d like to talk more about it, feel free to email me: Corey.Schmidt at uga.edu. To everyone on the listserv, please feel free to correct any of this info if it?s incorrect/misleading. Sincerely, Corey Corey Schmidt Special Collections Libraries | Project Management Librarian/Archivist 300 S Hull St | Athens, GA 30605 Corey.Schmidt at uga.edu From: archivesspace_users_group-bounces at lyralists.lyrasis.org > On Behalf Of Ron Van den Branden Sent: Wednesday, May 18, 2022 3:45 PM To: archivesspace_users_group at lyralists.lyrasis.org Subject: [Archivesspace_Users_Group] linking to related Resources / Archival Objects in ArchivesSpace [EXTERNAL SENDER - PROCEED CAUTIOUSLY] Hi all, This is my first message to this group; apologies if this has been addressed before (tried my best researching the list archive at https://www.mail-archive.com/archivesspace_users_group at lyralists.lyrasis.org/). At my institution, we?re preparing a migration of data from a previous archival description system to ArchivesSpace. The previous system allowed for structured links between archival descriptions within the system. For example, resource A could point to resource B within the same system by means of a system identifier, which the system would resolve to a full link in the PUI. This is functioning in a similar way as Agents Links or Related Accessions sections in ArchivesSpace; only with a different record type (resources / archival objects instead of agents, resp. accessions). Please correct me if I?m wrong, but I don?t see an immediate equivalent mechanism in ArchivesSpace. This raises some questions: * Am I overlooking the obvious, and does ArchivesSpace provide a structured mechanism to point from a Resource / Archival Object to another Resource / Archival Object? * If not, I do see the External Documents section as a close fit, with the semantic drawback that these linked resources are not really external but rather internal. More substantially, though, External Documents only allows for a literal URL, which is less elegant, more error-prone, and less sustainable than the dynamically generated links provided via Agent Links or Related Accessions. * If not, is this something that?s on a development roadmap, or have others implemented this as a plug-in? Many thanks for your thoughts! Best, Ron Ron Van den Branden | functioneel analist - applicatiebeheerder Letterenhuis Stad Antwerpen | Talentontwikkeling en Vrijetijdsbeleving | Musea en Erfgoed Minderbroedersstraat 22, 2000 Antwerpen ? Grote Markt 1, 2000 Antwerpen gsm +32 0485 02 80 50 | tel. +32 3 222 93 30 letterenhuis.be | instagram | facebook Proclaimer Vergissen is menselijk. Dus als deze e-mail, samen met eventuele bijlagen, niet voor u bestemd is, vragen we u vriendelijk om dat te melden aan de afzender. Deze e-mail en de bijlagen zijn namelijk offici?le documenten van de stad Antwerpen. Ze kunnen vertrouwelijke of persoonlijke informatie bevatten. Als stad nemen we privacy heel serieus en willen we als een goede huisvader waken over de vertrouwelijkheid van documenten. Als u dit bericht per vergissing hebt ontvangen of ergens hebt gevonden, wees dan zo eerlijk om het meteen te verwijderen en het niet verder te verspreiden of te kopi?ren. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brijmcla at iu.edu Thu May 26 12:30:57 2022 From: brijmcla at iu.edu (McLaughlin, Brianna Jean) Date: Thu, 26 May 2022 16:30:57 +0000 Subject: [Archivesspace_Users_Group] Customizing the accessions template Message-ID: Hi everyone, We are starting to look into the Accessions module. The Accessions template looks pretty simple compared to the Harvard spreadsheet template we're using for importing components. Is it still possible to customize the spreadsheet without preventing a successful import? For example, could we add Agent fields by copy and pasting and adding a "_2"? Could we add more Event fields by following the same structure (ie accessions_deaccession_date). Generally, I'd love to hear any experimentation with customizing the Accessions template and what limits you've encountered. We're on AS version 2.7.1, likely to be upgrading soon to 3.? Thanks in advance! Bri McLaughlin, she/her/hers Visiting Metadata Services Librarian Indiana University 812-856-3321 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdm7g at virginia.edu Thu May 26 15:48:47 2022 From: sdm7g at virginia.edu (Majewski, Steven Dennis (sdm7g)) Date: Thu, 26 May 2022 19:48:47 +0000 Subject: [Archivesspace_Users_Group] Detailed data map for LCNAF plug-in? In-Reply-To: References: Message-ID: <7ACAA808-D990-495D-A68B-DC90FB330601@virginia.edu> I haven?t looked at the code since before 3.0, and I can see there have been a bunch of changes since, but although the code has changed, it looks like the basic structure stays roughly the same. Start at the LCNAF plugin controller: https://github.com/archivesspace/archivesspace/blob/master/plugins/lcnaf/frontend/controllers/lcnaf_controller.rb And you will see that it sets up a batch converter job, depending on whether it?s importing subjects or agents: # agents are processed by MarcXMLAuthAgentConverter introduced in ANW-429 # subjects are processed by MarcXMLBibConverter as before ANW-429 Batch jobs like converters and exporters get dispatched to the backend service, so look for those in: https://github.com/archivesspace/archivesspace/tree/master/backend/app/converters Where you won?t find any answers because all of the work and mappings for these converters is actually in the base maps in the converters/lib/ directory, where you can see how MARC XML fields are mapped into ArchivesSpace agent or subject JSON schema: https://github.com/archivesspace/archivesspace/blob/master/backend/app/converters/lib/marcxml_auth_agent_base_map.rb https://github.com/archivesspace/archivesspace/blob/master/backend/app/converters/lib/marcxml_bib_base_map.rb Hope that helps as a start. I still find it rough going from there, but that?s mainly because I don?t know MARC that well. Somewhere, there was a document outlining mappings for MARC,EAD,etc. but that prepared long ago as developer specifications ? last I looked, those documents weren?t being updated to track changes in the code, so I don?t know how reliable they are. https://archivesspace.atlassian.net/browse/ANW-429 references in the code above might be a better source. ? Steve M. > On May 26, 2022, at 12:20 PM, Bowers, Kate A. wrote: > > Does anyone know where I can find a list of exactly which fields from LCNAF authority records go into which fields in AS agent records if one implements the LCNAF plug-in? > > I?ve search git-hub and the AS wiki?d and AS help and I have not found details on exactly what the import does. > > Thanks! > > Kate > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3342 bytes Desc: not available URL: From ahaywood at cca.qc.ca Thu May 26 16:36:57 2022 From: ahaywood at cca.qc.ca (Anna Haywood) Date: Thu, 26 May 2022 20:36:57 +0000 Subject: [Archivesspace_Users_Group] Items not showing up in search results filter In-Reply-To: <1354732b-788b-6cb8-5f17-e84c29dad4d2@bodleian.ox.ac.uk> References: <1354732b-788b-6cb8-5f17-e84c29dad4d2@bodleian.ox.ac.uk> Message-ID: Hello Andrew, Thanks so much for your answer. Yes, I am in the right repository and your technique of searching * brought up the items I was looking for. However, for some collections, when I search their unique ID, then filter by "archival object," I can see the item filter. But for others, the items don't come up. I am trying to figure out what the difference between these collections are or the difference between the item records in each fonds but so far I am at a loss. Anna --- Anna Haywood Archiviste Archivist Centre Canadien d'Architecture Canadian Centre for Architecture 1920, rue Baile, Montr?al, Qu?bec, Canada, H3H 2S6 +1 5149397001x1368 cca.qc.ca Twitter | Instagram | Facebook | YouTube Comment pouvons-nous contribuer ? une approche plus collaborative du travail archivistique transnational? How can we contribute to a collaborative approach to transnational archival work? Inscrivez-vous pour recevoir de nos nouvelles. Sign up to get news from us. From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Andrew Morrison Sent: Thursday, May 19, 2022 3:42 AM To: archivesspace_users_group at lyralists.lyrasis.org Subject: Re: [Archivesspace_Users_Group] Items not showing up in search results filter Presumably you are in the correct repository, otherwise your search for a particular collection wouldn't find anything. Is it a problem with just one specific collection, or all of them? If you don't do the search for a unique ID first, and instead just do a simple search for *, then filter to archival objects, do you still not get the "Item" option in Level facet? You could try a soft re-index, to rule out it being a problem with Solr being out-of-sync with MySQL: https://archivesspace.github.io/tech-docs/administration/indexes.html Andrew. On 18/05/2022 21:49, Anna Haywood wrote: Hello everyone, I am having some trouble with my search results filters. When I search by collection unique ID in ArchivesSpace and then filter by "archival object" on the left hand side, I receive an additional set of filters for "Level." Here I can filter by series, subseries, file, etc. However, for some time now, the level "item" does not show up as one of the filters. This is very odd because in my sandbox environment, the items does come up as an option in the Level filter. Both sandbox and production are on version 3.2.0. Does anyone have any theories about why this might be happening? Thanks in advance, Anna --- Anna Haywood Archiviste Archivist Centre Canadien d'Architecture Canadian Centre for Architecture 1920, rue Baile, Montr?al, Qu?bec, Canada, H3H 2S6 +1 5149397001x1368 cca.qc.ca Twitter | Instagram | Facebook | YouTube Comment pouvons-nous contribuer ? une approche plus collaborative du travail archivistique transnational? How can we contribute to a collaborative approach to transnational archival work? Inscrivez-vous pour recevoir de nos nouvelles. Sign up to get news from us. _______________________________________________ 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: From kate_bowers at harvard.edu Thu May 26 21:11:29 2022 From: kate_bowers at harvard.edu (Bowers, Kate A.) Date: Fri, 27 May 2022 01:11:29 +0000 Subject: [Archivesspace_Users_Group] Detailed data map for LCNAF plug-in? In-Reply-To: References: Message-ID: For anyone else who is interested in this, there might not be documentation, but the "map" part of the converter code is here (thanks Steven Majewski): https://github.com/archivesspace/archivesspace/blob/master/backend/app/converters/lib/marcxml_auth_agent_base_map.rb It takes quite a bit of mucking around to see where the data is going, but it is possible to figure it out. Kate From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of Bowers, Kate A. Sent: Thursday, May 26, 2022 12:21 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Detailed data map for LCNAF plug-in? Does anyone know where I can find a list of exactly which fields from LCNAF authority records go into which fields in AS agent records if one implements the LCNAF plug-in? I've search git-hub and the AS wiki'd and AS help and I have not found details on exactly what the import does. Thanks! Kate -------------- next part -------------- An HTML attachment was scrubbed... URL: From julia.tanenbaum at wisc.edu Tue May 31 11:52:33 2022 From: julia.tanenbaum at wisc.edu (Julia Tanenbaum) Date: Tue, 31 May 2022 15:52:33 +0000 Subject: [Archivesspace_Users_Group] Digital Object Module validation error Message-ID: Dear ArchivesSpace users, I am attempting to add a digital object to a record for the same item as an instance. It already has a physical instance. When I try to add it I get a "validation error." Does anyone know what I am doing wrong? Sincerely Julia Tanenbaum she/her Project Processing Archivist University of Wisconsin Madison University Archives **My working day may not be your working day. Please do not feel obliged to reply to this email outside of your normal working hours.** -------------- next part -------------- An HTML attachment was scrubbed... URL: From vaddonizio at atlas-sys.com Tue May 31 13:47:42 2022 From: vaddonizio at atlas-sys.com (Valerie Addonizio) Date: Tue, 31 May 2022 17:47:42 +0000 Subject: [Archivesspace_Users_Group] Customizing the accessions template In-Reply-To: References: Message-ID: Bri, In my experience (which is not truth!) I have never been able to customize the accession importer. The Accession importer's mappings are defined very strictly. You can see them here. Even without knowledge of Ruby, once you scroll down that page to about Line 33 it is easy to see that the mapping is hard-coded. If you open up the accession import spreadsheet you'll see that that code matches the spreadsheet perfectly, ex. 'accession_title' => 'accession.title' where the first value is the column header from the spreadsheet and the second value is what it maps to in an ASpace accession record. In short, if a column name is not there, it does not process the data, so while a new column may not generate an error, I'm 99% sure you will not see the data imported. Now I'm not sure what happens if you re-use the same column name... that would need experimentation, but I'm not optimistic it would work. The history of the importers is varied: they were written by different devs at different times with different methods and different use cases, so it does make sense to me that a behavior you rely on in one importer is not present in another. If all of this is correct so far, the only way this could be changed would be with a plugin or a feature request. -Valerie From: archivesspace_users_group-bounces at lyralists.lyrasis.org On Behalf Of McLaughlin, Brianna Jean Sent: Thursday, May 26, 2022 12:31 PM To: Archivesspace Users Group Subject: [Archivesspace_Users_Group] Customizing the accessions template Hi everyone, We are starting to look into the Accessions module. The Accessions template looks pretty simple compared to the Harvard spreadsheet template we're using for importing components. Is it still possible to customize the spreadsheet without preventing a successful import? For example, could we add Agent fields by copy and pasting and adding a "_2"? Could we add more Event fields by following the same structure (ie accessions_deaccession_date). Generally, I'd love to hear any experimentation with customizing the Accessions template and what limits you've encountered. We're on AS version 2.7.1, likely to be upgrading soon to 3.? Thanks in advance! Bri McLaughlin, she/her/hers Visiting Metadata Services Librarian Indiana University 812-856-3321 -------------- next part -------------- An HTML attachment was scrubbed... URL: From atopek at smith.edu Tue May 31 14:47:12 2022 From: atopek at smith.edu (Althea Topek) Date: Tue, 31 May 2022 14:47:12 -0400 Subject: [Archivesspace_Users_Group] Customizing the accessions template In-Reply-To: References: Message-ID: Hi Bri, At Smith, we have a custom accession template and Python script to import accession records for our rare books. The template is very specific to rare book accessioning (it includes payment information) but we usually import two agent records for each accession (often the author and bookseller). The documentation is available on our GitHub page where you can download the template and script. Let me know if you have any questions! Best, Althea On Thu, May 26, 2022 at 12:31 PM McLaughlin, Brianna Jean wrote: > Hi everyone, > > > > We are starting to look into the Accessions module. The Accessions > template looks pretty simple compared to the Harvard spreadsheet template > we?re using for importing components. Is it still possible to customize the > spreadsheet without preventing a successful import? For example, could we > add Agent fields by copy and pasting and adding a ?_2?? Could we add more > Event fields by following the same structure (ie > accessions_deaccession_date). Generally, I?d love to hear any > experimentation with customizing the Accessions template and what limits > you?ve encountered. > > > > We?re on AS version 2.7.1, likely to be upgrading soon to 3.? > > > > Thanks in advance! > > > > Bri McLaughlin, she/her/hers > > Visiting Metadata Services Librarian > > Indiana University > > 812-856-3321 > > > _______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group at lyralists.lyrasis.org > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > -- Althea Topek Accessioning Archivist Smith College Special Collections atopek at smith.edu 413.585.4484 *she/her/hers* -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jessica.Crouch at lyrasis.org Tue May 31 16:47:08 2022 From: Jessica.Crouch at lyrasis.org (Jessica Crouch) Date: Tue, 31 May 2022 20:47:08 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace Update - May 2022 In-Reply-To: References: Message-ID: [cid:image001.jpg at 01D7E600.7FF2B540] Upcoming Schedule at a Glance: June 15-18: ArchivesSpace Community Engagement Coordinator, Jessica Crouch, attending the Association of Canadian Archivists annual conference June 28: Webinar: Using ArchivesSpace for Reparative Description (registration will be available soon) June 30: ArchivesSpace Member Match applicants notified of matches Development We are gathering up and testing development work in anticipation of the next release. New development is always up on our test server at https://test.archivesspace.org/staff/. We'll have information in June to share about the timing for the release. Membership Renewals ArchivesSpace is developed by and for the community that uses it, and strengthened by services and activities that support our community and connect us to one another. As we close another membership year, we want to give a special thanks to all of the institutions that have joined us as members. ArchivesSpace membership is our primary source of revenue and informs and sustains every aspect of the program, including software development, support and engagement. Thanks for all that your support makes possible. ArchivesSpace membership renewals for 2022-2023 have been sent to all current members. If you have any questions, or if you would like to join as a new member for the 2022-2023 membership year, please let us know at ArchivesSpaceHome at lyrasis.org. We look forward to another year working together. Save the Date: Webinar-Using ArchivesSpace for Reparative Description The next ArchivesSpace webinar will be a 90-minute learning opportunity on June 28th at 2:00pm ET/11:00am PT. Members of the ArchivesSpace user community will highlight reparative description work they are undertaking at their own institutions using ArchivesSpace. A discussion will follow. Registration for this webinar will become available in the coming days. Save The Date: ArchivesSpace 8th Annual Member Forum Our 8th annual ArchivesSpace Member Forum will be a hybrid event held in conjunction with the Society of American Archivists annual meeting. An in-person half-day meeting will be held Wednesday, August 24, 2022 from 9:00am-12:30pm ET in Boston. This event will not be livestreamed, however, we will be offering virtual workshops the week of August 29. As with all ArchivesSpace member forums, this in-person event and the virtual workshops to follow will be available to ArchivesSpace members only and registration information will be made available closer to the event. Webinar Recording Available: Using ArchivesSpace to Create EAC-CPF Records Thank you to everyone who attended our 90-minute webinar on creating valid EAC-CPF records in ArchivesSpace on May 24th. The recording of this webinar is now available at https://archivesspace.org/archives/7243. Membership Update We are excited to welcome our newest members to our community! Our new members since April 30 include: * Dodge City Public Library (Dodge City, KS) * Ferris State University (Big Rapids, MI) * Sisters of the Presentation (San Francisco, CA) * Texas Christian University (Fort Worth, TX) As of May 31, we have 471 General members, 22 Educational Program members, and 3 Registered Service Providers. If you are interested in your institution becoming a member of ArchivesSpace, please email us at ArchivesSpaceHome at lyrasis.org for more information. ________________________________ ArchivesSpace monthly updates provide news about ArchivesSpace community and program activities and are sent to our member listservs, the ArchivesSpace Google Group, and SAA?s Collection Management Section listserv, as well as being posted on the ArchivesSpace website. Please feel free to share this update with people you know who have an interest in ArchivesSpace but may not be on one of these lists. Jessica Dowd Crouch Community Engagement Coordinator for ArchivesSpace jessica.crouch at lyrasis.org [page1image482511520] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 22523 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 29121 bytes Desc: image002.jpg URL: From smquimby at upenn.edu Tue May 31 17:16:27 2022 From: smquimby at upenn.edu (Quimby, Sean) Date: Tue, 31 May 2022 21:16:27 +0000 Subject: [Archivesspace_Users_Group] ArchivesSpace - Message from the Chair Message-ID: Dear ArchivesSpace members, I am writing to report on the ArchivesSpace Governance Board 4th Quarter meeting, a virtual meeting that was conducted on May 18th. We reviewed: * an operations report which highlighted the membership renewal process and starting to participate in more in person events * the continued excellent work of TAC and UAC and working to help clarify the relationship between the councils and the board * preparations for the May 27 Governance/Community session to help clarify the governance board?s role and provide opportunities for members to identify their representatives for further engagement. The session was recorded, so please stay tuned for information on how to go back and watch. The board approved: * A FY22-23 budget focused on supporting the continued growth of the software, paying down technical debt, and fostering community engagement efforts * Training recommendations that move to a communitywide, virtual training model with expanded training offerings * A slate of TAC and UAC appointees. Look for an announcement from the Nominating Committee soon! We recognized the election of Julia Novakovic, Senior Archivist, The Strong, representing the small membership level, to serve as the ArchivesSpace Governance Vice Chair effective July 1, 2021. She will then serve as Chair effective July 1, 2022. This will be my last message to the community as Board Chair as my one-year term ends June 30, 2021. It has been an honor to serve in this role. Annie Benefiel from Grand Valley State University will serve as the next Governance Board Chair effective July 1. Thank you, Annie! As we look ahead to a new membership year, I am excited to see the program continue to grow and foster a strong sense of community among a growing group of users. The Board welcomes your communications and comments on anything mentioned here, or anything else related to ArchivesSpace that is of concern or interest to you. Kind regards, Sean Quimby Past Chair, ArchivesSpace Board of Governance, Associate University Librarian for Special Collections, Director of the Jay I. Kislak Center, & Director of the Schoenberg Institute for Manuscript Studies University of Pennsylvania Libraries 3420 Walnut Street Philadelphia, PA 19104-6206 -------------- next part -------------- An HTML attachment was scrubbed... URL: