Re: [Archivesspace_Users_Group] Indexed - but still some issues

[Peter Heiner]

Indeed, -Xss is the stack size, this amount gets allocated for each thread
created. I believe the default is 1MB. A general rule of thumb is to increase
it conservatively if you get a stack overflow error in the app.

p

Trevor Thornton wrote on 2021-03-25 16:59:00:
> I may not be understanding it completely, but from what I've read 256k is
> typical for a 64-bit JVM. Given that, 2m is comparatively big. 1g is 500
> times the default, which seems excessively big.
> 
> On Wed, Mar 24, 2021 at 3:06 PM Tom Hanstra  wrote:
> 
> > My understand/reading regarding this setting is that it is the thread size
> > for Java, and has to be big enough to handle the work but cannot be too big
> > either. The default of 2m seems very low. I have been working with the 1g
> > size lately but am not sure that is optimal either. I'd be curious to know
> > if there are optimal numbers that people have found useful.
> >
> > Tom
> >
> > On Wed, Mar 24, 2021 at 12:55 PM Trevor Thornton 
> > wrote:
> >
> >> I'm doing this exact thing right now and I wanted to confirm that the 'g'
> >> here shouldn't be an 'm':
> >> ASPACE_JAVA_XSS="-Xss1g"
> >>
> >> The default looks to be:
> >> ASPACE_JAVA_XSS="-Xss2m"
> >>
> >> https://github.com/archivesspace/archivesspace/blob/master/launcher/archivesspace.sh#L105
> >>
> >> On Wed, Mar 24, 2021 at 11:43 AM Tom Hanstra  wrote:
> >>
> >>> Hmmm. So I finally tracked the issue down to my Java settings. For some
> >>> reason, before/during indexing, Java settings of:
> >>>
> >>> ASPACE_JAVA_XMX="-Xmx8192m"
> >>> ASPACE_JAVA_XSS="-Xss4g"
> >>>
> >>> worked fine. But, once indexing was complete, those settings were
> >>> somehow unusable. Staff connection would not work, searches failed, etc.
> >>>
> >>> But when I crank down the thread size to:
> >>>
> >>>ASPACE_JAVA_XMX="-Xmx8192m"
> >>>ASPACE_JAVA_XSS="-Xss1g"
> >>>
> >>> everything goes back to working. There was a server reboot in there as
> >>> well as numerous restarts with config.rb changes and that was the only
> >>> change that I found could address the issues. Through a number of 
> >>> restarts,
> >>> there was nothing in the logs to indicate the issue. Finally got an error
> >>> that suggested Java space issues and tried the lower value and things now
> >>> work (as far as I've tested at least).
> >>>
> >>> Quite a journey so far...
> >>>
> >>> Tom
> >>>
> >>>
> >>> On Wed, Mar 24, 2021 at 9:54 AM Peter Heiner  wrote:
> >>>
>  Tom Hanstra wrote on 2021-03-24 09:25:24:
>  > So, I am now further than I've been yet, at least based upon the
>  logs. But
>  > I still have something not working properly, because when I do a
>  search and
>  > find output, nothing is coming up when I try to look at the found
>  record. I
>  > get the error:
>  >
>  > *We're sorry, but something went wrong.*
>  >
>  > When I've seen that in other applications, it has been a rails issue.
>  Not
>  > sure if that is what is happening here as well.
> 
>  This error should have a corresponding event with at least WARNING
>  level in
>  the frontend/public log (depending on which gave you the error) that
>  you can
>  correlate by event time.
> 
>  > Also, the "Found In" links for the records come back with:
>  >
>  > *The record you've tried to access does not exist or may have been
>  > removed.The record you've tried to access does not exist or may have
>  been
>  > removed.*
> 
>  This would point to the fact that your database and index are not in
>  sync.
>  Given your struggles with indexing I'm starting to wonder if you're
>  reading
>  from the Solr instance you're writing to.
> 
>  p
> 
>  ___
>  Archivesspace_Users_Group mailing list
>  Archivesspace_Users_Group@lyralists.lyrasis.org
>  http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
> 
> >>>
> >>>
> >>> --
> >>> *Tom Hanstra*
> >>> *Sr. Systems Administrator*
> >>> hans...@nd.edu
> >>>
> >>>
> >>> ___
> >>> Archivesspace_Users_Group mailing list
> >>> Archivesspace_Users_Group@lyralists.lyrasis.org
> >>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
> >>>
> >>
> >>
> >> --
> >> Trevor Thornton
> >> Applications Developer, Digital Library Initiatives
> >> North Carolina State University Libraries
> >> ___
> >> Archivesspace_Users_Group mailing list
> >> Archivesspace_Users_Group@lyralists.lyrasis.org
> >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
> >>
> >
> >
> > --
> > *Tom Hanstra*
> > *Sr. Systems Administrator*
> > hans...@nd.edu
> >
> >
> > ___
> > Archivesspace_Users_Group mailing list
> > Archivesspace_Users_Group@lyralists.lyrasis.org
> > http://lyralists.lyrasis.org/mai

Re: [Archivesspace_Users_Group] Indexed - but still some issues

[Trevor Thornton]

I may not be understanding it completely, but from what I've read 256k is
typical for a 64-bit JVM. Given that, 2m is comparatively big. 1g is 500
times the default, which seems excessively big.

On Wed, Mar 24, 2021 at 3:06 PM Tom Hanstra  wrote:

> My understand/reading regarding this setting is that it is the thread size
> for Java, and has to be big enough to handle the work but cannot be too big
> either. The default of 2m seems very low. I have been working with the 1g
> size lately but am not sure that is optimal either. I'd be curious to know
> if there are optimal numbers that people have found useful.
>
> Tom
>
> On Wed, Mar 24, 2021 at 12:55 PM Trevor Thornton 
> wrote:
>
>> I'm doing this exact thing right now and I wanted to confirm that the 'g'
>> here shouldn't be an 'm':
>> ASPACE_JAVA_XSS="-Xss1g"
>>
>> The default looks to be:
>> ASPACE_JAVA_XSS="-Xss2m"
>>
>> https://github.com/archivesspace/archivesspace/blob/master/launcher/archivesspace.sh#L105
>>
>> On Wed, Mar 24, 2021 at 11:43 AM Tom Hanstra  wrote:
>>
>>> Hmmm. So I finally tracked the issue down to my Java settings. For some
>>> reason, before/during indexing, Java settings of:
>>>
>>> ASPACE_JAVA_XMX="-Xmx8192m"
>>> ASPACE_JAVA_XSS="-Xss4g"
>>>
>>> worked fine. But, once indexing was complete, those settings were
>>> somehow unusable. Staff connection would not work, searches failed, etc.
>>>
>>> But when I crank down the thread size to:
>>>
>>>ASPACE_JAVA_XMX="-Xmx8192m"
>>>ASPACE_JAVA_XSS="-Xss1g"
>>>
>>> everything goes back to working. There was a server reboot in there as
>>> well as numerous restarts with config.rb changes and that was the only
>>> change that I found could address the issues. Through a number of restarts,
>>> there was nothing in the logs to indicate the issue. Finally got an error
>>> that suggested Java space issues and tried the lower value and things now
>>> work (as far as I've tested at least).
>>>
>>> Quite a journey so far...
>>>
>>> Tom
>>>
>>>
>>> On Wed, Mar 24, 2021 at 9:54 AM Peter Heiner  wrote:
>>>
 Tom Hanstra wrote on 2021-03-24 09:25:24:
 > So, I am now further than I've been yet, at least based upon the
 logs. But
 > I still have something not working properly, because when I do a
 search and
 > find output, nothing is coming up when I try to look at the found
 record. I
 > get the error:
 >
 > *We're sorry, but something went wrong.*
 >
 > When I've seen that in other applications, it has been a rails issue.
 Not
 > sure if that is what is happening here as well.

 This error should have a corresponding event with at least WARNING
 level in
 the frontend/public log (depending on which gave you the error) that
 you can
 correlate by event time.

 > Also, the "Found In" links for the records come back with:
 >
 > *The record you've tried to access does not exist or may have been
 > removed.The record you've tried to access does not exist or may have
 been
 > removed.*

 This would point to the fact that your database and index are not in
 sync.
 Given your struggles with indexing I'm starting to wonder if you're
 reading
 from the Solr instance you're writing to.

 p

 ___
 Archivesspace_Users_Group mailing list
 Archivesspace_Users_Group@lyralists.lyrasis.org
 http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

>>>
>>>
>>> --
>>> *Tom Hanstra*
>>> *Sr. Systems Administrator*
>>> hans...@nd.edu
>>>
>>>
>>> ___
>>> Archivesspace_Users_Group mailing list
>>> Archivesspace_Users_Group@lyralists.lyrasis.org
>>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>>
>>
>>
>> --
>> Trevor Thornton
>> Applications Developer, Digital Library Initiatives
>> North Carolina State University Libraries
>> ___
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group@lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>
>
> --
> *Tom Hanstra*
> *Sr. Systems Administrator*
> hans...@nd.edu
>
>
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>


-- 
Trevor Thornton
Applications Developer, Digital Library Initiatives
North Carolina State University Libraries
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

[Archivesspace_Users_Group] release candidate available - ArchivesSpace v3.0.0-RC1

[Christine Di Bella]

Hello ArchivesSpace members,

The ArchivesSpace team is pleased to announce a release candidate, v3.0.0-RC1. 
You can download it at 
https://github.com/archivesspace/archivesspace/releases/tag/v3.0.0-RC1 or test 
it out without downloading at http://test.archivesspace.org/staff  (username 
admin /password admin).

This release candidate centers around changes to the agents module of 
ArchivesSpace to make it more standards-compliant with EAC-CPF and the MARCXML 
format for authority data, enabling deeper and richer description of people, 
families, and corporate entities, their relationships to each other and their 
relationships to materials held outside ArchivesSpace. This work is the result 
of a community specification written through the participation of many users 
across the ArchivesSpace community, mostly notably Cory Nimer, Sue Luftschein, 
and Brad Westbrook. Through this work new fields and sub-records have been 
added to the agents schema, and staff and public interface views, imports, 
exports, and auxiliary functionality like agent merging have all been updated. 
There is also a new Light mode for agents, which provides the option for users 
to continue to work with agent records in the staff interface in a pared down 
view that is similar to that of ArchivesSpace versions prior to this one.

While the bulk of the changes in this release candidate relate to the agents 
module, the release candidate also contains improvements in some other areas of 
the application contributed by community developers and program team developers 
and contractors. Included among these are additional performance, backend and 
staff interface improvements courtesy of work Hudson Molonglo developers James 
Bullen, Mark Triggs, and Payten Giles did for Queensland State Archives as part 
of a larger project.

Every bit of testing and feedback helps us improves the release. We encourage 
you to test these improvements with your own data if you can. Some resources 
you may find helpful when testing include:


  *   Information from the webinar highlighting changes in v3.0.0: 
https://archivesspace.org/archives/6660


  *   Some new or updated user manual sections on the agents module (access 
requires your usual user manual login): 
https://archivesspace.atlassian.net/wiki/label/ArchivesSpaceUserManual/3agents

Thanks to the many community members who made contributions as we worked on 
bringing this expanded functionality to ArchivesSpace, including both 
individual archives staff and developers and our Testing and User Documentation 
sub-teams.

Please try this release candidate out and let us know at 
archivesspaceh...@lyrasis.org by April 7 
if you notice any problems with the specific areas addressed in this release, 
or if anything that was working before no longer is. The results of community 
testing will help us determine a release date.

Please get in touch if you have any questions. Thanks as always for your 
feedback and support.

Christine

Christine Di Bella
ArchivesSpace Program Manager
christine.dibe...@lyrasis.org
800.999.8558 x2905
678-235-2905
cdibella13 (Skype)

[ASpaceOrgHomeMedium]

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

[Archivesspace_Users_Group] Announcing the ARK (Archival Resource Key) Alliance (arks.org)

[Collopy, Peter S.]

Dear colleagues,



[https://lh6.googleusercontent.com/lwniYti6F-oPMreWgw7uJVx5ETdR5-CRxKKdoG68uPnRZtmG2KkSqOPnfopD6Y7-Wio6Ru8rY2pBQ3OMB8IxJWhPprfUbtsG1jJ2Dfq1oVyiJntiYvcGjUg8arOWgScT3hRaNbVB]



We are pleased to announce the formation of the ARK 
Alliance, an open global community supporting Archival 
Resource Keys (ARKs).



The ARK Alliance succeeds the ARKs-in-the-Open 
initiative, begun in 2018. We invite you to visit us 
at our new website, which contains guidance on how to get 
started with ARKs, resources, news, the community, and links to email forums 
for users in English and French.



ARK users can receive news and updates from the ARK community by subscribing to 
the ARK Alliance newsletter and following the ARK 
Alliance on Twitter.



The ARK Alliance has three working groups and welcomes your participation, 
which can take many forms. Please visit the 
community page to learn about ways to become 
involved.



About ARKs:
ARKs are used as “persistent identifiers”, which are stable, trusted references 
(names) for information objects. Among other things, they aim to be web 
addresses (URLs) that don’t return 404 Page Not Found errors.



ARKs are similar to DOIs, URNs, and Handles. All of them

  *
were introduced over 20 years ago,
  *
exist in large numbers (8.2 billion ARKs, 240 million DOIs, etc.),
  *
start with a string to identify the name assigning authority,
  *
require the active updating of URL redirects, and
  *
support research and scholarship, appearing in the Data Citation Index, 
Wikipedia, ORCiD.org profiles, etc.



In contrast, ARKs are cheaper, more flexible, and less centralized, letting you

  *
create unlimited identifiers without paying for the right to do so,
  *
add any kind of metadata, including no metadata,
  *
append extensions and query strings during resolution,
  *
link directly to an article, image, or spreadsheet that is immediately usable 
by people and software without making them first stop at a landing page, and
  *
make millions of ARKs resolvable by managing just one ARK, via a mechanism 
called suffix passthrough.



Who uses ARKs:



End users, especially researchers, rely on ARKs for long term access to the 
global scientific and cultural record, where by design they identify anything 
digital, physical, or abstract.



[https://lh3.googleusercontent.com/lP0IT9ZtBOOQocpPECJ4oTXAEeEwiNGqB7357S-ekVMKjNn55C_aFII6_-V-6S3bNqap2yw_pEwTBVXSovU61FInyITcZee3svapvWCHmns8tNn2pcqv8UdUNLd0NubAPQdXVxQV]



Some things that have ARKs — an article, violin, genealogy, storybook, sports 
photo, and plant specimen — assigned by the Smithsonian Institution, Internet 
Archive, California Digital Library, and FamilySearch.



Over 725 organizations are registered to create ARKs, including libraries, data 
centers, archives, museums, publishers, government agencies, and vendors. 
Additional organizations are signing on rapidly.
[chart of growth of ARK-assigning organizations since 2001]





Peter Sachs Collopy, PhD (he/him)
University Archivist and Head of Archives and Special 
Collections
Caltech Library

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Bug in PUI search filtering?

[Andrew Morrison]

This sounds similar to some observations I made last year in a comment 
on the fix that made defaulting to AND between multiple search terms 
work in the PUI:


https://github.com/archivesspace/archivesspace/pull/1861#issuecomment-620676731

Basically, what I believe is happening is that old versions of Solr, 
including the one packaged with ArchivesSpace, ignore the choice of 
implicit-AND between two or more search terms (as set by q.op or mm in 
AppConfig[:solr_params]) when it receives a query that includes explicit 
Boolean logic. That is the case when you add date filters, because the 
ArchivesSpace backend builds a query to send to Solr in which whatever 
you enter as a user is AND'ed with the date range. The number of hits 
goes up even further when you remove the date filter because 
&filter_q[]= in the URL means it is AND'ing the user's query with a 
search for *. Newer versions of Solr allow q.op or mm parameters to 
apply within subqueries, which removes this issue.


To confirm, are the people who see this effect running ArchivesSpace 
2.8.0 or higher with internal Solr (i.e. is AppConfig[:enable_solr] set 
to true in config.rb)? Or, if using external Solr, is the version lower 
than 5.5?


I'm afraid I never got round to raising a JIRA ticket for this, partly 
because it doesn't actually affect us (we run external Solr and also 
have opted for implicit-OR) and partly because there is probably nothing 
that can be done to fix it (except by upgrading the version of Solr that 
comes with ArchivesSpace, but as I understand it another change made in 
Solr after 4.10 makes that difficult.)


Andrew.


On 25/03/2021 01:13, Brian Hoffman wrote:


Responding to Anna’s original message, I think this issue in JIRA 
captures what is probably going on when a two-word search yields more 
(rather than fewer) results after filtering by another word:


https://archivesspace.atlassian.net/browse/ANW-1240 



*From: * on 
behalf of Blake Carver 
*Reply-To: *Archivesspace Users Group 


*Date: *Wednesday, March 24, 2021 at 4:39 PM
*To: *Archivesspace Users Group 


*Subject: *Re: [Archivesspace_Users_Group] Bug in PUI search filtering?

> Blake, any insight?

Nope, it does look like a bug to me, but I'm not sure on that. I'll 
look into it, and get a JIRA in if that's the case.




*From:*archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of 
Anna Robinson-Sweet 

*Sent:* Wednesday, March 24, 2021 4:03 PM
*To:* Archivesspace Users Group 


*Subject:* Re: [Archivesspace_Users_Group] Bug in PUI search filtering?

That is indeed what seems to be happening. For us it's not only with 
the date filter, but also the free text filter.


Search for fashion designers (113 results): 
https://findingaids.archives.newschool.edu/search?utf8=%E2%9C%93&op%5B%5D=&q%5B%5D=fashion+designers&limit=&field%5B%5D=&from_year%5B%5D=&to_year%5B%5D=&commit=Search 



When I type critics into the filter search bar, 136 results: 
https://findingaids.archives.newschool.edu/search?utf8=%E2%9C%93&op%5B%5D=&q%5B%5D=fashion+designers&limit=&field%5B%5D=&from_year%5B%5D=&to_year%5B%5D=&action=search&sort=&filter_q%5B%5D=critics&filter_from_year=&filter_to_year=&commit=Search 



On Wed, Mar 24, 2021 at 4:00 PM Michelle Paquette > wrote:


Ha, and actually now I've tested it in my own system and this
seems to be the case that when adding the date filter it switches
to OR. Doesn't seem to be happening with any other filters though.
Blake, any insight?

On Wed, Mar 24, 2021 at 3:56 PM Michelle Paquette
mailto:mpaque...@smith.edu>> wrote:

Hi Anna,

I'm wondering if something is happening to the default AND
boolean - if you search fashion OR designers in the first
place you're getting 5998 results, so it seems when you remove
the date filter it switches from an AND to an OR search.

Michelle

On Wed, Mar 24, 2021 at 3:41 PM Anna Robinson-Sweet
mailto:robin...@newschool.edu>> wrote:

Hello,

We just noticed what appears to be a bug in applying
filters to search results in the PUI. When we run a search
on a phrase that is more than one word, and then apply a
filter to those results, we get more results in the
"filtered" search than in the initial one. When we remove
the filter, there are even more results than e