You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(5) |
Sep
(39) |
Oct
(18) |
Nov
(16) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(15) |
Feb
(90) |
Mar
(41) |
Apr
(129) |
May
(69) |
Jun
(112) |
Jul
(153) |
Aug
(82) |
Sep
(95) |
Oct
(111) |
Nov
(39) |
Dec
(50) |
2009 |
Jan
(11) |
Feb
(63) |
Mar
(51) |
Apr
(45) |
May
(68) |
Jun
(84) |
Jul
(114) |
Aug
(149) |
Sep
(259) |
Oct
(179) |
Nov
(132) |
Dec
(87) |
2010 |
Jan
(59) |
Feb
(88) |
Mar
(145) |
Apr
(130) |
May
(24) |
Jun
(36) |
Jul
(143) |
Aug
(94) |
Sep
(125) |
Oct
(142) |
Nov
(100) |
Dec
(103) |
2011 |
Jan
(76) |
Feb
(105) |
Mar
(145) |
Apr
(112) |
May
(74) |
Jun
(157) |
Jul
(95) |
Aug
(191) |
Sep
(75) |
Oct
(91) |
Nov
(100) |
Dec
(102) |
2012 |
Jan
(100) |
Feb
(126) |
Mar
(97) |
Apr
(74) |
May
(161) |
Jun
(135) |
Jul
(161) |
Aug
(132) |
Sep
(266) |
Oct
(212) |
Nov
(114) |
Dec
(87) |
2013 |
Jan
(101) |
Feb
(254) |
Mar
(236) |
Apr
(244) |
May
(144) |
Jun
(156) |
Jul
(203) |
Aug
(242) |
Sep
(118) |
Oct
(206) |
Nov
(140) |
Dec
(108) |
2014 |
Jan
(141) |
Feb
(88) |
Mar
(167) |
Apr
(61) |
May
(109) |
Jun
(105) |
Jul
(218) |
Aug
(125) |
Sep
(152) |
Oct
(217) |
Nov
(129) |
Dec
(63) |
2015 |
Jan
(121) |
Feb
(78) |
Mar
(156) |
Apr
(92) |
May
(91) |
Jun
(118) |
Jul
(114) |
Aug
(236) |
Sep
(75) |
Oct
(112) |
Nov
(106) |
Dec
(74) |
2016 |
Jan
(121) |
Feb
(165) |
Mar
(127) |
Apr
(145) |
May
(142) |
Jun
(113) |
Jul
(66) |
Aug
(61) |
Sep
(46) |
Oct
(120) |
Nov
(59) |
Dec
(49) |
2017 |
Jan
(67) |
Feb
(55) |
Mar
(79) |
Apr
(28) |
May
(49) |
Jun
(50) |
Jul
(119) |
Aug
(72) |
Sep
(40) |
Oct
(45) |
Nov
(66) |
Dec
(60) |
2018 |
Jan
(63) |
Feb
(52) |
Mar
(48) |
Apr
(52) |
May
(60) |
Jun
(41) |
Jul
(78) |
Aug
(63) |
Sep
(46) |
Oct
(48) |
Nov
(17) |
Dec
(21) |
2019 |
Jan
(74) |
Feb
(78) |
Mar
(46) |
Apr
(42) |
May
(49) |
Jun
(15) |
Jul
(50) |
Aug
(16) |
Sep
(49) |
Oct
(63) |
Nov
(14) |
Dec
(11) |
2020 |
Jan
(36) |
Feb
(31) |
Mar
(36) |
Apr
(9) |
May
(92) |
Jun
(42) |
Jul
(29) |
Aug
(29) |
Sep
(66) |
Oct
(13) |
Nov
(29) |
Dec
(14) |
2021 |
Jan
(8) |
Feb
(34) |
Mar
(30) |
Apr
(14) |
May
(17) |
Jun
(28) |
Jul
(23) |
Aug
(25) |
Sep
(28) |
Oct
(32) |
Nov
(50) |
Dec
(19) |
2022 |
Jan
(25) |
Feb
(54) |
Mar
(44) |
Apr
(19) |
May
(11) |
Jun
(9) |
Jul
(17) |
Aug
(27) |
Sep
(33) |
Oct
(24) |
Nov
(37) |
Dec
(17) |
2023 |
Jan
(15) |
Feb
(21) |
Mar
(40) |
Apr
(16) |
May
(20) |
Jun
(117) |
Jul
(59) |
Aug
(18) |
Sep
(28) |
Oct
(13) |
Nov
(54) |
Dec
(20) |
2024 |
Jan
(24) |
Feb
(39) |
Mar
(20) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Demian K. <dem...@vi...> - 2024-03-18 14:24:27
|
Hugo, Did you try enclosing username and password in double quotes? If a special character is causing this issue, that should help. - Demian Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Hugo Agud Andreu <ha...@or...> Sent: Monday, March 18, 2024 4:19:34 AM To: vuf...@li... <vuf...@li...> Subject: [EXTERNAL] [VuFind-Tech] EDS.ini api Good morning We're configuring EDS into Vufid Service with name "EDS" could not be created. Reason: Error reading INI file "/usr/local/vufind/local/config/vufind/EDS.ini": syntax error, unexpected ')' in /usr/local/vufind/local/config/vufind/EDS.ini on line 247 Previous exceptions * Error reading INI file "/usr/local/vufind/local/config/vufind/EDS.ini": syntax error, unexpected ')' in /usr/local/vufind/local/config/vufind/EDS.ini on line 247 (2) The issue, I guess, is that username and password include ( and ) and it crashes the code... I guess we can change auth by uswername and password to ip, but do yo know if there is a workaround for it? thanks you i n advance Hugo Agud - Orex Digital www.orex.es<http://www.orex.es/> Linkedin<https://www.linkedin.com/company/orex-digital/> Innovando para ayudar a las bibliotecas a alcanzar el siguiente nivel<https://orex.es/productos/orex-analytics/> Rosa Leveroni 10 Oficina 2 - 08960 Sant Just Desvern - Tel: 932 435 179 ha...@or...<mailto:ha...@or...> · http://www.orex.es/ No imprima este mensaje a no ser que sea necesario. Una tonelada de papel implica la tala de 15 árboles y el consumo de 250.000 litros de agua. Aviso de confidencialidad Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su destinatario, pudiendo contener información confidencial sometida a secreto profesional. No está permitida su reproducción o distribución sin la autorización expresa de Orex Digital, S.L. Si usted no es el destinatario final por favor elimínelo e infórmenos por esta vía. En cumplimiento de lo establecido en el Reglamento General de Protección de Datos (RGPD) (UE) 2016/679 y a la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos de Carácter Personal y Garantía de los Derechos Digitales (LOPD-GDD), le informamos que tratamos sus datos personales con la finalidad de responder a su solicitud de información, realizar la gestión administrativa derivada de nuestra relación comercial o contractual, así como enviarle comunicaciones comerciales sobre nuestros productos y servicios. La legitimación será en base a un interés legítimo, por ejecución de un contrato y/o por consentimiento, en algunos casos. Los datos proporcionados se conservarán mientras se mantenga la relación contractual o durante los años necesarios para cumplir con las obligaciones legales. Los datos no se cederán a terceros salvo en los casos en que exista una obligación legal o sea necesario para la ejecución de un contrato. No se tomarán decisiones automatizadas que puedan causar un efecto jurídico significativo, salvo que se haya recabado previamente el consentimiento. Asimismo, le informamos de la posibilidad de ejercer los siguientes derechos sobre sus datos personales: derecho de acceso, rectificación, supresión u olvido, limitación, oposición, portabilidad y a retirar el consentimiento prestado. Para ello podrá enviar un email a: in...@or...<mailto:in...@or...>, adjuntando copia de su DNI. Además, el interesado puede dirigirse a la Autoridad de Control en materia de Protección de Datos competente (AEPD, en España) para obtener información adicional o presentar una reclamación. Datos identificativos: Orex Digital, S.L.U., B64500945, Rosa Leveroni 10, Oficina 2 - 08960 - Sant Just Desvern - BARCELONA, 932 435 179 |
From: Ere M. <ere...@he...> - 2024-03-18 12:38:11
|
I posted a pull request to fix the example. 🙂 https://github.com/vufind-org/vufind/pull/3524 Best, Ere On 18.3.2024 12.48, Hugo Agud Andreu wrote: > It worked! Thank you! sorry 🙁 > > > *Hugo Agud - Orex Digital * > > *www.orex.es <http://www.orex.es/>* > > *Linkedin <https://www.linkedin.com/company/orex-digital/>* > > *Innovando para ayudar a las bibliotecas a alcanzar el siguiente nivel > <https://orex.es/productos/orex-analytics/>* > > > > > Rosa Leveroni 10 Oficina 2 - 08960 Sant Just Desvern - Tel: 932 435 > 179 ha...@or... · http://www.orex.es/ > > No imprima este mensaje a no ser que sea necesario. Una tonelada de > papel implica la tala de 15 árboles y el consumo de 250.000 litros de > agua. > > Aviso de confidencialidad > > Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su > destinatario, pudiendo contener información confidencial sometida a > secreto profesional. No está permitida su reproducción o distribución > sin la autorización expresa de Orex Digital, S.L. Si usted no es el > destinatario final por favor elimínelo e infórmenos por esta vía. > > En cumplimiento de lo establecido en el Reglamento General de > Protección de Datos (RGPD) (UE) 2016/679 y a la Ley Orgánica 3/2018, > de 5 de diciembre, de Protección de Datos de Carácter Personal y > Garantía de los Derechos Digitales (LOPD-GDD), le informamos que > tratamos sus datos personales con la finalidad de _responder a su > solicitud de información, realizar la gestión administrativa derivada > de nuestra relación comercial o contractual, así como enviarle > comunicaciones comerciales sobre nuestros productos y servicios_. > > La legitimación será en base a un interés legítimo, por ejecución de > un contrato y/o por consentimiento, en algunos casos. Los datos > proporcionados se conservarán mientras se mantenga la relación > contractual o durante los años necesarios para cumplir con las > obligaciones legales. Los datos no se cederán a terceros salvo en los > casos en que exista una obligación legal o sea necesario para la > ejecución de un contrato. No se tomarán decisiones automatizadas que > puedan causar un efecto jurídico significativo, salvo que se haya > recabado previamente el consentimiento. > > Asimismo, le informamos de la posibilidad de ejercer los siguientes > derechos sobre sus datos personales: derecho de acceso, rectificación, > supresión u olvido, limitación, oposición, portabilidad y a retirar el > consentimiento prestado. Para ello podrá enviar un email a: > *in...@or...*, adjuntando copia de su DNI. > > Además, el interesado puede dirigirse a la Autoridad de Control en > materia de Protección de Datos competente (AEPD, en España) para > obtener información adicional o presentar una reclamación. > > Datos identificativos: > > Orex Digital, S.L.U., B64500945, Rosa Leveroni 10, Oficina 2 - 08960 - > Sant Just Desvern - BARCELONA, 932 435 179 > > ------------------------------------------------------------------------ > *De:* Demian Katz <dem...@vi...> > *Enviado:* lunes, 18 de marzo de 2024 10:52 > *Para:* Hugo Agud Andreu <ha...@or...>; > vuf...@li... <vuf...@li...> > *Asunto:* Re: [EXTERNAL] [VuFind-Tech] EDS.ini api > Hugo, > > Did you try enclosing usernameand password in double quotes? If a > special character is causing this issue, that should help. > > - Demian > > Sent from my Verizon, Samsung Galaxy smartphone > Get Outlook for Android <https://aka.ms/AAb9ysg> > ------------------------------------------------------------------------ > *From:* Hugo Agud Andreu <ha...@or...> > *Sent:* Monday, March 18, 2024 4:19:34 AM > *To:* vuf...@li... > <vuf...@li...> > *Subject:* [EXTERNAL] [VuFind-Tech] EDS.ini api > Good morning > > > We're configuring EDS into Vufid > > Service with name "EDS" could not be created. Reason: Error reading > INI file "/usr/local/vufind/local/config/vufind/EDS.ini": syntax > error, unexpected ')' in /usr/local/vufind/local/config/vufind/EDS.ini > on line 247 > Previous exceptions > > * Error reading INI file > "/usr/local/vufind/local/config/vufind/EDS.ini": syntax error, > unexpected ')' in /usr/local/vufind/local/config/vufind/EDS.ini on > line 247 (2) > > > The issue, I guess, is that username and password include ( and ) and > it crashes the code... I guess we can change auth by uswername and > password to ip, but do yo know if there is a workaround for it? > > thanks you i n advance > > *Hugo Agud - Orex Digital * > > *www.orex.es <http://www.orex.es/>* > > *Linkedin <https://www.linkedin.com/company/orex-digital/>* > > *Innovando para ayudar a las bibliotecas a alcanzar el siguiente nivel > <https://orex.es/productos/orex-analytics/>* > > > > > Rosa Leveroni 10 Oficina 2 - 08960 Sant Just Desvern - Tel: 932 435 > 179 ha...@or... · http://www.orex.es/ > > No imprima este mensaje a no ser que sea necesario. Una tonelada de > papel implica la tala de 15 árboles y el consumo de 250.000 litros de > agua. > > Aviso de confidencialidad > > Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su > destinatario, pudiendo contener información confidencial sometida a > secreto profesional. No está permitida su reproducción o distribución > sin la autorización expresa de Orex Digital, S.L. Si usted no es el > destinatario final por favor elimínelo e infórmenos por esta vía. > > En cumplimiento de lo establecido en el Reglamento General de > Protección de Datos (RGPD) (UE) 2016/679 y a la Ley Orgánica 3/2018, > de 5 de diciembre, de Protección de Datos de Carácter Personal y > Garantía de los Derechos Digitales (LOPD-GDD), le informamos que > tratamos sus datos personales con la finalidad de _responder a su > solicitud de información, realizar la gestión administrativa derivada > de nuestra relación comercial o contractual, así como enviarle > comunicaciones comerciales sobre nuestros productos y servicios_. > > La legitimación será en base a un interés legítimo, por ejecución de > un contrato y/o por consentimiento, en algunos casos. Los datos > proporcionados se conservarán mientras se mantenga la relación > contractual o durante los años necesarios para cumplir con las > obligaciones legales. Los datos no se cederán a terceros salvo en los > casos en que exista una obligación legal o sea necesario para la > ejecución de un contrato. No se tomarán decisiones automatizadas que > puedan causar un efecto jurídico significativo, salvo que se haya > recabado previamente el consentimiento. > > Asimismo, le informamos de la posibilidad de ejercer los siguientes > derechos sobre sus datos personales: derecho de acceso, rectificación, > supresión u olvido, limitación, oposición, portabilidad y a retirar el > consentimiento prestado. Para ello podrá enviar un email a: > *in...@or...*, adjuntando copia de su DNI. > > Además, el interesado puede dirigirse a la Autoridad de Control en > materia de Protección de Datos competente (AEPD, en España) para > obtener información adicional o presentar una reclamación. > > Datos identificativos: > > Orex Digital, S.L.U., B64500945, Rosa Leveroni 10, Oficina 2 - 08960 - > Sant Just Desvern - BARCELONA, 932 435 179 > > > > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech -- Ere Maijala Kansalliskirjasto / The National Library of Finland |
From: Hugo A. A. <ha...@or...> - 2024-03-18 11:02:45
|
It worked! Thank you! sorry 🙁 Hugo Agud - Orex Digital www.orex.es<http://www.orex.es/> Linkedin<https://www.linkedin.com/company/orex-digital/> Innovando para ayudar a las bibliotecas a alcanzar el siguiente nivel<https://orex.es/productos/orex-analytics/> Rosa Leveroni 10 Oficina 2 - 08960 Sant Just Desvern - Tel: 932 435 179 ha...@or...<mailto:ha...@or...> · http://www.orex.es/ No imprima este mensaje a no ser que sea necesario. Una tonelada de papel implica la tala de 15 árboles y el consumo de 250.000 litros de agua. Aviso de confidencialidad Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su destinatario, pudiendo contener información confidencial sometida a secreto profesional. No está permitida su reproducción o distribución sin la autorización expresa de Orex Digital, S.L. Si usted no es el destinatario final por favor elimínelo e infórmenos por esta vía. En cumplimiento de lo establecido en el Reglamento General de Protección de Datos (RGPD) (UE) 2016/679 y a la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos de Carácter Personal y Garantía de los Derechos Digitales (LOPD-GDD), le informamos que tratamos sus datos personales con la finalidad de responder a su solicitud de información, realizar la gestión administrativa derivada de nuestra relación comercial o contractual, así como enviarle comunicaciones comerciales sobre nuestros productos y servicios. La legitimación será en base a un interés legítimo, por ejecución de un contrato y/o por consentimiento, en algunos casos. Los datos proporcionados se conservarán mientras se mantenga la relación contractual o durante los años necesarios para cumplir con las obligaciones legales. Los datos no se cederán a terceros salvo en los casos en que exista una obligación legal o sea necesario para la ejecución de un contrato. No se tomarán decisiones automatizadas que puedan causar un efecto jurídico significativo, salvo que se haya recabado previamente el consentimiento. Asimismo, le informamos de la posibilidad de ejercer los siguientes derechos sobre sus datos personales: derecho de acceso, rectificación, supresión u olvido, limitación, oposición, portabilidad y a retirar el consentimiento prestado. Para ello podrá enviar un email a: in...@or...<mailto:in...@or...>, adjuntando copia de su DNI. Además, el interesado puede dirigirse a la Autoridad de Control en materia de Protección de Datos competente (AEPD, en España) para obtener información adicional o presentar una reclamación. Datos identificativos: Orex Digital, S.L.U., B64500945, Rosa Leveroni 10, Oficina 2 - 08960 - Sant Just Desvern - BARCELONA, 932 435 179 ________________________________ De: Demian Katz <dem...@vi...> Enviado: lunes, 18 de marzo de 2024 10:52 Para: Hugo Agud Andreu <ha...@or...>; vuf...@li... <vuf...@li...> Asunto: Re: [EXTERNAL] [VuFind-Tech] EDS.ini api Hugo, Did you try enclosing username and password in double quotes? If a special character is causing this issue, that should help. - Demian Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Hugo Agud Andreu <ha...@or...> Sent: Monday, March 18, 2024 4:19:34 AM To: vuf...@li... <vuf...@li...> Subject: [EXTERNAL] [VuFind-Tech] EDS.ini api Good morning We're configuring EDS into Vufid Service with name "EDS" could not be created. Reason: Error reading INI file "/usr/local/vufind/local/config/vufind/EDS.ini": syntax error, unexpected ')' in /usr/local/vufind/local/config/vufind/EDS.ini on line 247 Previous exceptions * Error reading INI file "/usr/local/vufind/local/config/vufind/EDS.ini": syntax error, unexpected ')' in /usr/local/vufind/local/config/vufind/EDS.ini on line 247 (2) The issue, I guess, is that username and password include ( and ) and it crashes the code... I guess we can change auth by uswername and password to ip, but do yo know if there is a workaround for it? thanks you i n advance Hugo Agud - Orex Digital www.orex.es<http://www.orex.es/> Linkedin<https://www.linkedin.com/company/orex-digital/> Innovando para ayudar a las bibliotecas a alcanzar el siguiente nivel<https://orex.es/productos/orex-analytics/> Rosa Leveroni 10 Oficina 2 - 08960 Sant Just Desvern - Tel: 932 435 179 ha...@or...<mailto:ha...@or...> · http://www.orex.es/ No imprima este mensaje a no ser que sea necesario. Una tonelada de papel implica la tala de 15 árboles y el consumo de 250.000 litros de agua. Aviso de confidencialidad Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su destinatario, pudiendo contener información confidencial sometida a secreto profesional. No está permitida su reproducción o distribución sin la autorización expresa de Orex Digital, S.L. Si usted no es el destinatario final por favor elimínelo e infórmenos por esta vía. En cumplimiento de lo establecido en el Reglamento General de Protección de Datos (RGPD) (UE) 2016/679 y a la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos de Carácter Personal y Garantía de los Derechos Digitales (LOPD-GDD), le informamos que tratamos sus datos personales con la finalidad de responder a su solicitud de información, realizar la gestión administrativa derivada de nuestra relación comercial o contractual, así como enviarle comunicaciones comerciales sobre nuestros productos y servicios. La legitimación será en base a un interés legítimo, por ejecución de un contrato y/o por consentimiento, en algunos casos. Los datos proporcionados se conservarán mientras se mantenga la relación contractual o durante los años necesarios para cumplir con las obligaciones legales. Los datos no se cederán a terceros salvo en los casos en que exista una obligación legal o sea necesario para la ejecución de un contrato. No se tomarán decisiones automatizadas que puedan causar un efecto jurídico significativo, salvo que se haya recabado previamente el consentimiento. Asimismo, le informamos de la posibilidad de ejercer los siguientes derechos sobre sus datos personales: derecho de acceso, rectificación, supresión u olvido, limitación, oposición, portabilidad y a retirar el consentimiento prestado. Para ello podrá enviar un email a: in...@or...<mailto:in...@or...>, adjuntando copia de su DNI. Además, el interesado puede dirigirse a la Autoridad de Control en materia de Protección de Datos competente (AEPD, en España) para obtener información adicional o presentar una reclamación. Datos identificativos: Orex Digital, S.L.U., B64500945, Rosa Leveroni 10, Oficina 2 - 08960 - Sant Just Desvern - BARCELONA, 932 435 179 |
From: Ahrens, H. <Hel...@ul...> - 2024-03-18 09:32:15
|
Dear Hugo, A bracket in the password should not cause any problems if the password is enclosed in quotation marks. That should work: password = "abcDEF123()" Maybe somewhere else before the password are quotation marks missing? Best wishes Helge Von: Hugo Agud Andreu <ha...@or...> Gesendet: Montag, 18. März 2024 09:20 An: vuf...@li... Betreff: [VuFind-Tech] EDS.ini api Good morning We're configuring EDS into Vufid Service with name "EDS" could not be created. Reason: Error reading INI file "/usr/local/vufind/local/config/vufind/EDS.ini": syntax error, unexpected ')' in /usr/local/vufind/local/config/vufind/EDS.ini on line 247 Previous exceptions * Error reading INI file "/usr/local/vufind/local/config/vufind/EDS.ini": syntax error, unexpected ')' in /usr/local/vufind/local/config/vufind/EDS.ini on line 247 (2) The issue, I guess, is that username and password include ( and ) and it crashes the code... I guess we can change auth by uswername and password to ip, but do yo know if there is a workaround for it? thanks you i n advance Hugo Agud - Orex Digital www.orex.es <http://www.orex.es/> Linkedin <https://www.linkedin.com/company/orex-digital/> Innovando para ayudar a las bibliotecas a alcanzar el siguiente nivel <https://orex.es/productos/orex-analytics/> Rosa Leveroni 10 Oficina 2 - 08960 Sant Just Desvern - Tel: 932 435 179 ha...@or... <mailto:ha...@or...> · http://www.orex.es/ No imprima este mensaje a no ser que sea necesario. Una tonelada de papel implica la tala de 15 árboles y el consumo de 250.000 litros de agua. Aviso de confidencialidad Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su destinatario, pudiendo contener información confidencial sometida a secreto profesional. No está permitida su reproducción o distribución sin la autorización expresa de Orex Digital, S.L. Si usted no es el destinatario final por favor elimínelo e infórmenos por esta vía. En cumplimiento de lo establecido en el Reglamento General de Protección de Datos (RGPD) (UE) 2016/679 y a la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos de Carácter Personal y Garantía de los Derechos Digitales (LOPD-GDD), le informamos que tratamos sus datos personales con la finalidad de responder a su solicitud de información, realizar la gestión administrativa derivada de nuestra relación comercial o contractual, así como enviarle comunicaciones comerciales sobre nuestros productos y servicios. La legitimación será en base a un interés legítimo, por ejecución de un contrato y/o por consentimiento, en algunos casos. Los datos proporcionados se conservarán mientras se mantenga la relación contractual o durante los años necesarios para cumplir con las obligaciones legales. Los datos no se cederán a terceros salvo en los casos en que exista una obligación legal o sea necesario para la ejecución de un contrato. No se tomarán decisiones automatizadas que puedan causar un efecto jurídico significativo, salvo que se haya recabado previamente el consentimiento. Asimismo, le informamos de la posibilidad de ejercer los siguientes derechos sobre sus datos personales: derecho de acceso, rectificación, supresión u olvido, limitación, oposición, portabilidad y a retirar el consentimiento prestado. Para ello podrá enviar un email a: in...@or... <mailto:in...@or...> , adjuntando copia de su DNI. Además, el interesado puede dirigirse a la Autoridad de Control en materia de Protección de Datos competente (AEPD, en España) para obtener información adicional o presentar una reclamación. Datos identificativos: Orex Digital, S.L.U., B64500945, Rosa Leveroni 10, Oficina 2 - 08960 - Sant Just Desvern - BARCELONA, 932 435 179 |
From: Thomas W. <wa...@he...> - 2024-03-18 09:26:28
|
Hello Hugo, my guess is that if you put the username and password in quotation marks the error should be fixed. Cheers Thomas Am 18.03.24 um 09:19 schrieb Hugo Agud Andreu: > Good morning > > > We're configuring EDS into Vufid > > Service with name "EDS" could not be created. Reason: Error reading > INI file "/usr/local/vufind/local/config/vufind/EDS.ini": syntax > error, unexpected ')' in /usr/local/vufind/local/config/vufind/EDS.ini > on line 247 > Previous exceptions > > * Error reading INI file > "/usr/local/vufind/local/config/vufind/EDS.ini": syntax error, > unexpected ')' in /usr/local/vufind/local/config/vufind/EDS.ini on > line 247 (2) > > > The issue, I guess, is that username and password include ( and ) and > it crashes the code... I guess we can change auth by uswername and > password to ip, but do yo know if there is a workaround for it? > > thanks you i n advance > > *Hugo Agud - Orex Digital * > > *www.orex.es <http://www.orex.es/>* > > *Linkedin <https://www.linkedin.com/company/orex-digital/>* > > *Innovando para ayudar a las bibliotecas a alcanzar el siguiente nivel > <https://orex.es/productos/orex-analytics/>* > > > > > Rosa Leveroni 10 Oficina 2 - 08960 Sant Just Desvern - Tel: 932 435 > 179 ha...@or... · http://www.orex.es/ > > No imprima este mensaje a no ser que sea necesario. Una tonelada de > papel implica la tala de 15 árboles y el consumo de 250.000 litros de > agua. > > Aviso de confidencialidad > > Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su > destinatario, pudiendo contener información confidencial sometida a > secreto profesional. No está permitida su reproducción o distribución > sin la autorización expresa de Orex Digital, S.L. Si usted no es el > destinatario final por favor elimínelo e infórmenos por esta vía. > > En cumplimiento de lo establecido en el Reglamento General de > Protección de Datos (RGPD) (UE) 2016/679 y a la Ley Orgánica 3/2018, > de 5 de diciembre, de Protección de Datos de Carácter Personal y > Garantía de los Derechos Digitales (LOPD-GDD), le informamos que > tratamos sus datos personales con la finalidad de _responder a su > solicitud de información, realizar la gestión administrativa derivada > de nuestra relación comercial o contractual, así como enviarle > comunicaciones comerciales sobre nuestros productos y servicios_. > > La legitimación será en base a un interés legítimo, por ejecución de > un contrato y/o por consentimiento, en algunos casos. Los datos > proporcionados se conservarán mientras se mantenga la relación > contractual o durante los años necesarios para cumplir con las > obligaciones legales. Los datos no se cederán a terceros salvo en los > casos en que exista una obligación legal o sea necesario para la > ejecución de un contrato. No se tomarán decisiones automatizadas que > puedan causar un efecto jurídico significativo, salvo que se haya > recabado previamente el consentimiento. > > Asimismo, le informamos de la posibilidad de ejercer los siguientes > derechos sobre sus datos personales: derecho de acceso, rectificación, > supresión u olvido, limitación, oposición, portabilidad y a retirar el > consentimiento prestado. Para ello podrá enviar un email a: > *in...@or...*, adjuntando copia de su DNI. > > Además, el interesado puede dirigirse a la Autoridad de Control en > materia de Protección de Datos competente (AEPD, en España) para > obtener información adicional o presentar una reclamación. > > Datos identificativos: > > Orex Digital, S.L.U., B64500945, Rosa Leveroni 10, Oficina 2 - 08960 - > Sant Just Desvern - BARCELONA, 932 435 179 > > > > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech -- Thomas Wagener hebis Verbundzentrale Vermittlungs- und Recherchelösungen https://www.hebis.de |
From: Hugo A. A. <ha...@or...> - 2024-03-18 08:53:49
|
Good morning We're configuring EDS into Vufid Service with name "EDS" could not be created. Reason: Error reading INI file "/usr/local/vufind/local/config/vufind/EDS.ini": syntax error, unexpected ')' in /usr/local/vufind/local/config/vufind/EDS.ini on line 247 Previous exceptions * Error reading INI file "/usr/local/vufind/local/config/vufind/EDS.ini": syntax error, unexpected ')' in /usr/local/vufind/local/config/vufind/EDS.ini on line 247 (2) The issue, I guess, is that username and password include ( and ) and it crashes the code... I guess we can change auth by uswername and password to ip, but do yo know if there is a workaround for it? thanks you i n advance Hugo Agud - Orex Digital www.orex.es<http://www.orex.es/> Linkedin<https://www.linkedin.com/company/orex-digital/> Innovando para ayudar a las bibliotecas a alcanzar el siguiente nivel<https://orex.es/productos/orex-analytics/> Rosa Leveroni 10 Oficina 2 - 08960 Sant Just Desvern - Tel: 932 435 179 ha...@or...<mailto:ha...@or...> · http://www.orex.es/ No imprima este mensaje a no ser que sea necesario. Una tonelada de papel implica la tala de 15 árboles y el consumo de 250.000 litros de agua. Aviso de confidencialidad Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su destinatario, pudiendo contener información confidencial sometida a secreto profesional. No está permitida su reproducción o distribución sin la autorización expresa de Orex Digital, S.L. Si usted no es el destinatario final por favor elimínelo e infórmenos por esta vía. En cumplimiento de lo establecido en el Reglamento General de Protección de Datos (RGPD) (UE) 2016/679 y a la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos de Carácter Personal y Garantía de los Derechos Digitales (LOPD-GDD), le informamos que tratamos sus datos personales con la finalidad de responder a su solicitud de información, realizar la gestión administrativa derivada de nuestra relación comercial o contractual, así como enviarle comunicaciones comerciales sobre nuestros productos y servicios. La legitimación será en base a un interés legítimo, por ejecución de un contrato y/o por consentimiento, en algunos casos. Los datos proporcionados se conservarán mientras se mantenga la relación contractual o durante los años necesarios para cumplir con las obligaciones legales. Los datos no se cederán a terceros salvo en los casos en que exista una obligación legal o sea necesario para la ejecución de un contrato. No se tomarán decisiones automatizadas que puedan causar un efecto jurídico significativo, salvo que se haya recabado previamente el consentimiento. Asimismo, le informamos de la posibilidad de ejercer los siguientes derechos sobre sus datos personales: derecho de acceso, rectificación, supresión u olvido, limitación, oposición, portabilidad y a retirar el consentimiento prestado. Para ello podrá enviar un email a: in...@or...<mailto:in...@or...>, adjuntando copia de su DNI. Además, el interesado puede dirigirse a la Autoridad de Control en materia de Protección de Datos competente (AEPD, en España) para obtener información adicional o presentar una reclamación. Datos identificativos: Orex Digital, S.L.U., B64500945, Rosa Leveroni 10, Oficina 2 - 08960 - Sant Just Desvern - BARCELONA, 932 435 179 |
From: Alex B. <ale...@ca...> - 2024-03-14 19:54:21
|
Thank you very much Ere and Demian! We will have a think on our end, and with our partner library,and potentially add feedback to the JIRA ticket. Appreciate your help with this. On 12/03/24 01:43, Ere Maijala wrote: > > Maybe a JIRA ticket for further discussion, yes. > > It's not easy to get the summary without proper support from the ILS. > Otherwise we'd have to do the same thing multiple times. And even then > the ILS could end up doing more work than it would have previously. > > > Paging with just the items like today could be done if the ILS can > return a subset of items sorted in order suitable for the configured > grouping. Then the only problem would be that the last group might be > incomplete. Though even this becomes complicated if you have something > like we do where the order can be customized so that e.g. the main > library is always the first. Oh, and of course there's translation > which messes up alphabetical sorting.. > > > --Ere > > > On 11.3.2024 14.03, Demian Katz wrote: >> Ere, >> >> This may be worth tackling eventually, but I agree that it's very >> complicated. It might be useful to redesign the mechanism so that >> fetching holdings and fetching items are two separate calls – then we >> could summarize the holdings quickly and load the items with AJAX. >> But even that is not straightforward, and it would require >> significant thought to be sure we covered all the possible use cases >> and situations. Maybe worth a JIRA ticket so we have a place to begin >> collecting thoughts... >> >> - Demian >> ------------------------------------------------------------------------ >> *From:* Ere Maijala <ere...@he...> >> *Sent:* Monday, March 11, 2024 6:39 AM >> *To:* Demian Katz <dem...@vi...>; >> vuf...@li... <vuf...@li...> >> *Subject:* Re: [EXTERNAL] Re: [VuFind-Tech] Gateway timeout from >> viewing bibliographic record with large number of item records >> >> I thought about it too, but it's indeed a huge pain. We do holdings >> paging in particular cases, but I'd try to avoid it here. >> >> --Ere >> >> On 11.3.2024 11.48, Demian Katz wrote: >>> The only other option, which could be useful but complicated, would >>> be to design a general holdings pagination mechanism... but due to >>> the way data gets grouped and processed, this would not be >>> straightforward. >>> >>> - Demian >>> >>> Sent from my Verizon, Samsung Galaxy smartphone >>> Get Outlook for Android <https://aka.ms/AAb9ysg> >>> ------------------------------------------------------------------------ >>> *From:* Ere Maijala <ere...@he...> >>> <mailto:ere...@he...> >>> *Sent:* Monday, March 11, 2024 5:36:40 AM >>> *To:* vuf...@li... >>> <mailto:vuf...@li...> >>> <vuf...@li...> >>> <mailto:vuf...@li...> >>> *Subject:* [EXTERNAL] Re: [VuFind-Tech] Gateway timeout from viewing >>> bibliographic record with large number of item records >>> >>> Hi, >>> >>> In VuFind it's basicly a single API call (plus another one to fetch >>> names of libraries if not already cached), so not much that could be >>> optimized there. >>> >>> Perhaps VuFind could indicate the priority order of different item >>> statuses, which would allow the Koha plugin to do the checks in the >>> requested order and only return the first status, which would avoid >>> calculation of unnecessary status information, but that still >>> requires the Koha plugin to do most of the work. That's the way I >>> intend pursue, anyway, at some point. >>> >>> I would have expected the statuses for 200-300 items to be returned >>> quicker than the timeout, so I believe that adding RAM as you >>> mentioned could be the key to improve performance by letting more of >>> the database be cached in memory. Increasing e.g. InnoDB buffer pool >>> size in MySQL could also help. >>> >>> --Ere >>> >>> On 10.3.2024 22.30, Alex Buckley via Vufind-tech wrote: >>>> >>>> Hi Ere, >>>> >>>> Thanks for your response. >>>> >>>> A large number of items in this case, would be 200-300 items. We >>>> are indeed using the KohaRest driver. >>>> >>>> Thanks for your suggestions. I'll try the following and see if that >>>> helps improve the situation: >>>> >>>> * Turning on the loadInitialTabWithAjax in config.ini. >>>> * Adding http_timeout = 60 from the Catalog section of KohaRest.ini >>>> >>>> Do you see there is room for some performance improvement in the >>>> KohaRest driver as well as the Koha DI plugin? >>>> >>>> Kind regards, >>>> >>>> Alex >>>> >>>> >>>> On 9/03/24 00:39, Ere Maijala wrote: >>>>> >>>>> Hi, >>>>> >>>>> How much is a large number of items? For comparison typical >>>>> performance I've seen is ~60 items per second, so a fairly high >>>>> number of items, like 800, takes some 13 seconds. >>>>> >>>>> But first of all I'd suggest turning on the loadInitialTabWithAjax >>>>> setting in VuFind's config.ini. This will ensure the main page >>>>> loads quickly even if the Holdings tab is slow. >>>>> >>>>> If you're using KohaRest driver with Vufind, you can try to >>>>> increase the timeout by adding something like this to Catalog >>>>> section of KohaRest.ini in VuFind: >>>>> >>>>> http_timeout = 60 >>>>> >>>>> Regardless of whether that helps, it's obviously not a very fluid >>>>> service if you have to wait an eternity for holdings information. >>>>> I think there could be room for some performance improvement in >>>>> the Koha DI plugin in some cases where we only need the most >>>>> important status information and don't need to know everything >>>>> about the items. Unfortunately I don't currently have much >>>>> bandwidth to pursue this further, but it would be interesting to >>>>> profile the availability calculation in the DI plugin a bit to see >>>>> if there's a particularly heavy operation that we could avoid in >>>>> some cases. >>>>> >>>>> Best, >>>>> >>>>> Ere >>>>> >>>>> On 8.3.2024 10.57, Alex Buckley via Vufind-tech wrote: >>>>>> >>>>>> Hi VuFind community, >>>>>> >>>>>> We have a partner library (using VuFind integrated with Koha) >>>>>> with approximately 40 print journal bibliographic records with a >>>>>> large number of item records attached. >>>>>> >>>>>> They find that when they view these journal bibliographic records >>>>>> they encounter a gateway timeout - see attached screenshot. Here >>>>>> are some more details about this timeout: >>>>>> >>>>>> * This gateway timeout happens on multiple environments - dev, >>>>>> staging and prod. So ruled out as environment specific. >>>>>> * The gateway timeout does not happen for biblios with a >>>>>> smaller number of linked items. >>>>>> * Our partner library encounters these gateway timeouts >>>>>> everytime they try to load the journal biblios - when we >>>>>> (Catalyst staff) try to access those records the timeout is >>>>>> intermittent. >>>>>> >>>>>> Has anyone else encountered this problem when viewing biblio >>>>>> records with a large number of attached items (holdings)? If so, >>>>>> how did you fix this issue. >>>>>> >>>>>> When we encounter such issues in the Koha LMS we usually >>>>>> recommend the server RAM specs be increased - to handle the >>>>>> additional processing . However, we would really appreciate any >>>>>> assistance or suggestions from others in the community! >>>>>> >>>>>> Thanks very much in advance, >>>>>> >>>>>> Alex >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Vufind-tech mailing list >>>>>> Vuf...@li... <mailto:Vuf...@li...> >>>>>> https://lists.sourceforge.net/lists/listinfo/vufind-tech <https://lists.sourceforge.net/lists/listinfo/vufind-tech> >>>>> -- >>>>> Ere Maijala >>>>> Kansalliskirjasto / The National Library of Finland >>>>> >>>>> >>>>> _______________________________________________ >>>>> Vufind-tech mailing list >>>>> Vuf...@li... <mailto:Vuf...@li...> >>>>> https://lists.sourceforge.net/lists/listinfo/vufind-tech <https://lists.sourceforge.net/lists/listinfo/vufind-tech> >>>> -- >>>> *Alex Buckley (he/him)* >>>> Koha Developer | Implementation Lead >>>> *Catalyst.Net Limited - Expert Open Source Solutions* >>>> >>>> *Catalyst.Net Limited - a Catalyst IT group company* >>>> www.catalyst.net.nz <http://www.catalyst.net.nz/> >>>> >>>> Follow Catalyst Koha on Twitter <https://twitter.com/catalystkoha> >>>> | Subscribe to the Catalyst Koha newsletter >>>> <https://catalyst.us4.list-manage.com/subscribe?u=62457ff5060d15ee3c07d3fc4&id=b73fbdcac8> >>>> >>>> Catalyst Logo >>>> >>>> CONFIDENTIALITY NOTICE: This email is intended for the named >>>> recipients only. It may contain privileged, confidential or >>>> copyright information. If you are not the named recipient, any use, >>>> reliance upon, disclosure or copying of this email or its >>>> attachments is unauthorised. If you have received this email in >>>> error, please reply via email or call +64 4 499 2267. >>>> >>>> >>>> _______________________________________________ >>>> Vufind-tech mailing list >>>> Vuf...@li... <mailto:Vuf...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/vufind-tech <https://lists.sourceforge.net/lists/listinfo/vufind-tech> >>> -- >>> Ere Maijala >>> Kansalliskirjasto / The National Library of Finland >> -- >> Ere Maijala >> Kansalliskirjasto / The National Library of Finland > -- > Ere Maijala > Kansalliskirjasto / The National Library of Finland > > > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech -- *Alex Buckley (he/him)* Koha Developer | Implementation Lead *Catalyst.Net Limited - Expert Open Source Solutions* *Catalyst.Net Limited - a Catalyst IT group company* www.catalyst.net.nz <http://www.catalyst.net.nz> Follow Catalyst Koha on Twitter <https://twitter.com/catalystkoha> | Subscribe to the Catalyst Koha newsletter <https://catalyst.us4.list-manage.com/subscribe?u=62457ff5060d15ee3c07d3fc4&id=b73fbdcac8> Catalyst Logo CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267. |
From: Demian K. <dem...@vi...> - 2024-03-11 13:01:30
|
Agreed! There is probably no perfect solution to this problem, but maybe we can at least offer a couple of different compromises for people to choose from in the long term. 😊 - Demian From: Ere Maijala <ere...@he...> Sent: Monday, March 11, 2024 8:44 AM To: Demian Katz <dem...@vi...>; vuf...@li... Subject: Re: [EXTERNAL] Re: [VuFind-Tech] Gateway timeout from viewing bibliographic record with large number of item records Maybe a JIRA ticket for further discussion, yes. It's not easy to get the summary without proper support from the ILS. Otherwise we'd have to do the same thing multiple times. And even then the ILS could end up doing more work than it would have previously. Paging with just the items like today could be done if the ILS can return a subset of items sorted in order suitable for the configured grouping. Then the only problem would be that the last group might be incomplete. Though even this becomes complicated if you have something like we do where the order can be customized so that e.g. the main library is always the first. Oh, and of course there's translation which messes up alphabetical sorting.. --Ere On 11.3.2024 14.03, Demian Katz wrote: Ere, This may be worth tackling eventually, but I agree that it's very complicated. It might be useful to redesign the mechanism so that fetching holdings and fetching items are two separate calls – then we could summarize the holdings quickly and load the items with AJAX. But even that is not straightforward, and it would require significant thought to be sure we covered all the possible use cases and situations. Maybe worth a JIRA ticket so we have a place to begin collecting thoughts... - Demian ________________________________ From: Ere Maijala <ere...@he...><mailto:ere...@he...> Sent: Monday, March 11, 2024 6:39 AM To: Demian Katz <dem...@vi...><mailto:dem...@vi...>; vuf...@li...<mailto:vuf...@li...> <vuf...@li...><mailto:vuf...@li...> Subject: Re: [EXTERNAL] Re: [VuFind-Tech] Gateway timeout from viewing bibliographic record with large number of item records I thought about it too, but it's indeed a huge pain. We do holdings paging in particular cases, but I'd try to avoid it here. --Ere On 11.3.2024 11.48, Demian Katz wrote: The only other option, which could be useful but complicated, would be to design a general holdings pagination mechanism... but due to the way data gets grouped and processed, this would not be straightforward. - Demian Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Ere Maijala <ere...@he...><mailto:ere...@he...> Sent: Monday, March 11, 2024 5:36:40 AM To: vuf...@li...<mailto:vuf...@li...> <vuf...@li...><mailto:vuf...@li...> Subject: [EXTERNAL] Re: [VuFind-Tech] Gateway timeout from viewing bibliographic record with large number of item records Hi, In VuFind it's basicly a single API call (plus another one to fetch names of libraries if not already cached), so not much that could be optimized there. Perhaps VuFind could indicate the priority order of different item statuses, which would allow the Koha plugin to do the checks in the requested order and only return the first status, which would avoid calculation of unnecessary status information, but that still requires the Koha plugin to do most of the work. That's the way I intend pursue, anyway, at some point. I would have expected the statuses for 200-300 items to be returned quicker than the timeout, so I believe that adding RAM as you mentioned could be the key to improve performance by letting more of the database be cached in memory. Increasing e.g. InnoDB buffer pool size in MySQL could also help. --Ere On 10.3.2024 22.30, Alex Buckley via Vufind-tech wrote: Hi Ere, Thanks for your response. A large number of items in this case, would be 200-300 items. We are indeed using the KohaRest driver. Thanks for your suggestions. I'll try the following and see if that helps improve the situation: * Turning on the loadInitialTabWithAjax in config.ini. * Adding http_timeout = 60 from the Catalog section of KohaRest.ini Do you see there is room for some performance improvement in the KohaRest driver as well as the Koha DI plugin? Kind regards, Alex On 9/03/24 00:39, Ere Maijala wrote: Hi, How much is a large number of items? For comparison typical performance I've seen is ~60 items per second, so a fairly high number of items, like 800, takes some 13 seconds. But first of all I'd suggest turning on the loadInitialTabWithAjax setting in VuFind's config.ini. This will ensure the main page loads quickly even if the Holdings tab is slow. If you're using KohaRest driver with Vufind, you can try to increase the timeout by adding something like this to Catalog section of KohaRest.ini in VuFind: http_timeout = 60 Regardless of whether that helps, it's obviously not a very fluid service if you have to wait an eternity for holdings information. I think there could be room for some performance improvement in the Koha DI plugin in some cases where we only need the most important status information and don't need to know everything about the items. Unfortunately I don't currently have much bandwidth to pursue this further, but it would be interesting to profile the availability calculation in the DI plugin a bit to see if there's a particularly heavy operation that we could avoid in some cases. Best, Ere On 8.3.2024 10.57, Alex Buckley via Vufind-tech wrote: Hi VuFind community, We have a partner library (using VuFind integrated with Koha) with approximately 40 print journal bibliographic records with a large number of item records attached. They find that when they view these journal bibliographic records they encounter a gateway timeout - see attached screenshot. Here are some more details about this timeout: * This gateway timeout happens on multiple environments - dev, staging and prod. So ruled out as environment specific. * The gateway timeout does not happen for biblios with a smaller number of linked items. * Our partner library encounters these gateway timeouts everytime they try to load the journal biblios - when we (Catalyst staff) try to access those records the timeout is intermittent. Has anyone else encountered this problem when viewing biblio records with a large number of attached items (holdings)? If so, how did you fix this issue. When we encounter such issues in the Koha LMS we usually recommend the server RAM specs be increased - to handle the additional processing . However, we would really appreciate any assistance or suggestions from others in the community! Thanks very much in advance, Alex _______________________________________________ Vufind-tech mailing list Vuf...@li...<mailto:Vuf...@li...> https://lists.sourceforge.net/lists/listinfo/vufind-tech -- Ere Maijala Kansalliskirjasto / The National Library of Finland _______________________________________________ Vufind-tech mailing list Vuf...@li...<mailto:Vuf...@li...> https://lists.sourceforge.net/lists/listinfo/vufind-tech -- Alex Buckley (he/him) Koha Developer | Implementation Lead Catalyst.Net Limited - Expert Open Source Solutions Catalyst.Net Limited - a Catalyst IT group company www.catalyst.net.nz<http://www.catalyst.net.nz/> Follow Catalyst Koha on Twitter<https://twitter.com/catalystkoha> | Subscribe to the Catalyst Koha newsletter<https://catalyst.us4.list-manage.com/subscribe?u=62457ff5060d15ee3c07d3fc4&id=b73fbdcac8> [Catalyst Logo] CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267. _______________________________________________ Vufind-tech mailing list Vuf...@li...<mailto:Vuf...@li...> https://lists.sourceforge.net/lists/listinfo/vufind-tech -- Ere Maijala Kansalliskirjasto / The National Library of Finland -- Ere Maijala Kansalliskirjasto / The National Library of Finland -- Ere Maijala Kansalliskirjasto / The National Library of Finland |
From: Ere M. <ere...@he...> - 2024-03-11 12:44:11
|
Maybe a JIRA ticket for further discussion, yes. It's not easy to get the summary without proper support from the ILS. Otherwise we'd have to do the same thing multiple times. And even then the ILS could end up doing more work than it would have previously. Paging with just the items like today could be done if the ILS can return a subset of items sorted in order suitable for the configured grouping. Then the only problem would be that the last group might be incomplete. Though even this becomes complicated if you have something like we do where the order can be customized so that e.g. the main library is always the first. Oh, and of course there's translation which messes up alphabetical sorting.. --Ere On 11.3.2024 14.03, Demian Katz wrote: > Ere, > > This may be worth tackling eventually, but I agree that it's very > complicated. It might be useful to redesign the mechanism so that > fetching holdings and fetching items are two separate calls – then we > could summarize the holdings quickly and load the items with AJAX. But > even that is not straightforward, and it would require significant > thought to be sure we covered all the possible use cases and > situations. Maybe worth a JIRA ticket so we have a place to begin > collecting thoughts... > > - Demian > ------------------------------------------------------------------------ > *From:* Ere Maijala <ere...@he...> > *Sent:* Monday, March 11, 2024 6:39 AM > *To:* Demian Katz <dem...@vi...>; > vuf...@li... <vuf...@li...> > *Subject:* Re: [EXTERNAL] Re: [VuFind-Tech] Gateway timeout from > viewing bibliographic record with large number of item records > > I thought about it too, but it's indeed a huge pain. We do holdings > paging in particular cases, but I'd try to avoid it here. > > --Ere > > On 11.3.2024 11.48, Demian Katz wrote: >> The only other option, which could be useful but complicated, would >> be to design a general holdings pagination mechanism... but due to >> the way data gets grouped and processed, this would not be >> straightforward. >> >> - Demian >> >> Sent from my Verizon, Samsung Galaxy smartphone >> Get Outlook for Android <https://aka.ms/AAb9ysg> >> ------------------------------------------------------------------------ >> *From:* Ere Maijala <ere...@he...> >> <mailto:ere...@he...> >> *Sent:* Monday, March 11, 2024 5:36:40 AM >> *To:* vuf...@li... >> <mailto:vuf...@li...> >> <vuf...@li...> >> <mailto:vuf...@li...> >> *Subject:* [EXTERNAL] Re: [VuFind-Tech] Gateway timeout from viewing >> bibliographic record with large number of item records >> >> Hi, >> >> In VuFind it's basicly a single API call (plus another one to fetch >> names of libraries if not already cached), so not much that could be >> optimized there. >> >> Perhaps VuFind could indicate the priority order of different item >> statuses, which would allow the Koha plugin to do the checks in the >> requested order and only return the first status, which would avoid >> calculation of unnecessary status information, but that still >> requires the Koha plugin to do most of the work. That's the way I >> intend pursue, anyway, at some point. >> >> I would have expected the statuses for 200-300 items to be returned >> quicker than the timeout, so I believe that adding RAM as you >> mentioned could be the key to improve performance by letting more of >> the database be cached in memory. Increasing e.g. InnoDB buffer pool >> size in MySQL could also help. >> >> --Ere >> >> On 10.3.2024 22.30, Alex Buckley via Vufind-tech wrote: >>> >>> Hi Ere, >>> >>> Thanks for your response. >>> >>> A large number of items in this case, would be 200-300 items. We are >>> indeed using the KohaRest driver. >>> >>> Thanks for your suggestions. I'll try the following and see if that >>> helps improve the situation: >>> >>> * Turning on the loadInitialTabWithAjax in config.ini. >>> * Adding http_timeout = 60 from the Catalog section of KohaRest.ini >>> >>> Do you see there is room for some performance improvement in the >>> KohaRest driver as well as the Koha DI plugin? >>> >>> Kind regards, >>> >>> Alex >>> >>> >>> On 9/03/24 00:39, Ere Maijala wrote: >>>> >>>> Hi, >>>> >>>> How much is a large number of items? For comparison typical >>>> performance I've seen is ~60 items per second, so a fairly high >>>> number of items, like 800, takes some 13 seconds. >>>> >>>> But first of all I'd suggest turning on the loadInitialTabWithAjax >>>> setting in VuFind's config.ini. This will ensure the main page >>>> loads quickly even if the Holdings tab is slow. >>>> >>>> If you're using KohaRest driver with Vufind, you can try to >>>> increase the timeout by adding something like this to Catalog >>>> section of KohaRest.ini in VuFind: >>>> >>>> http_timeout = 60 >>>> >>>> Regardless of whether that helps, it's obviously not a very fluid >>>> service if you have to wait an eternity for holdings information. I >>>> think there could be room for some performance improvement in the >>>> Koha DI plugin in some cases where we only need the most important >>>> status information and don't need to know everything about the >>>> items. Unfortunately I don't currently have much bandwidth to >>>> pursue this further, but it would be interesting to profile the >>>> availability calculation in the DI plugin a bit to see if there's a >>>> particularly heavy operation that we could avoid in some cases. >>>> >>>> Best, >>>> >>>> Ere >>>> >>>> On 8.3.2024 10.57, Alex Buckley via Vufind-tech wrote: >>>>> >>>>> Hi VuFind community, >>>>> >>>>> We have a partner library (using VuFind integrated with Koha) with >>>>> approximately 40 print journal bibliographic records with a large >>>>> number of item records attached. >>>>> >>>>> They find that when they view these journal bibliographic records >>>>> they encounter a gateway timeout - see attached screenshot. Here >>>>> are some more details about this timeout: >>>>> >>>>> * This gateway timeout happens on multiple environments - dev, >>>>> staging and prod. So ruled out as environment specific. >>>>> * The gateway timeout does not happen for biblios with a smaller >>>>> number of linked items. >>>>> * Our partner library encounters these gateway timeouts >>>>> everytime they try to load the journal biblios - when we >>>>> (Catalyst staff) try to access those records the timeout is >>>>> intermittent. >>>>> >>>>> Has anyone else encountered this problem when viewing biblio >>>>> records with a large number of attached items (holdings)? If so, >>>>> how did you fix this issue. >>>>> >>>>> When we encounter such issues in the Koha LMS we usually recommend >>>>> the server RAM specs be increased - to handle the additional >>>>> processing . However, we would really appreciate any assistance or >>>>> suggestions from others in the community! >>>>> >>>>> Thanks very much in advance, >>>>> >>>>> Alex >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Vufind-tech mailing list >>>>> Vuf...@li... <mailto:Vuf...@li...> >>>>> https://lists.sourceforge.net/lists/listinfo/vufind-tech <https://lists.sourceforge.net/lists/listinfo/vufind-tech> >>>> -- >>>> Ere Maijala >>>> Kansalliskirjasto / The National Library of Finland >>>> >>>> >>>> _______________________________________________ >>>> Vufind-tech mailing list >>>> Vuf...@li... <mailto:Vuf...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/vufind-tech <https://lists.sourceforge.net/lists/listinfo/vufind-tech> >>> -- >>> *Alex Buckley (he/him)* >>> Koha Developer | Implementation Lead >>> *Catalyst.Net Limited - Expert Open Source Solutions* >>> >>> *Catalyst.Net Limited - a Catalyst IT group company* >>> www.catalyst.net.nz <http://www.catalyst.net.nz/> >>> >>> Follow Catalyst Koha on Twitter <https://twitter.com/catalystkoha> | >>> Subscribe to the Catalyst Koha newsletter >>> <https://catalyst.us4.list-manage.com/subscribe?u=62457ff5060d15ee3c07d3fc4&id=b73fbdcac8> >>> >>> Catalyst Logo >>> >>> CONFIDENTIALITY NOTICE: This email is intended for the named >>> recipients only. It may contain privileged, confidential or >>> copyright information. If you are not the named recipient, any use, >>> reliance upon, disclosure or copying of this email or its >>> attachments is unauthorised. If you have received this email in >>> error, please reply via email or call +64 4 499 2267. >>> >>> >>> _______________________________________________ >>> Vufind-tech mailing list >>> Vuf...@li... <mailto:Vuf...@li...> >>> https://lists.sourceforge.net/lists/listinfo/vufind-tech <https://lists.sourceforge.net/lists/listinfo/vufind-tech> >> -- >> Ere Maijala >> Kansalliskirjasto / The National Library of Finland > -- > Ere Maijala > Kansalliskirjasto / The National Library of Finland -- Ere Maijala Kansalliskirjasto / The National Library of Finland |
From: Demian K. <dem...@vi...> - 2024-03-11 12:35:38
|
Ere, This may be worth tackling eventually, but I agree that it's very complicated. It might be useful to redesign the mechanism so that fetching holdings and fetching items are two separate calls – then we could summarize the holdings quickly and load the items with AJAX. But even that is not straightforward, and it would require significant thought to be sure we covered all the possible use cases and situations. Maybe worth a JIRA ticket so we have a place to begin collecting thoughts... - Demian ________________________________ From: Ere Maijala <ere...@he...> Sent: Monday, March 11, 2024 6:39 AM To: Demian Katz <dem...@vi...>; vuf...@li... <vuf...@li...> Subject: Re: [EXTERNAL] Re: [VuFind-Tech] Gateway timeout from viewing bibliographic record with large number of item records I thought about it too, but it's indeed a huge pain. We do holdings paging in particular cases, but I'd try to avoid it here. --Ere On 11.3.2024 11.48, Demian Katz wrote: The only other option, which could be useful but complicated, would be to design a general holdings pagination mechanism... but due to the way data gets grouped and processed, this would not be straightforward. - Demian Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Ere Maijala <ere...@he...><mailto:ere...@he...> Sent: Monday, March 11, 2024 5:36:40 AM To: vuf...@li...<mailto:vuf...@li...> <vuf...@li...><mailto:vuf...@li...> Subject: [EXTERNAL] Re: [VuFind-Tech] Gateway timeout from viewing bibliographic record with large number of item records Hi, In VuFind it's basicly a single API call (plus another one to fetch names of libraries if not already cached), so not much that could be optimized there. Perhaps VuFind could indicate the priority order of different item statuses, which would allow the Koha plugin to do the checks in the requested order and only return the first status, which would avoid calculation of unnecessary status information, but that still requires the Koha plugin to do most of the work. That's the way I intend pursue, anyway, at some point. I would have expected the statuses for 200-300 items to be returned quicker than the timeout, so I believe that adding RAM as you mentioned could be the key to improve performance by letting more of the database be cached in memory. Increasing e.g. InnoDB buffer pool size in MySQL could also help. --Ere On 10.3.2024 22.30, Alex Buckley via Vufind-tech wrote: Hi Ere, Thanks for your response. A large number of items in this case, would be 200-300 items. We are indeed using the KohaRest driver. Thanks for your suggestions. I'll try the following and see if that helps improve the situation: * Turning on the loadInitialTabWithAjax in config.ini. * Adding http_timeout = 60 from the Catalog section of KohaRest.ini Do you see there is room for some performance improvement in the KohaRest driver as well as the Koha DI plugin? Kind regards, Alex On 9/03/24 00:39, Ere Maijala wrote: Hi, How much is a large number of items? For comparison typical performance I've seen is ~60 items per second, so a fairly high number of items, like 800, takes some 13 seconds. But first of all I'd suggest turning on the loadInitialTabWithAjax setting in VuFind's config.ini. This will ensure the main page loads quickly even if the Holdings tab is slow. If you're using KohaRest driver with Vufind, you can try to increase the timeout by adding something like this to Catalog section of KohaRest.ini in VuFind: http_timeout = 60 Regardless of whether that helps, it's obviously not a very fluid service if you have to wait an eternity for holdings information. I think there could be room for some performance improvement in the Koha DI plugin in some cases where we only need the most important status information and don't need to know everything about the items. Unfortunately I don't currently have much bandwidth to pursue this further, but it would be interesting to profile the availability calculation in the DI plugin a bit to see if there's a particularly heavy operation that we could avoid in some cases. Best, Ere On 8.3.2024 10.57, Alex Buckley via Vufind-tech wrote: Hi VuFind community, We have a partner library (using VuFind integrated with Koha) with approximately 40 print journal bibliographic records with a large number of item records attached. They find that when they view these journal bibliographic records they encounter a gateway timeout - see attached screenshot. Here are some more details about this timeout: * This gateway timeout happens on multiple environments - dev, staging and prod. So ruled out as environment specific. * The gateway timeout does not happen for biblios with a smaller number of linked items. * Our partner library encounters these gateway timeouts everytime they try to load the journal biblios - when we (Catalyst staff) try to access those records the timeout is intermittent. Has anyone else encountered this problem when viewing biblio records with a large number of attached items (holdings)? If so, how did you fix this issue. When we encounter such issues in the Koha LMS we usually recommend the server RAM specs be increased - to handle the additional processing . However, we would really appreciate any assistance or suggestions from others in the community! Thanks very much in advance, Alex _______________________________________________ Vufind-tech mailing list Vuf...@li...<mailto:Vuf...@li...> https://lists.sourceforge.net/lists/listinfo/vufind-tech -- Ere Maijala Kansalliskirjasto / The National Library of Finland _______________________________________________ Vufind-tech mailing list Vuf...@li...<mailto:Vuf...@li...> https://lists.sourceforge.net/lists/listinfo/vufind-tech -- Alex Buckley (he/him) Koha Developer | Implementation Lead Catalyst.Net Limited - Expert Open Source Solutions Catalyst.Net Limited - a Catalyst IT group company www.catalyst.net.nz<http://www.catalyst.net.nz/> Follow Catalyst Koha on Twitter<https://twitter.com/catalystkoha> | Subscribe to the Catalyst Koha newsletter<https://catalyst.us4.list-manage.com/subscribe?u=62457ff5060d15ee3c07d3fc4&id=b73fbdcac8> [Catalyst Logo] CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267. _______________________________________________ Vufind-tech mailing list Vuf...@li...<mailto:Vuf...@li...> https://lists.sourceforge.net/lists/listinfo/vufind-tech -- Ere Maijala Kansalliskirjasto / The National Library of Finland -- Ere Maijala Kansalliskirjasto / The National Library of Finland |
From: Ere M. <ere...@he...> - 2024-03-11 10:39:43
|
I thought about it too, but it's indeed a huge pain. We do holdings paging in particular cases, but I'd try to avoid it here. --Ere On 11.3.2024 11.48, Demian Katz wrote: > The only other option, which could be useful but complicated, would be > to design a general holdings pagination mechanism... but due to the > way data gets grouped and processed, this would not be straightforward. > > - Demian > > Sent from my Verizon, Samsung Galaxy smartphone > Get Outlook for Android <https://aka.ms/AAb9ysg> > ------------------------------------------------------------------------ > *From:* Ere Maijala <ere...@he...> > *Sent:* Monday, March 11, 2024 5:36:40 AM > *To:* vuf...@li... > <vuf...@li...> > *Subject:* [EXTERNAL] Re: [VuFind-Tech] Gateway timeout from viewing > bibliographic record with large number of item records > > Hi, > > In VuFind it's basicly a single API call (plus another one to fetch > names of libraries if not already cached), so not much that could be > optimized there. > > Perhaps VuFind could indicate the priority order of different item > statuses, which would allow the Koha plugin to do the checks in the > requested order and only return the first status, which would avoid > calculation of unnecessary status information, but that still requires > the Koha plugin to do most of the work. That's the way I intend > pursue, anyway, at some point. > > I would have expected the statuses for 200-300 items to be returned > quicker than the timeout, so I believe that adding RAM as you > mentioned could be the key to improve performance by letting more of > the database be cached in memory. Increasing e.g. InnoDB buffer pool > size in MySQL could also help. > > --Ere > > On 10.3.2024 22.30, Alex Buckley via Vufind-tech wrote: >> >> Hi Ere, >> >> Thanks for your response. >> >> A large number of items in this case, would be 200-300 items. We are >> indeed using the KohaRest driver. >> >> Thanks for your suggestions. I'll try the following and see if that >> helps improve the situation: >> >> * Turning on the loadInitialTabWithAjax in config.ini. >> * Adding http_timeout = 60 from the Catalog section of KohaRest.ini >> >> Do you see there is room for some performance improvement in the >> KohaRest driver as well as the Koha DI plugin? >> >> Kind regards, >> >> Alex >> >> >> On 9/03/24 00:39, Ere Maijala wrote: >>> >>> Hi, >>> >>> How much is a large number of items? For comparison typical >>> performance I've seen is ~60 items per second, so a fairly high >>> number of items, like 800, takes some 13 seconds. >>> >>> But first of all I'd suggest turning on the loadInitialTabWithAjax >>> setting in VuFind's config.ini. This will ensure the main page loads >>> quickly even if the Holdings tab is slow. >>> >>> If you're using KohaRest driver with Vufind, you can try to increase >>> the timeout by adding something like this to Catalog section of >>> KohaRest.ini in VuFind: >>> >>> http_timeout = 60 >>> >>> Regardless of whether that helps, it's obviously not a very fluid >>> service if you have to wait an eternity for holdings information. I >>> think there could be room for some performance improvement in the >>> Koha DI plugin in some cases where we only need the most important >>> status information and don't need to know everything about the >>> items. Unfortunately I don't currently have much bandwidth to pursue >>> this further, but it would be interesting to profile the >>> availability calculation in the DI plugin a bit to see if there's a >>> particularly heavy operation that we could avoid in some cases. >>> >>> Best, >>> >>> Ere >>> >>> On 8.3.2024 10.57, Alex Buckley via Vufind-tech wrote: >>>> >>>> Hi VuFind community, >>>> >>>> We have a partner library (using VuFind integrated with Koha) with >>>> approximately 40 print journal bibliographic records with a large >>>> number of item records attached. >>>> >>>> They find that when they view these journal bibliographic records >>>> they encounter a gateway timeout - see attached screenshot. Here >>>> are some more details about this timeout: >>>> >>>> * This gateway timeout happens on multiple environments - dev, >>>> staging and prod. So ruled out as environment specific. >>>> * The gateway timeout does not happen for biblios with a smaller >>>> number of linked items. >>>> * Our partner library encounters these gateway timeouts everytime >>>> they try to load the journal biblios - when we (Catalyst staff) >>>> try to access those records the timeout is intermittent. >>>> >>>> Has anyone else encountered this problem when viewing biblio >>>> records with a large number of attached items (holdings)? If so, >>>> how did you fix this issue. >>>> >>>> When we encounter such issues in the Koha LMS we usually recommend >>>> the server RAM specs be increased - to handle the additional >>>> processing . However, we would really appreciate any assistance or >>>> suggestions from others in the community! >>>> >>>> Thanks very much in advance, >>>> >>>> Alex >>>> >>>> >>>> >>>> _______________________________________________ >>>> Vufind-tech mailing list >>>> Vuf...@li... <mailto:Vuf...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/vufind-tech <https://lists.sourceforge.net/lists/listinfo/vufind-tech> >>> -- >>> Ere Maijala >>> Kansalliskirjasto / The National Library of Finland >>> >>> >>> _______________________________________________ >>> Vufind-tech mailing list >>> Vuf...@li... <mailto:Vuf...@li...> >>> https://lists.sourceforge.net/lists/listinfo/vufind-tech <https://lists.sourceforge.net/lists/listinfo/vufind-tech> >> -- >> *Alex Buckley (he/him)* >> Koha Developer | Implementation Lead >> *Catalyst.Net Limited - Expert Open Source Solutions* >> >> *Catalyst.Net Limited - a Catalyst IT group company* >> www.catalyst.net.nz <http://www.catalyst.net.nz/> >> >> Follow Catalyst Koha on Twitter <https://twitter.com/catalystkoha> | >> Subscribe to the Catalyst Koha newsletter >> <https://catalyst.us4.list-manage.com/subscribe?u=62457ff5060d15ee3c07d3fc4&id=b73fbdcac8> >> >> Catalyst Logo >> >> CONFIDENTIALITY NOTICE: This email is intended for the named >> recipients only. It may contain privileged, confidential or copyright >> information. If you are not the named recipient, any use, reliance >> upon, disclosure or copying of this email or its attachments is >> unauthorised. If you have received this email in error, please reply >> via email or call +64 4 499 2267. >> >> >> _______________________________________________ >> Vufind-tech mailing list >> Vuf...@li... <mailto:Vuf...@li...> >> https://lists.sourceforge.net/lists/listinfo/vufind-tech <https://lists.sourceforge.net/lists/listinfo/vufind-tech> > -- > Ere Maijala > Kansalliskirjasto / The National Library of Finland -- Ere Maijala Kansalliskirjasto / The National Library of Finland |
From: Demian K. <dem...@vi...> - 2024-03-11 10:23:13
|
The only other option, which could be useful but complicated, would be to design a general holdings pagination mechanism... but due to the way data gets grouped and processed, this would not be straightforward. - Demian Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Ere Maijala <ere...@he...> Sent: Monday, March 11, 2024 5:36:40 AM To: vuf...@li... <vuf...@li...> Subject: [EXTERNAL] Re: [VuFind-Tech] Gateway timeout from viewing bibliographic record with large number of item records Hi, In VuFind it's basicly a single API call (plus another one to fetch names of libraries if not already cached), so not much that could be optimized there. Perhaps VuFind could indicate the priority order of different item statuses, which would allow the Koha plugin to do the checks in the requested order and only return the first status, which would avoid calculation of unnecessary status information, but that still requires the Koha plugin to do most of the work. That's the way I intend pursue, anyway, at some point. I would have expected the statuses for 200-300 items to be returned quicker than the timeout, so I believe that adding RAM as you mentioned could be the key to improve performance by letting more of the database be cached in memory. Increasing e.g. InnoDB buffer pool size in MySQL could also help. --Ere On 10.3.2024 22.30, Alex Buckley via Vufind-tech wrote: Hi Ere, Thanks for your response. A large number of items in this case, would be 200-300 items. We are indeed using the KohaRest driver. Thanks for your suggestions. I'll try the following and see if that helps improve the situation: * Turning on the loadInitialTabWithAjax in config.ini. * Adding http_timeout = 60 from the Catalog section of KohaRest.ini Do you see there is room for some performance improvement in the KohaRest driver as well as the Koha DI plugin? Kind regards, Alex On 9/03/24 00:39, Ere Maijala wrote: Hi, How much is a large number of items? For comparison typical performance I've seen is ~60 items per second, so a fairly high number of items, like 800, takes some 13 seconds. But first of all I'd suggest turning on the loadInitialTabWithAjax setting in VuFind's config.ini. This will ensure the main page loads quickly even if the Holdings tab is slow. If you're using KohaRest driver with Vufind, you can try to increase the timeout by adding something like this to Catalog section of KohaRest.ini in VuFind: http_timeout = 60 Regardless of whether that helps, it's obviously not a very fluid service if you have to wait an eternity for holdings information. I think there could be room for some performance improvement in the Koha DI plugin in some cases where we only need the most important status information and don't need to know everything about the items. Unfortunately I don't currently have much bandwidth to pursue this further, but it would be interesting to profile the availability calculation in the DI plugin a bit to see if there's a particularly heavy operation that we could avoid in some cases. Best, Ere On 8.3.2024 10.57, Alex Buckley via Vufind-tech wrote: Hi VuFind community, We have a partner library (using VuFind integrated with Koha) with approximately 40 print journal bibliographic records with a large number of item records attached. They find that when they view these journal bibliographic records they encounter a gateway timeout - see attached screenshot. Here are some more details about this timeout: * This gateway timeout happens on multiple environments - dev, staging and prod. So ruled out as environment specific. * The gateway timeout does not happen for biblios with a smaller number of linked items. * Our partner library encounters these gateway timeouts everytime they try to load the journal biblios - when we (Catalyst staff) try to access those records the timeout is intermittent. Has anyone else encountered this problem when viewing biblio records with a large number of attached items (holdings)? If so, how did you fix this issue. When we encounter such issues in the Koha LMS we usually recommend the server RAM specs be increased - to handle the additional processing . However, we would really appreciate any assistance or suggestions from others in the community! Thanks very much in advance, Alex _______________________________________________ Vufind-tech mailing list Vuf...@li...<mailto:Vuf...@li...> https://lists.sourceforge.net/lists/listinfo/vufind-tech -- Ere Maijala Kansalliskirjasto / The National Library of Finland _______________________________________________ Vufind-tech mailing list Vuf...@li...<mailto:Vuf...@li...> https://lists.sourceforge.net/lists/listinfo/vufind-tech -- Alex Buckley (he/him) Koha Developer | Implementation Lead Catalyst.Net Limited - Expert Open Source Solutions Catalyst.Net Limited - a Catalyst IT group company www.catalyst.net.nz<http://www.catalyst.net.nz/> Follow Catalyst Koha on Twitter<https://twitter.com/catalystkoha> | Subscribe to the Catalyst Koha newsletter<https://catalyst.us4.list-manage.com/subscribe?u=62457ff5060d15ee3c07d3fc4&id=b73fbdcac8> [Catalyst Logo] CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267. _______________________________________________ Vufind-tech mailing list Vuf...@li...<mailto:Vuf...@li...> https://lists.sourceforge.net/lists/listinfo/vufind-tech -- Ere Maijala Kansalliskirjasto / The National Library of Finland |
From: Demian K. <dem...@vi...> - 2024-03-11 10:20:24
|
Hugo, The sslcapath/file settings should point to your OS certificate store, not the cert used by your own site. These settings help verify the certificates used by other sites when VuFind makes SSL requests. If you only include your own key, then external sites cannot be validated correctly. - Demian Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Hugo Agud Andreu <ha...@or...> Sent: Monday, March 11, 2024 4:57:18 AM To: Demian Katz <dem...@vi...>; vufind-tech <vuf...@li...> Subject: RE: [EXTERNAL] [VuFind-Tech] Harvesing oai-repository on 443 port Good morning I think I have configured propertly but I am facing an issue that I ask for help, please Unable to enable crypto on TCP connection sgb.ucuenca.edu.ec: make sure the "sslcafile" option points to a valid SSL certificate file config.ini sslcapath = "/etc/letsencrypt/live/vufind.lets.edu./" sslcafile = "/etc/letsencrypt/live/vufind.lets.edu/cert.pem" Where it could be the issue? Hugo Agud - Orex Digital www.orex.es<http://www.orex.es/> Linkedin<https://www.linkedin.com/company/orex-digital/> Innovando para ayudar a las bibliotecas a alcanzar el siguiente nivel<https://orex.es/productos/orex-analytics/> Rosa Leveroni 10 Oficina 2 - 08960 Sant Just Desvern - Tel: 932 435 179 ha...@or...<mailto:ha...@or...> · http://www.orex.es/ No imprima este mensaje a no ser que sea necesario. Una tonelada de papel implica la tala de 15 árboles y el consumo de 250.000 litros de agua. Aviso de confidencialidad Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su destinatario, pudiendo contener información confidencial sometida a secreto profesional. No está permitida su reproducción o distribución sin la autorización expresa de Orex Digital, S.L. Si usted no es el destinatario final por favor elimínelo e infórmenos por esta vía. En cumplimiento de lo establecido en el Reglamento General de Protección de Datos (RGPD) (UE) 2016/679 y a la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos de Carácter Personal y Garantía de los Derechos Digitales (LOPD-GDD), le informamos que tratamos sus datos personales con la finalidad de responder a su solicitud de información, realizar la gestión administrativa derivada de nuestra relación comercial o contractual, así como enviarle comunicaciones comerciales sobre nuestros productos y servicios. La legitimación será en base a un interés legítimo, por ejecución de un contrato y/o por consentimiento, en algunos casos. Los datos proporcionados se conservarán mientras se mantenga la relación contractual o durante los años necesarios para cumplir con las obligaciones legales. Los datos no se cederán a terceros salvo en los casos en que exista una obligación legal o sea necesario para la ejecución de un contrato. No se tomarán decisiones automatizadas que puedan causar un efecto jurídico significativo, salvo que se haya recabado previamente el consentimiento. Asimismo, le informamos de la posibilidad de ejercer los siguientes derechos sobre sus datos personales: derecho de acceso, rectificación, supresión u olvido, limitación, oposición, portabilidad y a retirar el consentimiento prestado. Para ello podrá enviar un email a: in...@or...<mailto:in...@or...>, adjuntando copia de su DNI. Además, el interesado puede dirigirse a la Autoridad de Control en materia de Protección de Datos competente (AEPD, en España) para obtener información adicional o presentar una reclamación. Datos identificativos: Orex Digital, S.L.U., B64500945, Rosa Leveroni 10, Oficina 2 - 08960 - Sant Just Desvern - BARCELONA, 932 435 179 ________________________________ De: Demian Katz <dem...@vi...> Enviado: lunes, 29 de enero de 2024 11:38 Para: Hugo Agud Andreu <ha...@or...>; vufind-tech <vuf...@li...> Asunto: Re: [EXTERNAL] [VuFind-Tech] Harvesing oai-repository on 443 port Can you successfully wget the url from the same system? Is the [Http] section of config.ini set up correctly? There are some SSL-related settings there Let me know if these questions lead you to a solution; if not, are you able to share your oai.ini section? - Demian Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Hugo Agud Andreu <ha...@or...> Sent: Monday, January 29, 2024 1:56:50 AM To: vufind-tech <vuf...@li...> Subject: [EXTERNAL] [VuFind-Tech] Harvesing oai-repository on 443 port Good morning I have to harvest an oai.pmh repositoriy on port 443 and Vufind is claiming that it can'0t Unable to connect to Error #0: stream_socket_client(): I guess I have to configure ssl cert in oai.ini? may anyone help us on this, please? Hugo Agud - Orex Digital www.orex.es<http://www.orex.es/> Linkedin<https://www.linkedin.com/company/orex-digital/> Innovando para ayudar a las bibliotecas a alcanzar el siguiente nivel<https://orex.es/productos/orex-analytics/> Rosa Leveroni 10 Oficina 2 - 08960 Sant Just Desvern - Tel: 932 435 179 ha...@or...<mailto:ha...@or...> · http://www.orex.es/ No imprima este mensaje a no ser que sea necesario. Una tonelada de papel implica la tala de 15 árboles y el consumo de 250.000 litros de agua. Aviso de confidencialidad Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su destinatario, pudiendo contener información confidencial sometida a secreto profesional. No está permitida su reproducción o distribución sin la autorización expresa de Orex Digital, S.L. Si usted no es el destinatario final por favor elimínelo e infórmenos por esta vía. En cumplimiento de lo establecido en el Reglamento General de Protección de Datos (RGPD) (UE) 2016/679 y a la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos de Carácter Personal y Garantía de los Derechos Digitales (LOPD-GDD), le informamos que tratamos sus datos personales con la finalidad de responder a su solicitud de información, realizar la gestión administrativa derivada de nuestra relación comercial o contractual, así como enviarle comunicaciones comerciales sobre nuestros productos y servicios. La legitimación será en base a un interés legítimo, por ejecución de un contrato y/o por consentimiento, en algunos casos. Los datos proporcionados se conservarán mientras se mantenga la relación contractual o durante los años necesarios para cumplir con las obligaciones legales. Los datos no se cederán a terceros salvo en los casos en que exista una obligación legal o sea necesario para la ejecución de un contrato. No se tomarán decisiones automatizadas que puedan causar un efecto jurídico significativo, salvo que se haya recabado previamente el consentimiento. Asimismo, le informamos de la posibilidad de ejercer los siguientes derechos sobre sus datos personales: derecho de acceso, rectificación, supresión u olvido, limitación, oposición, portabilidad y a retirar el consentimiento prestado. Para ello podrá enviar un email a: in...@or...<mailto:in...@or...>, adjuntando copia de su DNI. Además, el interesado puede dirigirse a la Autoridad de Control en materia de Protección de Datos competente (AEPD, en España) para obtener información adicional o presentar una reclamación. Datos identificativos: Orex Digital, S.L.U., B64500945, Rosa Leveroni 10, Oficina 2 - 08960 - Sant Just Desvern - BARCELONA, 932 435 179 |
From: Ere M. <ere...@he...> - 2024-03-11 09:37:01
|
Hi, In VuFind it's basicly a single API call (plus another one to fetch names of libraries if not already cached), so not much that could be optimized there. Perhaps VuFind could indicate the priority order of different item statuses, which would allow the Koha plugin to do the checks in the requested order and only return the first status, which would avoid calculation of unnecessary status information, but that still requires the Koha plugin to do most of the work. That's the way I intend pursue, anyway, at some point. I would have expected the statuses for 200-300 items to be returned quicker than the timeout, so I believe that adding RAM as you mentioned could be the key to improve performance by letting more of the database be cached in memory. Increasing e.g. InnoDB buffer pool size in MySQL could also help. --Ere On 10.3.2024 22.30, Alex Buckley via Vufind-tech wrote: > > Hi Ere, > > Thanks for your response. > > A large number of items in this case, would be 200-300 items. We are > indeed using the KohaRest driver. > > Thanks for your suggestions. I'll try the following and see if that > helps improve the situation: > > * Turning on the loadInitialTabWithAjax in config.ini. > * Adding http_timeout = 60 from the Catalog section of KohaRest.ini > > Do you see there is room for some performance improvement in the > KohaRest driver as well as the Koha DI plugin? > > Kind regards, > > Alex > > > On 9/03/24 00:39, Ere Maijala wrote: >> >> Hi, >> >> How much is a large number of items? For comparison typical >> performance I've seen is ~60 items per second, so a fairly high >> number of items, like 800, takes some 13 seconds. >> >> But first of all I'd suggest turning on the loadInitialTabWithAjax >> setting in VuFind's config.ini. This will ensure the main page loads >> quickly even if the Holdings tab is slow. >> >> If you're using KohaRest driver with Vufind, you can try to increase >> the timeout by adding something like this to Catalog section of >> KohaRest.ini in VuFind: >> >> http_timeout = 60 >> >> Regardless of whether that helps, it's obviously not a very fluid >> service if you have to wait an eternity for holdings information. I >> think there could be room for some performance improvement in the >> Koha DI plugin in some cases where we only need the most important >> status information and don't need to know everything about the items. >> Unfortunately I don't currently have much bandwidth to pursue this >> further, but it would be interesting to profile the availability >> calculation in the DI plugin a bit to see if there's a particularly >> heavy operation that we could avoid in some cases. >> >> Best, >> >> Ere >> >> On 8.3.2024 10.57, Alex Buckley via Vufind-tech wrote: >>> >>> Hi VuFind community, >>> >>> We have a partner library (using VuFind integrated with Koha) with >>> approximately 40 print journal bibliographic records with a large >>> number of item records attached. >>> >>> They find that when they view these journal bibliographic records >>> they encounter a gateway timeout - see attached screenshot. Here are >>> some more details about this timeout: >>> >>> * This gateway timeout happens on multiple environments - dev, >>> staging and prod. So ruled out as environment specific. >>> * The gateway timeout does not happen for biblios with a smaller >>> number of linked items. >>> * Our partner library encounters these gateway timeouts everytime >>> they try to load the journal biblios - when we (Catalyst staff) >>> try to access those records the timeout is intermittent. >>> >>> Has anyone else encountered this problem when viewing biblio records >>> with a large number of attached items (holdings)? If so, how did you >>> fix this issue. >>> >>> When we encounter such issues in the Koha LMS we usually recommend >>> the server RAM specs be increased - to handle the additional >>> processing . However, we would really appreciate any assistance or >>> suggestions from others in the community! >>> >>> Thanks very much in advance, >>> >>> Alex >>> >>> >>> >>> _______________________________________________ >>> Vufind-tech mailing list >>> Vuf...@li... >>> https://lists.sourceforge.net/lists/listinfo/vufind-tech >> -- >> Ere Maijala >> Kansalliskirjasto / The National Library of Finland >> >> >> _______________________________________________ >> Vufind-tech mailing list >> Vuf...@li... >> https://lists.sourceforge.net/lists/listinfo/vufind-tech > -- > *Alex Buckley (he/him)* > Koha Developer | Implementation Lead > *Catalyst.Net Limited - Expert Open Source Solutions* > > *Catalyst.Net Limited - a Catalyst IT group company* > www.catalyst.net.nz <http://www.catalyst.net.nz> > > Follow Catalyst Koha on Twitter <https://twitter.com/catalystkoha> | > Subscribe to the Catalyst Koha newsletter > <https://catalyst.us4.list-manage.com/subscribe?u=62457ff5060d15ee3c07d3fc4&id=b73fbdcac8> > > Catalyst Logo > > CONFIDENTIALITY NOTICE: This email is intended for the named > recipients only. It may contain privileged, confidential or copyright > information. If you are not the named recipient, any use, reliance > upon, disclosure or copying of this email or its attachments is > unauthorised. If you have received this email in error, please reply > via email or call +64 4 499 2267. > > > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech -- Ere Maijala Kansalliskirjasto / The National Library of Finland |
From: Hugo A. A. <ha...@or...> - 2024-03-11 09:31:07
|
Good morning I think I have configured propertly but I am facing an issue that I ask for help, please Unable to enable crypto on TCP connection sgb.ucuenca.edu.ec: make sure the "sslcafile" option points to a valid SSL certificate file config.ini sslcapath = "/etc/letsencrypt/live/vufind.lets.edu./" sslcafile = "/etc/letsencrypt/live/vufind.lets.edu/cert.pem" Where it could be the issue? Hugo Agud - Orex Digital www.orex.es<http://www.orex.es/> Linkedin<https://www.linkedin.com/company/orex-digital/> Innovando para ayudar a las bibliotecas a alcanzar el siguiente nivel<https://orex.es/productos/orex-analytics/> Rosa Leveroni 10 Oficina 2 - 08960 Sant Just Desvern - Tel: 932 435 179 ha...@or...<mailto:ha...@or...> · http://www.orex.es/ No imprima este mensaje a no ser que sea necesario. Una tonelada de papel implica la tala de 15 árboles y el consumo de 250.000 litros de agua. Aviso de confidencialidad Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su destinatario, pudiendo contener información confidencial sometida a secreto profesional. No está permitida su reproducción o distribución sin la autorización expresa de Orex Digital, S.L. Si usted no es el destinatario final por favor elimínelo e infórmenos por esta vía. En cumplimiento de lo establecido en el Reglamento General de Protección de Datos (RGPD) (UE) 2016/679 y a la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos de Carácter Personal y Garantía de los Derechos Digitales (LOPD-GDD), le informamos que tratamos sus datos personales con la finalidad de responder a su solicitud de información, realizar la gestión administrativa derivada de nuestra relación comercial o contractual, así como enviarle comunicaciones comerciales sobre nuestros productos y servicios. La legitimación será en base a un interés legítimo, por ejecución de un contrato y/o por consentimiento, en algunos casos. Los datos proporcionados se conservarán mientras se mantenga la relación contractual o durante los años necesarios para cumplir con las obligaciones legales. Los datos no se cederán a terceros salvo en los casos en que exista una obligación legal o sea necesario para la ejecución de un contrato. No se tomarán decisiones automatizadas que puedan causar un efecto jurídico significativo, salvo que se haya recabado previamente el consentimiento. Asimismo, le informamos de la posibilidad de ejercer los siguientes derechos sobre sus datos personales: derecho de acceso, rectificación, supresión u olvido, limitación, oposición, portabilidad y a retirar el consentimiento prestado. Para ello podrá enviar un email a: in...@or...<mailto:in...@or...>, adjuntando copia de su DNI. Además, el interesado puede dirigirse a la Autoridad de Control en materia de Protección de Datos competente (AEPD, en España) para obtener información adicional o presentar una reclamación. Datos identificativos: Orex Digital, S.L.U., B64500945, Rosa Leveroni 10, Oficina 2 - 08960 - Sant Just Desvern - BARCELONA, 932 435 179 ________________________________ De: Demian Katz <dem...@vi...> Enviado: lunes, 29 de enero de 2024 11:38 Para: Hugo Agud Andreu <ha...@or...>; vufind-tech <vuf...@li...> Asunto: Re: [EXTERNAL] [VuFind-Tech] Harvesing oai-repository on 443 port Can you successfully wget the url from the same system? Is the [Http] section of config.ini set up correctly? There are some SSL-related settings there Let me know if these questions lead you to a solution; if not, are you able to share your oai.ini section? - Demian Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Hugo Agud Andreu <ha...@or...> Sent: Monday, January 29, 2024 1:56:50 AM To: vufind-tech <vuf...@li...> Subject: [EXTERNAL] [VuFind-Tech] Harvesing oai-repository on 443 port Good morning I have to harvest an oai.pmh repositoriy on port 443 and Vufind is claiming that it can'0t Unable to connect to Error #0: stream_socket_client(): I guess I have to configure ssl cert in oai.ini? may anyone help us on this, please? Hugo Agud - Orex Digital www.orex.es<http://www.orex.es/> Linkedin<https://www.linkedin.com/company/orex-digital/> Innovando para ayudar a las bibliotecas a alcanzar el siguiente nivel<https://orex.es/productos/orex-analytics/> Rosa Leveroni 10 Oficina 2 - 08960 Sant Just Desvern - Tel: 932 435 179 ha...@or...<mailto:ha...@or...> · http://www.orex.es/ No imprima este mensaje a no ser que sea necesario. Una tonelada de papel implica la tala de 15 árboles y el consumo de 250.000 litros de agua. Aviso de confidencialidad Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su destinatario, pudiendo contener información confidencial sometida a secreto profesional. No está permitida su reproducción o distribución sin la autorización expresa de Orex Digital, S.L. Si usted no es el destinatario final por favor elimínelo e infórmenos por esta vía. En cumplimiento de lo establecido en el Reglamento General de Protección de Datos (RGPD) (UE) 2016/679 y a la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos de Carácter Personal y Garantía de los Derechos Digitales (LOPD-GDD), le informamos que tratamos sus datos personales con la finalidad de responder a su solicitud de información, realizar la gestión administrativa derivada de nuestra relación comercial o contractual, así como enviarle comunicaciones comerciales sobre nuestros productos y servicios. La legitimación será en base a un interés legítimo, por ejecución de un contrato y/o por consentimiento, en algunos casos. Los datos proporcionados se conservarán mientras se mantenga la relación contractual o durante los años necesarios para cumplir con las obligaciones legales. Los datos no se cederán a terceros salvo en los casos en que exista una obligación legal o sea necesario para la ejecución de un contrato. No se tomarán decisiones automatizadas que puedan causar un efecto jurídico significativo, salvo que se haya recabado previamente el consentimiento. Asimismo, le informamos de la posibilidad de ejercer los siguientes derechos sobre sus datos personales: derecho de acceso, rectificación, supresión u olvido, limitación, oposición, portabilidad y a retirar el consentimiento prestado. Para ello podrá enviar un email a: in...@or...<mailto:in...@or...>, adjuntando copia de su DNI. Además, el interesado puede dirigirse a la Autoridad de Control en materia de Protección de Datos competente (AEPD, en España) para obtener información adicional o presentar una reclamación. Datos identificativos: Orex Digital, S.L.U., B64500945, Rosa Leveroni 10, Oficina 2 - 08960 - Sant Just Desvern - BARCELONA, 932 435 179 |
From: Alex B. <ale...@ca...> - 2024-03-10 20:30:56
|
Hi Ere, Thanks for your response. A large number of items in this case, would be 200-300 items. We are indeed using the KohaRest driver. Thanks for your suggestions. I'll try the following and see if that helps improve the situation: * Turning on the loadInitialTabWithAjax in config.ini. * Adding http_timeout = 60 from the Catalog section of KohaRest.ini Do you see there is room for some performance improvement in the KohaRest driver as well as the Koha DI plugin? Kind regards, Alex On 9/03/24 00:39, Ere Maijala wrote: > > Hi, > > How much is a large number of items? For comparison typical > performance I've seen is ~60 items per second, so a fairly high number > of items, like 800, takes some 13 seconds. > > But first of all I'd suggest turning on the loadInitialTabWithAjax > setting in VuFind's config.ini. This will ensure the main page loads > quickly even if the Holdings tab is slow. > > If you're using KohaRest driver with Vufind, you can try to increase > the timeout by adding something like this to Catalog section of > KohaRest.ini in VuFind: > > http_timeout = 60 > > Regardless of whether that helps, it's obviously not a very fluid > service if you have to wait an eternity for holdings information. I > think there could be room for some performance improvement in the Koha > DI plugin in some cases where we only need the most important status > information and don't need to know everything about the items. > Unfortunately I don't currently have much bandwidth to pursue this > further, but it would be interesting to profile the availability > calculation in the DI plugin a bit to see if there's a particularly > heavy operation that we could avoid in some cases. > > Best, > > Ere > > On 8.3.2024 10.57, Alex Buckley via Vufind-tech wrote: >> >> Hi VuFind community, >> >> We have a partner library (using VuFind integrated with Koha) with >> approximately 40 print journal bibliographic records with a large >> number of item records attached. >> >> They find that when they view these journal bibliographic records >> they encounter a gateway timeout - see attached screenshot. Here are >> some more details about this timeout: >> >> * This gateway timeout happens on multiple environments - dev, >> staging and prod. So ruled out as environment specific. >> * The gateway timeout does not happen for biblios with a smaller >> number of linked items. >> * Our partner library encounters these gateway timeouts everytime >> they try to load the journal biblios - when we (Catalyst staff) >> try to access those records the timeout is intermittent. >> >> Has anyone else encountered this problem when viewing biblio records >> with a large number of attached items (holdings)? If so, how did you >> fix this issue. >> >> When we encounter such issues in the Koha LMS we usually recommend >> the server RAM specs be increased - to handle the additional >> processing . However, we would really appreciate any assistance or >> suggestions from others in the community! >> >> Thanks very much in advance, >> >> Alex >> >> >> >> _______________________________________________ >> Vufind-tech mailing list >> Vuf...@li... >> https://lists.sourceforge.net/lists/listinfo/vufind-tech > -- > Ere Maijala > Kansalliskirjasto / The National Library of Finland > > > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech -- *Alex Buckley (he/him)* Koha Developer | Implementation Lead *Catalyst.Net Limited - Expert Open Source Solutions* *Catalyst.Net Limited - a Catalyst IT group company* www.catalyst.net.nz <http://www.catalyst.net.nz> Follow Catalyst Koha on Twitter <https://twitter.com/catalystkoha> | Subscribe to the Catalyst Koha newsletter <https://catalyst.us4.list-manage.com/subscribe?u=62457ff5060d15ee3c07d3fc4&id=b73fbdcac8> Catalyst Logo CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267. |
From: Alex B. <ale...@ca...> - 2024-03-10 03:10:40
|
Hi Demian, Thanks for your response. We are using the KohaRest driver :) Kind regards, Alex On 8/03/24 23:39, Demian Katz wrote: > Alex, > > Which Koha driver are you using? That might make a difference, since > each implements item retrieval differently. Perhaps there is room for > improvement in the one you're using. Beyond that, I defer to the > expertise of other Koha users, since I don't have personal experience > with that ILS. > > - Demian > > Sent from my Verizon, Samsung Galaxy smartphone > Get Outlook for Android <https://aka.ms/AAb9ysg> > ------------------------------------------------------------------------ > *From:* Alex Buckley via Vufind-tech <vuf...@li...> > *Sent:* Friday, March 8, 2024 3:57:54 AM > *To:* vuf...@li... > <vuf...@li...> > *Cc:* Matthew Banks <mat...@au...>; > koh...@ca... <koh...@ca...> > *Subject:* [EXTERNAL] [VuFind-Tech] Gateway timeout from viewing > bibliographic record with large number of item records > > Hi VuFind community, > > We have a partner library (using VuFind integrated with Koha) with > approximately 40 print journal bibliographic records with a large > number of item records attached. > > They find that when they view these journal bibliographic records they > encounter a gateway timeout - see attached screenshot. Here are some > more details about this timeout: > > * This gateway timeout happens on multiple environments - dev, > staging and prod. So ruled out as environment specific. > * The gateway timeout does not happen for biblios with a smaller > number of linked items. > * Our partner library encounters these gateway timeouts everytime > they try to load the journal biblios - when we (Catalyst staff) > try to access those records the timeout is intermittent. > > Has anyone else encountered this problem when viewing biblio records > with a large number of attached items (holdings)? If so, how did you > fix this issue. > > When we encounter such issues in the Koha LMS we usually recommend the > server RAM specs be increased - to handle the additional processing . > However, we would really appreciate any assistance or suggestions from > others in the community! > > Thanks very much in advance, > > Alex > -- *Alex Buckley (he/him)* Koha Developer | Implementation Lead *Catalyst.Net Limited - Expert Open Source Solutions* *Catalyst.Net Limited - a Catalyst IT group company* www.catalyst.net.nz <http://www.catalyst.net.nz> Follow Catalyst Koha on Twitter <https://twitter.com/catalystkoha> | Subscribe to the Catalyst Koha newsletter <https://catalyst.us4.list-manage.com/subscribe?u=62457ff5060d15ee3c07d3fc4&id=b73fbdcac8> Catalyst Logo CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267. |
From: Ere M. <ere...@he...> - 2024-03-08 11:40:11
|
Hi, How much is a large number of items? For comparison typical performance I've seen is ~60 items per second, so a fairly high number of items, like 800, takes some 13 seconds. But first of all I'd suggest turning on the loadInitialTabWithAjax setting in VuFind's config.ini. This will ensure the main page loads quickly even if the Holdings tab is slow. If you're using KohaRest driver with Vufind, you can try to increase the timeout by adding something like this to Catalog section of KohaRest.ini in VuFind: http_timeout = 60 Regardless of whether that helps, it's obviously not a very fluid service if you have to wait an eternity for holdings information. I think there could be room for some performance improvement in the Koha DI plugin in some cases where we only need the most important status information and don't need to know everything about the items. Unfortunately I don't currently have much bandwidth to pursue this further, but it would be interesting to profile the availability calculation in the DI plugin a bit to see if there's a particularly heavy operation that we could avoid in some cases. Best, Ere On 8.3.2024 10.57, Alex Buckley via Vufind-tech wrote: > > Hi VuFind community, > > We have a partner library (using VuFind integrated with Koha) with > approximately 40 print journal bibliographic records with a large > number of item records attached. > > They find that when they view these journal bibliographic records they > encounter a gateway timeout - see attached screenshot. Here are some > more details about this timeout: > > * This gateway timeout happens on multiple environments - dev, > staging and prod. So ruled out as environment specific. > * The gateway timeout does not happen for biblios with a smaller > number of linked items. > * Our partner library encounters these gateway timeouts everytime > they try to load the journal biblios - when we (Catalyst staff) > try to access those records the timeout is intermittent. > > Has anyone else encountered this problem when viewing biblio records > with a large number of attached items (holdings)? If so, how did you > fix this issue. > > When we encounter such issues in the Koha LMS we usually recommend the > server RAM specs be increased - to handle the additional processing . > However, we would really appreciate any assistance or suggestions from > others in the community! > > Thanks very much in advance, > > Alex > > > > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech -- Ere Maijala Kansalliskirjasto / The National Library of Finland |
From: Demian K. <dem...@vi...> - 2024-03-08 10:40:09
|
Alex, Which Koha driver are you using? That might make a difference, since each implements item retrieval differently. Perhaps there is room for improvement in the one you're using. Beyond that, I defer to the expertise of other Koha users, since I don't have personal experience with that ILS. - Demian Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Alex Buckley via Vufind-tech <vuf...@li...> Sent: Friday, March 8, 2024 3:57:54 AM To: vuf...@li... <vuf...@li...> Cc: Matthew Banks <mat...@au...>; koh...@ca... <koh...@ca...> Subject: [EXTERNAL] [VuFind-Tech] Gateway timeout from viewing bibliographic record with large number of item records Hi VuFind community, We have a partner library (using VuFind integrated with Koha) with approximately 40 print journal bibliographic records with a large number of item records attached. They find that when they view these journal bibliographic records they encounter a gateway timeout - see attached screenshot. Here are some more details about this timeout: * This gateway timeout happens on multiple environments - dev, staging and prod. So ruled out as environment specific. * The gateway timeout does not happen for biblios with a smaller number of linked items. * Our partner library encounters these gateway timeouts everytime they try to load the journal biblios - when we (Catalyst staff) try to access those records the timeout is intermittent. Has anyone else encountered this problem when viewing biblio records with a large number of attached items (holdings)? If so, how did you fix this issue. When we encounter such issues in the Koha LMS we usually recommend the server RAM specs be increased - to handle the additional processing . However, we would really appreciate any assistance or suggestions from others in the community! Thanks very much in advance, Alex |
From: Alex B. <ale...@ca...> - 2024-03-08 08:58:11
|
Hi VuFind community, We have a partner library (using VuFind integrated with Koha) with approximately 40 print journal bibliographic records with a large number of item records attached. They find that when they view these journal bibliographic records they encounter a gateway timeout - see attached screenshot. Here are some more details about this timeout: * This gateway timeout happens on multiple environments - dev, staging and prod. So ruled out as environment specific. * The gateway timeout does not happen for biblios with a smaller number of linked items. * Our partner library encounters these gateway timeouts everytime they try to load the journal biblios - when we (Catalyst staff) try to access those records the timeout is intermittent. Has anyone else encountered this problem when viewing biblio records with a large number of attached items (holdings)? If so, how did you fix this issue. When we encounter such issues in the Koha LMS we usually recommend the server RAM specs be increased - to handle the additional processing . However, we would really appreciate any assistance or suggestions from others in the community! Thanks very much in advance, Alex |
From: Demian K. <dem...@vi...> - 2024-02-28 12:33:12
|
Jannis, I cannot reproduce this problem in my test environment. When a record is missing, VuFind replaces it with a "Missing" record driver, and both favorite lists and the cart display it with a "Title unavailable" message. It should not cause a fatal error. Is it possible that you are seeing the problem because of some local customization or combination of non-default settings? Have you tried turning on development mode to find out exactly what the 500 error is that is being triggered? - Demian From: Ohms, Jannis <j....@tu...> Sent: Wednesday, February 28, 2024 5:39 AM To: vuf...@li... Subject: [EXTERNAL] [VuFind-Tech] Raw Hidden Filters can break Carts and Lists Hi all If a vufind_cart cookie contains a record id which is filtered out by the raw hidden filters the cart can not be opened The request /vufind/Cart/Home Returns the error code HTTP_500 This could also happen with lists stored in the db I was able to reproduce this on Vufind 8 and Vufind 5 I did not test other versions Any idea how to fix this ? Jannis Ohms Technische Universität Braunschweig Universitätsbibliothek | <i>University Library</i> Abt.: IT und Forschungsnahe Services | <i>Dep.: IT and Research Support Services</i Universitätsplatz 1, R212 38106 Braunschweig Germany Phone: +49 531 391 5027 j....@tu...<mailto:j....@tu...> www.tu-braunschweig.de/ub/<http://www.tu-braunschweig.de/ub/> |
From: Ohms, J. <j....@tu...> - 2024-02-28 12:31:24
|
Thanks this helps I will look at our customizations Von: Demian Katz <dem...@vi...> Gesendet: Mittwoch, 28. Februar 2024 13:17 An: Ohms, Jannis <j....@tu...>; vuf...@li... Betreff: RE: [EXTERNAL] [VuFind-Tech] Raw Hidden Filters can break Carts and Lists Jannis, I cannot reproduce this problem in my test environment. When a record is missing, VuFind replaces it with a "Missing" record driver, and both favorite lists and the cart display it with a "Title unavailable" message. It should not cause a fatal error. Is it possible that you are seeing the problem because of some local customization or combination of non-default settings? Have you tried turning on development mode to find out exactly what the 500 error is that is being triggered? - Demian From: Ohms, Jannis <j....@tu...<mailto:j....@tu...>> Sent: Wednesday, February 28, 2024 5:39 AM To: vuf...@li...<mailto:vuf...@li...> Subject: [EXTERNAL] [VuFind-Tech] Raw Hidden Filters can break Carts and Lists Hi all If a vufind_cart cookie contains a record id which is filtered out by the raw hidden filters the cart can not be opened The request /vufind/Cart/Home Returns the error code HTTP_500 This could also happen with lists stored in the db I was able to reproduce this on Vufind 8 and Vufind 5 I did not test other versions Any idea how to fix this ? Jannis Ohms Technische Universität Braunschweig Universitätsbibliothek | <i>University Library</i> Abt.: IT und Forschungsnahe Services | <i>Dep.: IT and Research Support Services</i Universitätsplatz 1, R212 38106 Braunschweig Germany Phone: +49 531 391 5027 j....@tu...<mailto:j....@tu...> www.tu-braunschweig.de/ub/<http://www.tu-braunschweig.de/ub/> |
From: Ohms, J. <j....@tu...> - 2024-02-28 10:55:17
|
Hi all If a vufind_cart cookie contains a record id which is filtered out by the raw hidden filters the cart can not be opened The request /vufind/Cart/Home Returns the error code HTTP_500 This could also happen with lists stored in the db I was able to reproduce this on Vufind 8 and Vufind 5 I did not test other versions Any idea how to fix this ? Jannis Ohms Technische Universität Braunschweig Universitätsbibliothek | <i>University Library</i> Abt.: IT und Forschungsnahe Services | <i>Dep.: IT and Research Support Services</i Universitätsplatz 1, R212 38106 Braunschweig Germany Phone: +49 531 391 5027 j....@tu...<mailto:j....@tu...> www.tu-braunschweig.de/ub/<http://www.tu-braunschweig.de/ub/> |
From: Demian K. <dem...@vi...> - 2024-02-27 14:20:36
|
Hello, everyone! The February, 2024 VuFind® newsletter has just been published: https://vufind.org/wiki/community:newsletter:2024-02 Additionally, the next Community Call will be held on Tuesday, March 5, 2024 at 9am Eastern Standard Time (14:00 GMT). Here is the full agenda: 1. Development Planning * Newsletter Highlights * Release 9.1.1 * Release 10.0 Release Date * Pull Request / JIRA Ticket Review (release 10.0) 2. Technical Discussion: Theme Development Next Steps / Collaboration 3. Technical Discussion: Javascript Unit Testing? 4. Future of Slack 5. Daylight Saving Reminder 6. Open Q&A / Other Topics? All are welcome to join the free online call, or to suggest additional agenda items. You can find information on joining here: https://vufind.org/wiki/community_call See you next month! - Demian |
From: Demian K. <dem...@vi...> - 2024-02-22 15:59:26
|
Great! And in the meantime, the proposed solution has been approved and merged, so it should be safe for you to try if you wish to backport it. - Demian From: Ahrens, Helge <Hel...@ul...> Sent: Thursday, February 22, 2024 10:52 AM To: Demian Katz <dem...@vi...>; vuf...@li... Subject: AW: [VuFind-Tech] [EXTERNAL] Problem with debug=true Parameter - VuFind8.1 Dear Demian, thank you very much for your deep investigation, I’ll be able to check it out tomorrow ☺ Best wishes Helge Von: Demian Katz <dem...@vi...<mailto:dem...@vi...>> Gesendet: Mittwoch, 21. Februar 2024 21:54 An: Demian Katz <dem...@vi...<mailto:dem...@vi...>>; Ahrens, Helge <Hel...@ul...<mailto:Hel...@ul...>>; vuf...@li...<mailto:vuf...@li...> Betreff: RE: [VuFind-Tech] [EXTERNAL] Problem with debug=true Parameter - VuFind8.1 Okay, I think this solution should help: https://github.com/vufind-org/vufind/pull/3434 It still requires review by others, so you might want to wait and see if any concerns are raised before adopting it as your fix… but hopefully it’s a start at least! - Demian From: Demian Katz via Vufind-tech <vuf...@li...<mailto:vuf...@li...>> Sent: Wednesday, February 21, 2024 1:29 PM To: Ahrens, Helge <Hel...@ul...<mailto:Hel...@ul...>>; vuf...@li...<mailto:vuf...@li...> Subject: Re: [VuFind-Tech] [EXTERNAL] Problem with debug=true Parameter - VuFind8.1 Okay, I’ve identified the culprit but don’t have time to think about a fix yet – we seem to have a circular dependency: https://github.com/vufind-org/vufind/blob/dev/module/VuFind/src/VuFind/Log/LoggerFactory.php#L244 The LoggerFactory does a permission check to see if dynamic debug mode is turned on… but the permission handlers require the logger. This is causing an uninitialized logger to get used, triggering the error you see. I suspect this will be a bit tricky to solve, and it may require refactoring the permission check to a different place. - Demian From: Demian Katz Sent: Wednesday, February 21, 2024 12:57 PM To: Demian Katz <dem...@vi...<mailto:dem...@vi...>>; Ahrens, Helge <Hel...@ul...<mailto:Hel...@ul...>>; vuf...@li...<mailto:vuf...@li...> Subject: RE: [VuFind-Tech] [EXTERNAL] Problem with debug=true Parameter - VuFind8.1 Actually, I already have a theory: the ServerParam permission handler includes some debug log calls. I bet those are triggering before the debug logger is fully configured, resulting in the error. As a short-term workaround, you can probably comment out the $this->debug() calls in https://github.com/vufind-org/vufind/blob/dev/module/VuFind/src/VuFind/Role/PermissionProvider/ServerParam.php. When time permits, I’ll see if there’s a way to make this work without compromising the logging of the permission handler. - Demian From: Demian Katz via Vufind-tech <vuf...@li...<mailto:vuf...@li...>> Sent: Wednesday, February 21, 2024 12:55 PM To: Ahrens, Helge <Hel...@ul...<mailto:Hel...@ul...>>; vuf...@li...<mailto:vuf...@li...> Subject: Re: [VuFind-Tech] [EXTERNAL] Problem with debug=true Parameter - VuFind8.1 Helge, I was able to reproduce the problem you describe in my test environment using the latest dev code, so this problem has not been fixed yet. I think you’re using a fairly rare combination of settings, so I suspect it has never been encountered before. I’m a bit short on time today, but I’ll investigate in more detail as soon as time permits. This is rather puzzling at first glance, but since it can be reproduced, I’m sure it can also be figured out and fixed. 😊 - Demian From: Ahrens, Helge <Hel...@ul...<mailto:Hel...@ul...>> Sent: Wednesday, February 21, 2024 12:18 PM To: vuf...@li...<mailto:vuf...@li...> Subject: [EXTERNAL] [VuFind-Tech] Problem with debug=true Parameter - VuFind8.1 Dear group, I’m facing a small but annoying problem. Since I set-up a serverParam[] = “KEY value” in permissions.ini for [api.SearchAndRecord] with permission[] = access.api.Search and permission[] = access.api.Record I can’t use the debug=true Get parameter anymore. If I add the parameter to our VuFind URLs the loggings in vufind.log are missing and on the website I get the error screen “System Under Maintenace”. If I try it on our test-system at least in “Search/Results” I get “Laminas\Log\ Exception\RuntimeException: No log writer specified” from https://github.com/vufind-org/vufind/blob/156b6f950b59f4f9bd1a25999cfefd9a342d8fdf/module/VuFind/src/VuFind/Role/PermissionProvider/ServerParam.php#L100 Is that already fixed or new to you? Best wishes Helge |