IdeaFix написал(а):
-------------------------------------------------------
> Тут многое зависит от...
>
> А что вы делаете когда разные истероидные личности
> творят под псевдонимами? А когда авторов без их
> ведома транслитеруют на половину европейских
> языков? А замуж-развод и еще пачку синонимов?
>
> В принципе, в системе, у которой главное это
> "заглавие", а автор приписывается к заглавию.
> иначе как костылями это не решить. В DSpace CRIS
> данная проблема решена более или менее изящно, но
> это требует изменения модели данных. На уровне
> костылей можно попытаться решить данную проблему
> посредством ORCID внутри dspace, либо же
> агитировать сотрудников за профили в GS, Academia
> EDU и пр.
>
> Но любой адекватный библиотекарь скажет что нельзя
> вносить в описание данные, которых нет. Если очень
> хочется - можно взять их в квадратные скобочки :)
> А для синонимов есть авторитетный файл.
>
> Про полных тёсок я уже и не спрашиваю... неужто
> вносите их как Иванов1 и иванов2, чтобы не дай бог
> не было пересечений :)

И пусть себе творят! Любой адекватный библиотекарь знает, как справиться и с псевдонимами, и с тезками!

А если серьезно, то, конечно данные поля citation заполняются строго по источнику. Но имеются и другие метаданные, куда можно вносить дополнительные сведения на усмотрение каталогизатора, в том числе - разночтения фамилий в любых вариантах и количествах.

P.S.Тезки кроме фамилий имеют инициалы. Поэтому никаких проблем не вижу.

> P.S.Тезки кроме фамилий имеют инициалы.
> Поэтому никаких проблем не вижу.

Каждый день сталкиваемся со 100% совпадением ФИО и даже тематик при работе с эльзивиром и кларивейтом :) Но вообще да, проблем нет.

Проблему, описанную выше (а я жму на поиск по автору а вылезает не всё, или не то что нужно) в данном случае не решить. Можно добавить поле метаданных со ссылкой на запись в АБИС, на авторитетный файл автора и пр. (очень хорошо реализовано в ТПУ - [earchive.tpu.ru]), но именно просмотровый индекс "по автору" можно сколь угодно долго подпирать костылями. Он от этого не перестанет быть лишь просмотровым индексом с костылями :(

В ТПУ данный функционал для публичного доступа недоделали, в СФУ вроде доделали, в Казанском федеральном интересное решение с вуфайндом над всем сверху, но, это уже не репозитории в чистом виде, это уже действительно больше похоже на CRIS.

Не в тему, конечно, но может кто-нибудь сталкивался. Никто не знает есть ли у РИНЦа (https://elibrary.ru) апи, позволяющее забирать данные о показателях конкретного автора?

andikk написал(а):
-------------------------------------------------------
> Не в тему, конечно, но может кто-нибудь
> сталкивался. Никто не знает есть ли у РИНЦа
> (https://elibrary.ru) апи, позволяющее забирать
> данные о показателях конкретного автора?


Есть. Платное. Достаточно дорогое.
Если бы мне было очень нужно, то я бы просто регулярно парсил соответствующие страницы.

Парсить ринц? :) Наверное, гугл академию курлить проще...

IdeaFix написал(а):
-------------------------------------------------------
> Парсить ринц? :) Наверное, гугл академию курлить
> проще...


Ну, если бы ГуглАкадемия собирала и содержала актуальные сведения о показателях конкретных авторов, то возможно и было бы проще. Но там такой информации нет.
Я сомневаюсь, что кто-то кроме РИНЦа владеет точной информацией по авторам, включая и самих авторов.

Игорь написал(а):
-------------------------------------------------------
> Ну, если бы ГуглАкадемия собирала и содержала
> актуальные сведения о показателях конкретных
> авторов, то возможно и было бы проще. Но там такой
> информации нет.
> Я сомневаюсь, что кто-то кроме РИНЦа владеет
> точной информацией по авторам, включая и самих
> авторов.

Ну, гугл академия в общем предоставляет авторам такую возможность, так или иначе, только вот если натравить на неё curl то... получится то, что должно получиться. А небезызвестная питонная оснастка работает именно что по конкретным авторам и тоже быстро банится. Что же до РИНЦ, то в сезон туда браузером не зайти, не то, что курлом.

В принципе, мы регулярно выгружаем xml файлы всего, что аффилировано с конторой, и парсим на стороне CRIS системы, получается нормально. Только вот в силу "родовой" принадлежности CRIS системы, она показывает хирш и цитирования только по SCOPUS, по остальным источникам (wos, ринц) только внутри, но не для внешнего наблюдателя :(

говорят(С), что если серверу скормить правильного юзер-агента и не слишком шустро переходить по ссылкам, то он гарантированно отдаст всё, что попросишь, вне зависимости от языка и библиотеки, на котором написан скрапер

хотя, я нарывался на разные варианты ответа сервера еще и в зависимости от наличия/отсутствия кук

а где у гугл-академии сводная статистика по автору? может, оно действительно удобнее РИНЦа ?

> а где у гугл-академии сводная статистика по автору? может,
> оно действительно удобнее РИНЦа ?

Так в профиле юзера - [scholar.google.ru]

Но это ни в коем случае не замена РИНЦ (по функционалу).

woodyfon написал(а):
-------------------------------------------------------
> НО если посмотреть через админку на этого
> пользователя, то запись о том, что пользователь
> включён в данную группу в интерфейсе Dspace
> отсутствует.
> Все верно, пользователя же в БД нет. Ему временно
> предоставляются соответствующие права.


Как пользователь может отсутствовать в БД, если он зарегистрирован?
Столкнулся с очень похожей проблемой. Суть в том, чтобы все новые зарегистрировавшиеся пользователи попадали в отдельную группу. Я сделал как в документации новую группу и указал её в конфиге. В админке новые пользователи не отображаются в этой группе, только в общем списке юзеров. Насчёт прав на коллекции, как писал andikk, не проверял. Хорошо, если оно действительно работает. Но у меня другая цель: отделить всех саморегистрирующихся пользователей и сформировать по ним статистику. Пока не совсем понимаю, как достичь конечной цели. На текущем этапе хорошо бы понять как убедится, что пользователь попадает в указанную группу, и попадает ли. Визуально я этого не вижу

Поднимаю вопрос.

В фасете справа не отображается один из авторов.
[rep.bsatu.by]

было написано так discovery.xml:
<property name="metadataFields">
<list>
<value>dc.contributor.author</value>
<value>dc.creator</value>
</list>
</property>
не отображался Сашко, Константин Владимирович (62)

сделал так:
<property name="metadataFields">
<list>
<value>dc.contributor.*</value>
<value>dc.creator</value>
</list>
</property>

запустил bin/dspace index-discovery -b
появились составители (Библиотека), но пропал Синельников, Владимир Михайлович (62)
он есть в гуг кэше:

[webcache.googleusercontent.com]

страница автора:

Цитата:

ы
http://rep.bsatu.by/browse?type=author&order=ASC&rpp=20&value=Синельников%2C+Владимир+Михайлович

В чём проблема?



===
Как добавить фасет с новым именем?
При переиндексации пишет ошибку в homepageConfiguration
Хотел, чтобы остался и старый, и сделать новый.

===
И ещё интересный момент.
В авторах показывало, что у Библиотеки 90 документов, хотя их 95.
Вычислил, какие не отображаются, зашёл в редактирования одного из документов, нажал "Обновить" (ничего не менял), документов стало отображаться 91. Проделе аналогично с остальными потерянными.
Что это странность?



Редактировано 3 раз. Последний раз 14.02.2019 11:53 пользователем PavelDAS.

PavelDAS
Что-то у Вас с SOLR и Вы не читаете логов. Для верности chown и fsck на то, куда solr кэширует. Потом читать логи dspace/solr.

IdeaFix написал(а):
-------------------------------------------------------
> PavelDAS
> Что-то у Вас с SOLR и Вы не читаете логов. Для
> верности chown и fsck на то, куда solr кэширует.
> Потом читать логи dspace/solr.

Система установлена на виртуалке.
в логах solr только такие ошибки location:d298627c-cdb6-4fb4-b8b2-816a862a3bb6:

d298627c-cdb6-4fb4-b8b2-816a862a3bb6 -- не ID ресурса, а. похоже, какой-то коллекции, только какой?

2019-02-18 01:03:58,407 ERROR org.dspace.search.Harvest @ org.apache.solr.search.SyntaxError: Cannot parse 'location:d298627c-cdb6-4fb4-b8b2-816a862a3bb6:[* TO *]': Encountered " ":" ": "" at line 1, column 45.
Was expecting one of:
    <EOF> 
    <AND> ...
    <OR> ...
    <NOT> ...
    "+" ...
    "-" ...
    <BAREOPER> ...
    "(" ...
    "*" ...
    "^" ...
    <QUOTED> ...
    <TERM> ...
    <FUZZY_SLOP> ...
    <PREFIXTERM> ...
    <WILDTERM> ...
    <REGEXPTERM> ...
    "[" ...
    "{" ...
    <LPARAMS> ...
    <NUMBER> ...
    
org.dspace.discovery.SearchServiceException: org.apache.solr.search.SyntaxError: Cannot parse 'location:d298627c-cdb6-4fb4-b8b2-816a862a3bb6:[* TO *]': Encountered " ":" ": "" at line 1, column 45.
Was expecting one of:
    <EOF> 
    <AND> ...
    <OR> ...
    <NOT> ...
    "+" ...
    "-" ...
    <BAREOPER> ...
    "(" ...
    "*" ...
    "^" ...
    <QUOTED> ...
    <TERM> ...
    <FUZZY_SLOP> ...
    <PREFIXTERM> ...
    <WILDTERM> ...
    <REGEXPTERM> ...
    "[" ...
    "{" ...
    <LPARAMS> ...
    <NUMBER> ...
    
	at org.dspace.discovery.SolrServiceImpl.search(SolrServiceImpl.java:1658)
	at org.dspace.discovery.SolrServiceImpl.search(SolrServiceImpl.java:1613)
	at org.dspace.search.Harvest.harvest(Harvest.java:135)
	at org.dspace.app.webui.servlet.FeedServlet.itemsChanged(FeedServlet.java:280)
	at org.dspace.app.webui.servlet.FeedServlet.doDSGet(FeedServlet.java:230)
	at org.dspace.app.webui.servlet.DSpaceServlet.processRequest(DSpaceServlet.java:126)
	at org.dspace.app.webui.servlet.DSpaceServlet.doGet(DSpaceServlet.java:73)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
	at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
	at org.dspace.utils.servlet.DSpaceWebappServletFilter.doFilter(DSpaceWebappServletFilter.java:78)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80)
	at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:341)
	at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:486)
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:861)
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Thread.java:745)

Редактировано 1 раз. Последний раз 18.02.2019 13:45 пользователем PavelDAS.

То, что система установлена на виртуалке не исключает как слёт прав, так и логическое повреждение ФС к сожалению. Хотя, вероятность второго несколько меньше.

А вообще, вроде похоже - [jira.duraspace.org] , только вот судя по описанию, это симптом другой проблемы.



Редактировано 1 раз. Последний раз 18.02.2019 15:25 пользователем IdeaFix.

С фасетами у нас проблем не было, просто правили discovery.xml и файл перевода:
[elib.uraic.ru]
[idun.urfu.ru] а тут вообще просто пример как не надо делать :) Но тем не менее это работает

IdeaFix написал(а):
-------------------------------------------------------
> Коллеги, а никто не настраивал архивацию логов
> сабжа в архив? Ну как у сквида, напрмер, логи
> бьются на кусочки и зипятся, штатными средствами и
> при этом доступны для программы, а то логов уже
> под 20ГБ и они всё растут.
>
> noisse
> Я помню наш "уговор", просто с началом учебного
> года свалилось много работы, как только освобожусь
> - напишу и про 1.8.х и про 3.0.х нормально,
> тяп-ляп делать неохота.

Добрый день!
Dspace 5.6.
Как вы решили проблему с логами?
У меня папка dspace/log неимоверно выросла и /tomcat8/logs не отстает.

PVF написал(а):
-------------------------------------------------------
> IdeaFix написал(а):
> --------------------------------------------------
> -----
> > Коллеги, а никто не настраивал архивацию логов
> > сабжа в архив? Ну как у сквида, напрмер, логи
> > бьются на кусочки и зипятся, штатными средствами
> и
> > при этом доступны для программы, а то логов уже
> > под 20ГБ и они всё растут.
> >
> > noisse
> > Я помню наш "уговор", просто с началом учебного
> > года свалилось много работы, как только
> освобожусь
> > - напишу и про 1.8.х и про 3.0.х нормально,
> > тяп-ляп делать неохота.
>
> Добрый день!
> Dspace 5.6.
> Как вы решили проблему с логами?
> У меня папка dspace/log неимоверно выросла и
> /tomcat8/logs не отстает.


Можно изменить уровень логов с INFO на ERROR, тогда будут записываться только ошибки + критические ошибки, а не всё вподряд.
[dspace]/config/log4j.properties
[dspace]/config/log4j-solr.properties

Tomcat описан здесь:
[tomcat.apache.org]

============
Отключил RSS, посмотрю, что получится. Автор не появился...



Редактировано 1 раз. Последний раз 19.02.2019 10:42 пользователем PavelDAS.

> Отключил RSS, посмотрю, что получится. Автор не появился...

Не, я к тому, что ошибка в логках указывает на ошибку RSS, но не объясняет странного поведения просмотрового индекса. Т.е. не тот симптом. Кстати, а что у наст там в ветке 6.х последнее? Может обновиться?

А по логам... блин, я жму средствами ФС. Логи томкэта - единственная более или менее достоверная статистика. Логи dspace - "другая" статистика. И если логам tomcat можно раз в пару месяцев устраивать logrotation вручную, то логи dspace для stat-genetal и stat-initial должны быть на месте все :(

Без RSS ошибок нет. И автора нет...
Индекс работает, но странно, выкидывает одного (или нескольких?) авторов.
И каждый раз разного, зависит у кого стало статей больше.

Иногда в логах dspace выскакивает warning на pdf:
2019-02-20 10:46:07,065 WARN org.dspace.app.webui.servlet.InternalErrorServlet @ :session_id=518A76C49B1763D0949CBA30CF4F2C1A:internal_error:-- URL Was: [rep.bsatu.by]
-- Method: GET
-- Parameters were:

javax.servlet.ServletException: java.lang.IllegalStateException: Cannot forward after response has been committed
at org.dspace.app.webui.util.JSPManager.showJSP(JSPManager.java:62)
at org.dspace.app.webui.util.JSPManager.showInternalError(JSPManager.java:78)
at org.dspace.app.webui.servlet.DSpaceServlet.processRequest(DSpaceServlet.java:169)
at org.dspace.app.webui.servlet.DSpaceServlet.doGet(DSpaceServlet.java:73)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at org.dspace.utils.servlet.DSpaceWebappServletFilter.doFilter(DSpaceWebappServletFilter.java:78)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:341)
at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:486)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:861)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalStateException: Cannot forward after response has been committed
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:321)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:311)
at org.dspace.app.webui.util.JSPManager.showJSP(JSPManager.java:60)
... 30 more



Редактировано 1 раз. Последний раз 20.02.2019 09:50 пользователем PavelDAS.

PavelDAS
Может всё же обновиться до 6.3?

Добрый день.
Подскажите пожалуйста настраиваю ОАІ.
При входе репозитарий/oai/ - ошибка HTTP Status 404 - Requested OAI context "" does not exist.
При этом /oai/request?verb=Identify и остальные пункты отображаются.
Где копать?

Вообще, /oai работать и не должен (на классическом OAI, не XOAI). Базовый урл - /oai/request

[elar.urfu.ru] вот так стало отрабатывать в 5-м dspace с xoai, но там были косяки с путями - был захардкожен никсовый путь - [jira.duraspace.org] вообще забавно что тривиал баг, который я вешал 3 года назад, до сих пор не закрыт :)

При /oai/request сообщение на красном фоне Illegal verb. Это нормально?
И dspace oai import нужно делать каждый день?

> При /oai/request сообщение на красном фоне Illegal verb.
> Это нормально?

Да. Это base url. Дальше уже харвестер разбирается что и как.

> И dspace oai import нужно делать каждый день?

То, что было загружено в репозиторий после последнего oai import, появится в фиде только после следующего. Я делаю по крону раз в сутки вместе с filter-media, generate-sitemaps и пр.

[wiki.duraspace.org]

>Т.е. не тот симптом. Кстати, а что у наст там в ветке 6.х последнее? Может обновиться?
Сомневаюсь, работает Dspace 5.6, лучше не трогать...

>А по логам... блин, я жму средствами ФС. Логи томкэта - единственная более или менее достоверная статистика.
В папку /tomcat/logs падают файлы localhost_access_log.дата.txt, localhost.дата.log, catalina.дата.log, catalina.out.
localhost_access_log.дата.txt разрастается бесконтрольно до несколько Гб с Get-запросами каждую секунду. Другие файлы catalina.дата.log, localhost.*.log, catalina.out "бьют" количеством.

Думаю раз в месяц "Logrotate" мне не поможет, необходимо наверное size 100M и rotate 7. Или удалить /cong/logging.properties :)

В catalina.out постоянная ошибка:
19-Feb-2019 16:01:19.037 SEVERE [ajp-nio-8009-exec-2] org.apache.coyote.ajp.AjpMessage.processHeader Invalid message received with signature [18245]
19-Feb-2019 17:00:21.325 INFO [http-nio-8080-exec-81] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:472)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:683)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)

20-Feb-2019 01:49:21.632 INFO [http-nio-8080-exec-150] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method names must be tokens
at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:422)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:683)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)

Говорят, это баг версии Apache Tomcat/8.5.16. Есть решение?


> Логи dspace - "другая" статистика. И если логам tomcat можно раз в пару месяцев устраивать logrotation вручную, то логи dspace для stat-genetal и stat-initial должны быть на месте все :(
В /dspace/log лежит solr.log, checker.log.*, dspace.log.*, cocoon.log.*.
Если я не ошибаюсь для статистика нужен solr.log. Не могут же логи расти до бесконечности? У меня папка увеличивается каждый день на 1 Гб.

Как вариант:
> Можно изменить уровень логов с INFO на ERROR, тогда будут записываться только ошибки + критические ошибки, а не всё вподряд.
[dspace]/config/log4j.properties
[dspace]/config/log4j-solr.properties

> Сомневаюсь, работает Dspace 5.6, лучше не трогать...
Там 6.0 вроде у коллеги, а вот насчет 5.6... почитал я ченджлоги в 5.10 и как-то запланировал обновляться на 8 марта :)

> Думаю раз в месяц "Logrotate" мне не поможет, необходимо
> наверное size 100M и rotate 7. Или удалить /cong/logging.properties :)
Ну, даже средствами NTFS это всё жмется на больших объёмах на два порядка, на маленьких - на один. Текст же... но если логи не нужны - конечно их нужно чистить.

> Если я не ошибаюсь для статистика нужен solr.log.
> Не могут же логи расти до бесконечности? У меня папка
> увеличивается каждый день на 1 Гб.

А Вы переместите логи все кроме solr.log и сделайте dspace stat-initial :) В том-то и печать что этой дряни нужно всё :(

> Можно изменить уровень логов с INFO на ERROR, тогда
> будут записываться только ошибки + критические ошибки,
> а не всё вподряд.

Это если Вы по логам вебсервера посещаемость не смотрите. Мы вот смотрим...

По ошибке, как у Вас https ревлизован? Понимаю что пальцем в небо, но попробуйте

<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on"/>

в server.xml

Да, кстати... я уже давненько забанил китай практически на всех подшефных репозиториях (вот просто ВСЕ китайские автономки). На совсем слабых железках выборочно побанил амазон, чтобы отпали semrush, turtin и пр. И жить стало веселее! И логов меньше и коннекшоны к СУБД исчерпавшиеся - скорее исключение, чем правило.

У нас самый слабенький dspace лег.... положили с 63.247.139.18, если гуглить, получается даже забавно - electra.hmdnsgroup.com :)

Кстати, кто как отбивается? Файл2бан? Ручные блокировки?

Стандартно: robots.txt, закрыт User-agent: SemrushBot-SA (BLEXBot, AlphaSeoBot-SA) Disallow: /.
Китая и 63.247.* в логах пока не вижу.

А, как вы боритесь с увеличением проиндексованных страниц в Google Search Console, (админы домена волнуются) показывает резкое увеличение проиндексированных страниц: Страница без ошибок--Страница проиндексирована, но ее нет в файле Sitemap -- 10 709 500 шт.

GoogleBot перебирает все варианты поиска.

Disallow: /*/simple-search - поможет?