diff --git a/content/posts/2023-02.md b/content/posts/2023-02.md
index 9dd2d3450..2e710ffec 100644
--- a/content/posts/2023-02.md
+++ b/content/posts/2023-02.md
@@ -202,4 +202,130 @@ Done.
- I think that particular error is because I applied the [indexes in this unmerged DSpace 6 patch](https://github.com/DSpace/DSpace/pull/1792), so I don't need to report this as an error in DSpace 7
+## 2023-02-16
+
+- I found a suspicious number of PostgreSQL locks on CGSpace and decided to investigate:
+
+```console
+$ psql -c 'SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON pl.pid = psa.pid;' | grep -o -E '(dspaceWeb|dspaceApi|dspaceCli)' | sort | uniq -c
+ 44 dspaceApi
+ 372 dspaceCli
+ 446 dspaceWeb
+```
+
+- This started happening yesterday and I killed a few locks that were several hours old after inspecting the `locks-age.sql` output
+- I also checked the `locks.sql` output, which helpfully lists the blocked PID and the blocking PID, to find one blocking PID that was idle in transaction
+ - I killed that process and then all other locks were instantly processed
+- I filed [a GitHub issue](https://github.com/DSpace/dspace-angular/issues/2103) on dspace-angular requesting the item view to use the bitstream description instead of the file name if present
+- Weekly CG Core types meeting
+ - I need to go through the actions and remove those items that are only for CGSpace internal use, ie:
+ - CD-ROM
+ - Manuscript-unpublished
+ - Photo Report
+ - Questionnaire
+ - Wiki
+- Weekly CGIAR Repository Working Group meeting
+- I did some experiments with Crossref dates for about 20,000 DOIs in CGSpace using my `crossref-doi-lookup.py` script
+- Some things I noted from reading the [Crossref API docs](https://github.com/CrossRef/rest-api-doc/blob/master/api_format.md) and inspecting the records for a few dozen DOIs manually:
+ - `["created"]["date-parts"]` → Date on which the DOI was first registered (not useful for us)
+ - `["published-print"]["date-parts"]` → Date on which the work was published in print
+ - `["journal-issue"]["published-print"]["date-parts"]` → When present, is 99% the same as the above
+ - `["published-online"]["date-parts"]` → Date on which the work was published online
+ - `["journal-issue"]["published-online"]["date-parts"]` → Much more rare, and only 50% the same as the above, so unreliable
+ - `["issued"]["date-parts"]` → Earliest of published-print and published-online (not useful to us)
+- After checking the DOIs manully I decided that when the `published-print` date exists, it is usually more accurate than our issued dates
+ - I set 12,300 issue dates to those from Crossref
+- I also decided that, when `published-online` exists, it is usually accurate when I check the publisher page (we don't have many online dates to compare)
+ - I set the available date for ~7,000 items to the published-online date as long as:
+ - There was no `dcterms.available` date already
+ - It was different than the issued date, because for now I only want online dates that are different, in case this is an online only journal in which case that can be the issue date... maybe I'll re-visit that later
+
+## 2023-02-17
+
+- It seems some (all?) of the changes I applied to dates last night didn't get saved...
+ - I don't know what happened, so I will run them again after some investigation
+ - I submitted the first batch of ~7,600 changes and it took twelve hours!
+ - I almost cancelled it because after applying the changes there was a lock blocking everything for two hours, and it seemed to be stuck, but I kept checking it and saw that the `query_start` and `state_change` were being updated despite it being state "idle in transaction":
+
+```console
+$ psql -c 'SELECT * FROM pg_stat_activity WHERE pid=1025176' | less -S
+```
+
+- I will apply the other changes in smaller batches...
+- Lately I've noticed a lot of activity from the country code tagger curation task
+ - Looking in the logs I see items being tagged that are very old and should have already been tagged years ago
+ - Also, I see a ton of these errors whenever the task is updating an item:
+
+```console
+2023-02-17 08:01:00,252 INFO org.dspace.curate.Curator @ Curation task: countrycodetagger performed on: 10568/89020 with status: 0. Result: '10568/89020: added 1 alpha2 country code(s)'
+2023-02-17 08:01:00,467 ERROR com.atmire.versioning.ModificationLogger @ Error while writing item to versioning index: a0fe9d9a-6ac1-4b6a-8fcb-dae07a6bbf58 message:missing required field: epersonID
+org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: missing required field: epersonID
+ at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:552)
+ at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:210)
+ at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:206)
+ at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:124)
+ at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116)
+ at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102)
+ at com.atmire.versioning.ModificationLogger.indexItem(ModificationLogger.java:263)
+ at com.atmire.versioning.ModificationConsumer.end(ModificationConsumer.java:134)
+ at org.dspace.event.BasicDispatcher.dispatch(BasicDispatcher.java:157)
+ at org.dspace.core.Context.dispatchEvents(Context.java:455)
+ at org.dspace.curate.Curator.visit(Curator.java:541)
+ at org.dspace.curate.Curator$TaskRunner.run(Curator.java:568)
+ at org.dspace.curate.Curator.doCollection(Curator.java:515)
+ at org.dspace.curate.Curator.doCommunity(Curator.java:487)
+ at org.dspace.curate.Curator.doSite(Curator.java:451)
+ at org.dspace.curate.Curator.curate(Curator.java:269)
+ at org.dspace.curate.Curator.curate(Curator.java:203)
+ at org.dspace.curate.CurationCli.main(CurationCli.java:220)
+ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
+ at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
+ at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
+ at java.lang.reflect.Method.invoke(Method.java:498)
+ at org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:229)
+ at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:81)
+```
+
+- This must be related...
+
+## 2023-02-18
+
+- I realized why the country-code-tagger was tagging everything: I had overridden the `force` parameter last week!
+- Start a harvest on AReS
+
+## 2023-02-20
+
+- IWMI is concerned that some of their items with top Altmetric attention scores don't show up in the AReS Explorer
+ - I looked into it for one and found that AReS is using the Handle, but Altmetric hasn't associated the Handle with the DOI
+- Looking into country and region issues for the PRMS team
+ - Last week they had some questions about some invalid countries that ended up being typos
+ - I realized my cgspace-java-helpers country-code-tagger curation task is not using the latest version, so it was missing Türkiye
+ - I compiled the new version and ran it manually, but I have to upload a new version to Maven Central and then update the dependency in `dspace/modules/additions/pom.xml` ughhhhhh
+ - I tagged version 6.2 with the change for Türkiye and uploaded to to Maven Central with `mvn clean deploy`
+- I'm having second thoughts about switching to UN M.49 for countries because there are just too many tradeoffs
+ - I want to find a way to keep our existing list, and codify some rules for it
+ - There are several discussions related to the shortcomings of ISO themselves and the iso-codes project, for example:
+ - [Inconsistency with articles in ISO-3166-1 English short names](https://salsa.debian.org/iso-codes-team/iso-codes/-/issues/33) (this one was filed by me two years ago!)
+ - [ISO 3166-1: What's the policy for `common_name`?](https://salsa.debian.org/iso-codes-team/iso-codes/-/issues/44)
+ - I almost want to say fuck it, let's just use iso-codes and tell everyone to deal with it, but make sure we handle ISO 3166-1 Alpha2 or probably Alpha3 in the future
+ - Something like:
+ - Prefer `common_name` if it exists
+ - Prefer the shorter of `name` and `official name`
+
+## 2023-02-21
+
+- Continue working on my `parse-iso-codes.py` script to parse the iso-codes JSON for ISO 3166-1
+ - I also started a spreadsheet to track current CGSpace country names, proposed new names using the compromise above, and UN M.49 names
+ - I proposed this to Peter but he wasn't happy because there are still some stupidly long and political names there
+- I bumped the version of cgspace-java-helpers to 6.2-SNAPSHOT and pushed it to Maven Central because I can't figure out how to get non-snapshot releases to go there
+- Ouch, grunt 1.6.0 was released a few weeks ago, which relies on Node.js v16, thus breaking the Mirage 2 build in DSpace 6
+ - I filed [an issue in DSpace](https://github.com/DSpace/DSpace/issues/8676)
+- Help Moises from CIP troubleshoot harvesting issues on their WordPress site
+ - I see 2,000 requests with the user agent "RTB website BOT" today and they are all HTTP 200
+
+```console
+# grep 'RTB website BOT' /var/log/nginx/rest.log | awk '{print $9}' | sort | uniq -c | sort -h
+ 2023 200
+```
+
diff --git a/docs/2023-02/index.html b/docs/2023-02/index.html
index a2f3dcac2..355689546 100644
--- a/docs/2023-02/index.html
+++ b/docs/2023-02/index.html
@@ -18,7 +18,7 @@ I want to try to expand my use of their data to journals, publishers, volumes, i
-
+
@@ -42,9 +42,9 @@ I want to try to expand my use of their data to journals, publishers, volumes, i
"@type": "BlogPosting",
"headline": "February, 2023",
"url": "https://alanorth.github.io/cgspace-notes/2023-02/",
- "wordCount": "1245",
+ "wordCount": "2333",
"datePublished": "2023-02-01T10:57:36+03:00",
- "dateModified": "2023-02-14T23:13:35+03:00",
+ "dateModified": "2023-02-15T19:47:13+03:00",
"author": {
"@type": "Person",
"name": "Alan Orth"
@@ -340,7 +340,175 @@ I want to try to expand my use of their data to journals, publishers, volumes, i
-
+2023-02-16
+
+- I found a suspicious number of PostgreSQL locks on CGSpace and decided to investigate:
+
+$ psql -c 'SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON pl.pid = psa.pid;' | grep -o -E '(dspaceWeb|dspaceApi|dspaceCli)' | sort | uniq -c
+ 44 dspaceApi
+ 372 dspaceCli
+ 446 dspaceWeb
+
+- This started happening yesterday and I killed a few locks that were several hours old after inspecting the
locks-age.sql output
+- I also checked the
locks.sql output, which helpfully lists the blocked PID and the blocking PID, to find one blocking PID that was idle in transaction
+
+- I killed that process and then all other locks were instantly processed
+
+
+- I filed a GitHub issue on dspace-angular requesting the item view to use the bitstream description instead of the file name if present
+- Weekly CG Core types meeting
+
+- I need to go through the actions and remove those items that are only for CGSpace internal use, ie:
+
+- CD-ROM
+- Manuscript-unpublished
+- Photo Report
+- Questionnaire
+- Wiki
+
+
+
+
+- Weekly CGIAR Repository Working Group meeting
+- I did some experiments with Crossref dates for about 20,000 DOIs in CGSpace using my
crossref-doi-lookup.py script
+- Some things I noted from reading the Crossref API docs and inspecting the records for a few dozen DOIs manually:
+
+["created"]["date-parts"] → Date on which the DOI was first registered (not useful for us)["published-print"]["date-parts"] → Date on which the work was published in print["journal-issue"]["published-print"]["date-parts"] → When present, is 99% the same as the above["published-online"]["date-parts"] → Date on which the work was published online["journal-issue"]["published-online"]["date-parts"] → Much more rare, and only 50% the same as the above, so unreliable["issued"]["date-parts"] → Earliest of published-print and published-online (not useful to us)
+
+- After checking the DOIs manully I decided that when the
published-print date exists, it is usually more accurate than our issued dates
+
+- I set 12,300 issue dates to those from Crossref
+
+
+- I also decided that, when
published-online exists, it is usually accurate when I check the publisher page (we don’t have many online dates to compare)
+
+- I set the available date for ~7,000 items to the published-online date as long as:
+
+- There was no
dcterms.available date already
+- It was different than the issued date, because for now I only want online dates that are different, in case this is an online only journal in which case that can be the issue date… maybe I’ll re-visit that later
+
+
+
+
+
+2023-02-17
+
+- It seems some (all?) of the changes I applied to dates last night didn’t get saved…
+
+- I don’t know what happened, so I will run them again after some investigation
+- I submitted the first batch of ~7,600 changes and it took twelve hours!
+- I almost cancelled it because after applying the changes there was a lock blocking everything for two hours, and it seemed to be stuck, but I kept checking it and saw that the
query_start and state_change were being updated despite it being state “idle in transaction”:
+
+
+
+$ psql -c 'SELECT * FROM pg_stat_activity WHERE pid=1025176' | less -S
+
+- I will apply the other changes in smaller batches…
+- Lately I’ve noticed a lot of activity from the country code tagger curation task
+
+- Looking in the logs I see items being tagged that are very old and should have already been tagged years ago
+- Also, I see a ton of these errors whenever the task is updating an item:
+
+
+
+2023-02-17 08:01:00,252 INFO org.dspace.curate.Curator @ Curation task: countrycodetagger performed on: 10568/89020 with status: 0. Result: '10568/89020: added 1 alpha2 country code(s)'
+2023-02-17 08:01:00,467 ERROR com.atmire.versioning.ModificationLogger @ Error while writing item to versioning index: a0fe9d9a-6ac1-4b6a-8fcb-dae07a6bbf58 message:missing required field: epersonID
+org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: missing required field: epersonID
+ at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:552)
+ at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:210)
+ at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:206)
+ at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:124)
+ at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116)
+ at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102)
+ at com.atmire.versioning.ModificationLogger.indexItem(ModificationLogger.java:263)
+ at com.atmire.versioning.ModificationConsumer.end(ModificationConsumer.java:134)
+ at org.dspace.event.BasicDispatcher.dispatch(BasicDispatcher.java:157)
+ at org.dspace.core.Context.dispatchEvents(Context.java:455)
+ at org.dspace.curate.Curator.visit(Curator.java:541)
+ at org.dspace.curate.Curator$TaskRunner.run(Curator.java:568)
+ at org.dspace.curate.Curator.doCollection(Curator.java:515)
+ at org.dspace.curate.Curator.doCommunity(Curator.java:487)
+ at org.dspace.curate.Curator.doSite(Curator.java:451)
+ at org.dspace.curate.Curator.curate(Curator.java:269)
+ at org.dspace.curate.Curator.curate(Curator.java:203)
+ at org.dspace.curate.CurationCli.main(CurationCli.java:220)
+ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
+ at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
+ at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
+ at java.lang.reflect.Method.invoke(Method.java:498)
+ at org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:229)
+ at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:81)
+
2023-02-18
+
+- I realized why the country-code-tagger was tagging everything: I had overridden the
force parameter last week!
+- Start a harvest on AReS
+
+2023-02-20
+
+- IWMI is concerned that some of their items with top Altmetric attention scores don’t show up in the AReS Explorer
+
+- I looked into it for one and found that AReS is using the Handle, but Altmetric hasn’t associated the Handle with the DOI
+
+
+- Looking into country and region issues for the PRMS team
+
+- Last week they had some questions about some invalid countries that ended up being typos
+- I realized my cgspace-java-helpers country-code-tagger curation task is not using the latest version, so it was missing Türkiye
+- I compiled the new version and ran it manually, but I have to upload a new version to Maven Central and then update the dependency in
dspace/modules/additions/pom.xml ughhhhhh
+- I tagged version 6.2 with the change for Türkiye and uploaded to to Maven Central with
mvn clean deploy
+
+
+- I’m having second thoughts about switching to UN M.49 for countries because there are just too many tradeoffs
+
+- I want to find a way to keep our existing list, and codify some rules for it
+- There are several discussions related to the shortcomings of ISO themselves and the iso-codes project, for example:
+
+
+- I almost want to say fuck it, let’s just use iso-codes and tell everyone to deal with it, but make sure we handle ISO 3166-1 Alpha2 or probably Alpha3 in the future
+- Something like:
+
+- Prefer
common_name if it exists
+- Prefer the shorter of
name and official name
+
+
+
+
+
+2023-02-21
+
+- Continue working on my
parse-iso-codes.py script to parse the iso-codes JSON for ISO 3166-1
+
+- I also started a spreadsheet to track current CGSpace country names, proposed new names using the compromise above, and UN M.49 names
+- I proposed this to Peter but he wasn’t happy because there are still some stupidly long and political names there
+
+
+- I bumped the version of cgspace-java-helpers to 6.2-SNAPSHOT and pushed it to Maven Central because I can’t figure out how to get non-snapshot releases to go there
+- Ouch, grunt 1.6.0 was released a few weeks ago, which relies on Node.js v16, thus breaking the Mirage 2 build in DSpace 6
+
+
+- Help Moises from CIP troubleshoot harvesting issues on their WordPress site
+
+- I see 2,000 requests with the user agent “RTB website BOT” today and they are all HTTP 200
+
+
+
+# grep 'RTB website BOT' /var/log/nginx/rest.log | awk '{print $9}' | sort | uniq -c | sort -h
+ 2023 200
+