You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(31) |
Nov
(25) |
Dec
(33) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(48) |
Feb
(62) |
Mar
(22) |
Apr
(29) |
May
(9) |
Jun
(45) |
Jul
(28) |
Aug
(41) |
Sep
(60) |
Oct
(96) |
Nov
(99) |
Dec
(70) |
2003 |
Jan
(98) |
Feb
(159) |
Mar
(164) |
Apr
(150) |
May
(143) |
Jun
(97) |
Jul
(184) |
Aug
(143) |
Sep
(207) |
Oct
(126) |
Nov
(159) |
Dec
(165) |
2004 |
Jan
(131) |
Feb
(229) |
Mar
(220) |
Apr
(212) |
May
(320) |
Jun
(223) |
Jul
(191) |
Aug
(390) |
Sep
(261) |
Oct
(229) |
Nov
(215) |
Dec
(184) |
2005 |
Jan
(221) |
Feb
(312) |
Mar
(336) |
Apr
(273) |
May
(359) |
Jun
(277) |
Jul
(303) |
Aug
(321) |
Sep
(256) |
Oct
(415) |
Nov
(428) |
Dec
(508) |
2006 |
Jan
(585) |
Feb
(419) |
Mar
(496) |
Apr
(296) |
May
(403) |
Jun
(404) |
Jul
(553) |
Aug
(296) |
Sep
(252) |
Oct
(416) |
Nov
(414) |
Dec
(245) |
2007 |
Jan
(354) |
Feb
(422) |
Mar
(389) |
Apr
(298) |
May
(397) |
Jun
(318) |
Jul
(315) |
Aug
(339) |
Sep
(253) |
Oct
(317) |
Nov
(350) |
Dec
(264) |
2008 |
Jan
(353) |
Feb
(313) |
Mar
(433) |
Apr
(383) |
May
(343) |
Jun
(355) |
Jul
(321) |
Aug
(338) |
Sep
(242) |
Oct
(206) |
Nov
(199) |
Dec
(279) |
2009 |
Jan
(327) |
Feb
(221) |
Mar
(280) |
Apr
(278) |
May
(237) |
Jun
(345) |
Jul
(322) |
Aug
(324) |
Sep
(676) |
Oct
(586) |
Nov
(735) |
Dec
(329) |
2010 |
Jan
(619) |
Feb
(424) |
Mar
(529) |
Apr
(241) |
May
(312) |
Jun
(554) |
Jul
(698) |
Aug
(576) |
Sep
(408) |
Oct
(268) |
Nov
(391) |
Dec
(426) |
2011 |
Jan
(629) |
Feb
(512) |
Mar
(465) |
Apr
(467) |
May
(475) |
Jun
(403) |
Jul
(426) |
Aug
(542) |
Sep
(418) |
Oct
(620) |
Nov
(614) |
Dec
(358) |
2012 |
Jan
(357) |
Feb
(466) |
Mar
(344) |
Apr
(215) |
May
(408) |
Jun
(375) |
Jul
(241) |
Aug
(260) |
Sep
(401) |
Oct
(461) |
Nov
(498) |
Dec
(294) |
2013 |
Jan
(453) |
Feb
(447) |
Mar
(434) |
Apr
(326) |
May
(295) |
Jun
(471) |
Jul
(463) |
Aug
(278) |
Sep
(525) |
Oct
(343) |
Nov
(389) |
Dec
(405) |
2014 |
Jan
(564) |
Feb
(324) |
Mar
(319) |
Apr
(319) |
May
(384) |
Jun
(259) |
Jul
(210) |
Aug
(219) |
Sep
(315) |
Oct
(478) |
Nov
(207) |
Dec
(316) |
2015 |
Jan
(222) |
Feb
(234) |
Mar
(201) |
Apr
(145) |
May
(367) |
Jun
(318) |
Jul
(195) |
Aug
(210) |
Sep
(234) |
Oct
(248) |
Nov
(217) |
Dec
(189) |
2016 |
Jan
(219) |
Feb
(177) |
Mar
(110) |
Apr
(91) |
May
(159) |
Jun
(124) |
Jul
(192) |
Aug
(119) |
Sep
(125) |
Oct
(64) |
Nov
(80) |
Dec
(68) |
2017 |
Jan
(156) |
Feb
(312) |
Mar
(386) |
Apr
(217) |
May
(89) |
Jun
(115) |
Jul
(79) |
Aug
(122) |
Sep
(100) |
Oct
(99) |
Nov
(129) |
Dec
(77) |
2018 |
Jan
(106) |
Feb
(78) |
Mar
(160) |
Apr
(73) |
May
(110) |
Jun
(160) |
Jul
(93) |
Aug
(92) |
Sep
(75) |
Oct
(147) |
Nov
(114) |
Dec
(97) |
2019 |
Jan
(141) |
Feb
(78) |
Mar
(158) |
Apr
(60) |
May
(123) |
Jun
(54) |
Jul
(44) |
Aug
(147) |
Sep
(117) |
Oct
(54) |
Nov
(74) |
Dec
(96) |
2020 |
Jan
(113) |
Feb
(125) |
Mar
(142) |
Apr
(57) |
May
(71) |
Jun
(99) |
Jul
(58) |
Aug
(81) |
Sep
(49) |
Oct
(50) |
Nov
(63) |
Dec
(37) |
2021 |
Jan
(37) |
Feb
(45) |
Mar
(39) |
Apr
(18) |
May
(14) |
Jun
(9) |
Jul
(44) |
Aug
(23) |
Sep
(13) |
Oct
(31) |
Nov
(13) |
Dec
(33) |
2022 |
Jan
(17) |
Feb
(8) |
Mar
(32) |
Apr
(7) |
May
(17) |
Jun
(7) |
Jul
(36) |
Aug
(29) |
Sep
(9) |
Oct
(20) |
Nov
(10) |
Dec
(1) |
2023 |
Jan
(30) |
Feb
(37) |
Mar
(23) |
Apr
(1) |
May
(14) |
Jun
(5) |
Jul
(3) |
Aug
(6) |
Sep
(5) |
Oct
(48) |
Nov
(4) |
Dec
(29) |
2024 |
Jan
(1) |
Feb
|
Mar
(21) |
Apr
(6) |
May
(16) |
Jun
(41) |
Jul
(11) |
Aug
(17) |
Sep
(16) |
Oct
(11) |
Nov
(3) |
Dec
(9) |
2025 |
Jan
(7) |
Feb
(7) |
Mar
(6) |
Apr
(6) |
May
(30) |
Jun
(8) |
Jul
(10) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
From: John P. <jpr...@ho...> - 2021-03-07 07:07:10
|
Joe requested my JDK: it is javac 1.8.0_121 Regards, John Preimonas M: 0478936636 jpr...@ho... The exhilaration of flying is too keen, the pleasure too great, for it to be neglected as a sport.— Orville Wright > On 6 Mar 2021, at 10:33 pm, exi...@li... wrote: > > Send Exist-open mailing list submissions to > exi...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/exist-open > or, via email, send a message with subject or body 'help' to > exi...@li... > > You can reach the person managing the list at > exi...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Exist-open digest..." > > > Today's Topics: > > 1. Exception Stacktrace message (John Preimonas) > 2. Re: Recommended IDE for eXist-db development (Dannes Wessels) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 6 Mar 2021 14:57:45 +1000 > From: John Preimonas <jpr...@ho...> > To: exist-open <exi...@li...> > Subject: [Exist-open] Exception Stacktrace message > Message-ID: > <PSX...@PS...> > > Content-Type: text/plain; charset="us-ascii" > > Hello exist-open folk, > Why do I constantly get the following message when I am in Java Admin Client, deleting files: > > org.xmldb.api.base.XMLDBException: > at org.exist.xmldb.RemoteCollection.execute(RemoteCollection.java:122) > at org.exist.xmldb.RemoteCollection.listChildCollections(RemoteCollection.java:306) > at org.exist.client.InteractiveClient.getResources(InteractiveClient.java:369) > at org.exist.client.ClientFrame.lambda$33(ClientFrame.java:753) > at java.lang.Thread.run(Thread.java:748) > The file is still deleted, because I see that it is gone after a refresh. > Is there a setting I need to set to cease receiving this message? > > Also, why does existdb server stop functioning after 10 or so hours of inactivity (e.g. overnight). I need to close it down and restart existdb again? > > I am using existdb v5.2.0 on macOS Big Sur v11.2.2, > > Regards, > John Preimonas > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 2 > Date: Sat, 6 Mar 2021 10:07:53 +0100 > From: Dannes Wessels <di...@ex...> > To: Jo Calder <Jo....@ha...> > Cc: Exi...@li... > Subject: Re: [Exist-open] Recommended IDE for eXist-db development > Message-ID: <CDC...@ex...> > Content-Type: text/plain; charset=utf-8 > > Hi, > > In the past we maintained the Netbeans project file pretty well; that was needed as we were using ant as build tool and there was no convention for the sources layout. > > These days we build using maven (look for Pom.xml), which makes life much easier: as long your IDE supports maven, it is possible to develop! > > Netbeans wil perfectly work I expect, most of us use IntelliJ these days. > > Regards > > Dannes > > >> On 2 Mar 2021, at 15:42, Jo Calder <Jo....@ha...> wrote: >> >> ? >> Hi all, >> >> I think I recall NetBeans as being the IDE of choice for eXist dev work. Is that so? I have a specific interest in writing Java extension code for XQuery modules. >> >> Best regards, -- Jo >> >> >> _______________________________________________ >> Exist-open mailing list >> Exi...@li... >> https://lists.sourceforge.net/lists/listinfo/exist-open > > > > ------------------------------ > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open > > > ------------------------------ > > End of Exist-open Digest, Vol 179, Issue 6 > ****************************************** |
From: Joe W. <jo...@gm...> - 2021-03-06 13:47:08
|
Which JDK? On Fri, Mar 5, 2021 at 11:59 PM John Preimonas <jpr...@ho...> wrote: > Hello exist-open folk, > Why do I constantly get the following message when I am in Java Admin > Client, deleting files: > > org.xmldb.api.base.XMLDBException: > at org.exist.xmldb.RemoteCollection.execute(RemoteCollection.java:122) > at > org.exist.xmldb.RemoteCollection.listChildCollections(RemoteCollection.java:306) > at > org.exist.client.InteractiveClient.getResources(InteractiveClient.java:369) > at org.exist.client.ClientFrame.lambda$33(ClientFrame.java:753) > at java.lang.Thread.run(Thread.java:748) > > > The file is still deleted, because I see that it is gone after a refresh. > Is there a setting I need to set to cease receiving this message? > > Also, why does existdb server stop functioning after 10 or so hours of > inactivity (e.g. overnight). I need to close it down and restart existdb > again? > > I am using existdb v5.2.0 on macOS Big Sur v11.2.2, > > Regards, > John Preimonas > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open > -- Sent from my iPhone |
From: Dannes W. <di...@ex...> - 2021-03-06 09:08:20
|
Hi, In the past we maintained the Netbeans project file pretty well; that was needed as we were using ant as build tool and there was no convention for the sources layout. These days we build using maven (look for Pom.xml), which makes life much easier: as long your IDE supports maven, it is possible to develop! Netbeans wil perfectly work I expect, most of us use IntelliJ these days. Regards Dannes > On 2 Mar 2021, at 15:42, Jo Calder <Jo....@ha...> wrote: > > > Hi all, > > I think I recall NetBeans as being the IDE of choice for eXist dev work. Is that so? I have a specific interest in writing Java extension code for XQuery modules. > > Best regards, -- Jo > > > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open |
From: John P. <jpr...@ho...> - 2021-03-06 04:58:16
|
Hello exist-open folk, Why do I constantly get the following message when I am in Java Admin Client, deleting files: org.xmldb.api.base.XMLDBException: at org.exist.xmldb.RemoteCollection.execute(RemoteCollection.java:122) at org.exist.xmldb.RemoteCollection.listChildCollections(RemoteCollection.java:306) at org.exist.client.InteractiveClient.getResources(InteractiveClient.java:369) at org.exist.client.ClientFrame.lambda$33(ClientFrame.java:753) at java.lang.Thread.run(Thread.java:748) The file is still deleted, because I see that it is gone after a refresh. Is there a setting I need to set to cease receiving this message? Also, why does existdb server stop functioning after 10 or so hours of inactivity (e.g. overnight). I need to close it down and restart existdb again? I am using existdb v5.2.0 on macOS Big Sur v11.2.2, Regards, John Preimonas |
From: Andreas W. <And...@em...> - 2021-03-03 08:48:34
|
hi all, this is so embarrassing - I was sooo determined to give you prompt feedback this time and yet I allowed this to be drowned in so much other stuff. I am truly sorry for being what we call "stoffelig" in German. * Alasdair Dougall dixit [2021-02-17 22:38]: > As Wolfgang said, range:match will work.I use them in one of my > functions, and it works really well and it is quick. I just wanted to say that, yes, range:match is working perfectly in our case. It seems we don't fall into the unsupported features category after all. Thank you a lot for your suggestion, Wolfgang and Alasdair! Best wishes to all, Andreas -- Dr. Andreas Wagner twitter: @anwagnerdreas Project "The School of Salamanca" web: http://salamanca.adwmainz.de Academy of Sciences and Literature, Mainz fon: +49 (0)69/798-32774 and Institute of Philosophy fax: +49 (0)69/798-32794 Goethe University Frankfurt IGF HP 25 / R 2.455 Norbert-Wollheim-Platz 1 60629 Frankfurt am Main |
From: Winona S. <wsa...@gm...> - 2021-03-02 17:16:18
|
Thanks Duncan, We are giving these a try today to see if we can sort this out. Your tips have been very helpful. -Winona On Mon, Mar 1, 2021 at 10:32 AM Duncan Paterson <du...@ex...> wrote: > HI, > > so from your responses I m still curious about the arguments used to start > and set the memory allocation of the containers. I’ve recently had the > chance to debug a clients app and test this part intensively (nothing like > a reproducer) dynamic memory allocation worked great, so did recovering > from crashes. > > There are essentially two immediate options: > 1) Killer Query / memory leak > > the instances a container will start eating over 10 GB > > sounds like that. Nothing to do with the orchestration, just plain old > programming error, or adventurous users. Check with latest and the logs to > see if there is a bad query or a hopefully fixed memory-leak. > > 2) ECS is stumbling when trying to reallocate memory leading to stuck > memory. Basically the external commands to the container, and its internal > reporting are out of sync. To test that you can run a single container in a > minimum memory environment locally do some light browsing / editing, if you > see crashes or runaway memory allocation that’s your problem. You need to > adjust the start commands (i.e. modify or override JAVA_TOOL_OPTIONS) to > your deployment scenario. Adjusting, e.g. > > -XX:MaxRAMFraction=1 > > to 2, should ensure that no internal external conflicts are occurring. You > can then continue to play with other commands to tweak it more, or this > might already be a suitable solutions to your problem, depending on your > overall load profile. > > If none of that helps, I’d need to take a deeper look into your system, as > part of a proper consultancy arrangement. I m very short on time at the > moment. > > Hope that helps > Duncan > > > > > Ceterum censeo exist-db.org esse conriganda > > > > On 1. Mar 2021, at 16:09, Woods, Jonathan <jon...@Va...> > wrote: > > Hey! > > I didn’t get that email. Not sure I get the replies. > > There aren’t 7 instances. There are 2 instances that are running 7/8 task > within ECS. Each service runs one task for the container. The containers > themselves aren’t dependent on each other. They all live within the same > network (VPC), but that is it. For memory allocations, I don’t have max > (aka – hard) limits on the containers. This allow the containers to use > whatever memory they need. The instance the containers are running on are > running out of memory, yes, but in theory there are 4 containers running on > a 16 GB instance and while monitoring the instances a container will start > eating over 10 GB of memory causing it to max out and then restart the > container. As for storage, we are using the rexray plug-in to have > consistent storage for the containers. We allocated 30 GB for each > container and they aren’t even close to utilizing that space. > > Hopefully that makes sense. > > *Jonathan Woods* > Cloud Engineer, Cloud Services > Information Technology | Vanderbilt University > > *From:* Winona Salesky <wsa...@gm...> > *Sent:* Monday, March 1, 2021 9:05 AM > *To:* Duncan Paterson <du...@ex...> > *Cc:* exist-open <exi...@li...>; Woods, Jonathan < > jon...@Va...> > *Subject:* Re: [Exist-open] Running eXist-db Docker containers on AWS > (Winona Salesky) > > Hi Duncan, > Thanks for getting back to me, I missed this over the weekend, so sorry > for the delay in responding. I'm looping in Jonathan Woods on this email as > he has handled the AWS installations. > Here is my understanding of our set up: > 1. The 7 instances run permanently > 2. There are no cross-dependencies between the containers. > Jonathan, perhaps you can answer the other questions having to do with > memory? > > I have not yet tried running them on :latest, as I was hoping to hold out > until the next official release, perhaps I will give it a try and see if it > addresses any issues. > > Thanks for your help, > -Winona > > > > On Sat, Feb 27, 2021 at 7:47 AM Duncan Paterson <du...@ex...> > wrote: > > Hi Winona, > > i m afraid the topology isn’t quite clear to me yet, from your > description. Are all 7 instances supposed to run permanently, or on-demand? > > Are there cross-dependencies between the containers? Do they all live on > the same network? What memory arguments are you using to run the > containers? What are the max and min memory allocations per container? > Are they running out of memory due to something that happens inside exist, > or due to ECS memory reallocations? > The logs you shared on slack actually look more like there is an IO issues > with disk spaces, what do the logs say that make you think its memory > related? > > Have you tried to switch to :latest as many bug fixes are in > 5.3.0-SNAPSHOT to see if the problem persists there? Are you provisioning > your own base images? > > Greetings > Duncan > > > > We are moving our eXist-db v5.2 based applications to AWS using docker and > are experiencing some performance issues. > > We have an ECS cluster running two t3a.xlarge which have 16gb, each. The > ECS service/task are running on a spread deployment where it tries to load > each task/container evenly between the nodes. We are running 7 eXist-db > based docker images. > > The apps all start out running fine, but eventually run out of memory, > which can cause an unclean shutdown. This seems to happen every few days. > > Any help debugging our setup would be greatly appreciated. > Thank you, > -Winona > > Ceterum censeo exist-db.org > <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexist-db.org%2F&data=04%7C01%7Cjonathan.woods%40vanderbilt.edu%7C87ff6a1d6b4c4b18eb1108d8dcc35861%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C0%7C637502078853258332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=szkt1r50J%2BPNwd4oMtGfOpi5Wp3Pm3aZ7xMElJEXJA8%3D&reserved=0> > esse conriganda > > > > > > > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fexist-open&data=04%7C01%7Cjonathan.woods%40vanderbilt.edu%7C87ff6a1d6b4c4b18eb1108d8dcc35861%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C0%7C637502078853258332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LEDbYsD8a6xTqe39I4QpMF%2FsTYni85z%2FTTKwMZTQbtA%3D&reserved=0> > > > |
From: Jo C. <Jo....@ha...> - 2021-03-02 14:41:41
|
Hi all, I think I recall NetBeans as being the IDE of choice for eXist dev work. Is that so? I have a specific interest in writing Java extension code for XQuery modules. Best regards, -- Jo |
From: Craig B. <cra...@ma...> - 2021-03-02 13:27:24
|
> On Mar 1, 2021, at 8:25 AM, Ihe Onwuka <ihe...@gm...> wrote: > > Great. So how do I install that? As I said up-thread, "So you could try building that and then just installing the resulting XAR via package manager like you would do for any locally-developed package." Since it has a build.xml, you will likely need to build it with ant by typing "ant" at the command line of a local copy of the repository. If all goes well, you should get a file with a .xar extension in the build/ subdirectory. Click on the Upload button in Package Manager and select that file to install it. > > On Mon, Mar 1, 2021 at 8:58 AM Craig Berry <cra...@ma...> wrote: > On Mar 1, 2021, at 6:57 AM, Ihe Onwuka <ihe...@gm...> wrote: > > > > Craig the package installed XSLTForms rev 594, the one you linked to is rev 565. > > Using that versioning scheme, the one I linked to is 652. See: > > <https://github.com/eXist-db/xsltforms-xar/commit/6423aef11a73988202807a8fab302553a1c31d71> > > I don't know why there are two versioning schemes or why there are a variety of inconsistent version numbers scattered throughout the project's build files. > > > > > On Mon, Mar 1, 2021 at 7:52 AM Craig Berry <cra...@ma...> wrote: > > > > > > > On Mar 1, 2021, at 12:43 AM, Ihe Onwuka <ihe...@gm...> wrote: > > > > > > That's older than what the package installed. I think I need at least 629 because that's when support for AVT's came in. > > > > Version 1.3 is not older than version 0.1 in any versioning scheme I've ever seen. > > > > > > > > On Sun, Feb 28, 2021 at 6:51 PM Craig Berry via Exist-open <exi...@li...> wrote: > > > > > > > On Feb 26, 2021, at 9:27 AM, Ihe Onwuka <ihe...@gm...> wrote: > > > > > > > > Next question. How do I upgrade to a more recent XSLTForms release - at least 629 rather than 594 which is on the package. > > > > > > Never used it myself, but it looks like what's available online via Package Manger is from 2014, i.e., a very old version. It lists both 565 and 0.1 as its version numbers, which sound like Subversion revision number and actual version number, respectively. My guess would be that the repository from which that package is built is no longer maintained. > > > > > > There appears to be a repository here: > > > > > > https://github.com/eXist-db/xsltforms-xar > > > > > > that has version 1.3. So you could try building that and then just installing the resulting XAR via package manager like you would do for any locally-developed package. > > > > > > I don't know who owns the exist-db.org/apps extension delivery mechanism or why it would be serving such an old version. > > > > > > > > > ________________________________________ > > > Craig A. Berry > > > > > > "... getting out of a sonnet is much more > > > difficult than getting in." > > > Brad Leithauser > > > > > > > > > > > > _______________________________________________ > > > Exist-open mailing list > > > Exi...@li... > > > https://lists.sourceforge.net/lists/listinfo/exist-open > > > > ________________________________________ > > Craig A. Berry > > > > "... getting out of a sonnet is much more > > difficult than getting in." > > Brad Leithauser > > > > ________________________________________ > Craig A. Berry > > "... getting out of a sonnet is much more > difficult than getting in." > Brad Leithauser > ________________________________________ Craig A. Berry "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser |
From: Duncan P. <du...@ex...> - 2021-03-01 15:32:49
|
HI, so from your responses I m still curious about the arguments used to start and set the memory allocation of the containers. I’ve recently had the chance to debug a clients app and test this part intensively (nothing like a reproducer) dynamic memory allocation worked great, so did recovering from crashes. There are essentially two immediate options: 1) Killer Query / memory leak > the instances a container will start eating over 10 GB sounds like that. Nothing to do with the orchestration, just plain old programming error, or adventurous users. Check with latest and the logs to see if there is a bad query or a hopefully fixed memory-leak. 2) ECS is stumbling when trying to reallocate memory leading to stuck memory. Basically the external commands to the container, and its internal reporting are out of sync. To test that you can run a single container in a minimum memory environment locally do some light browsing / editing, if you see crashes or runaway memory allocation that’s your problem. You need to adjust the start commands (i.e. modify or override JAVA_TOOL_OPTIONS) to your deployment scenario. Adjusting, e.g. > -XX:MaxRAMFraction=1 to 2, should ensure that no internal external conflicts are occurring. You can then continue to play with other commands to tweak it more, or this might already be a suitable solutions to your problem, depending on your overall load profile. If none of that helps, I’d need to take a deeper look into your system, as part of a proper consultancy arrangement. I m very short on time at the moment. Hope that helps Duncan Ceterum censeo exist-db.org esse conriganda > On 1. Mar 2021, at 16:09, Woods, Jonathan <jon...@Va...> wrote: > > Hey! > > I didn’t get that email. Not sure I get the replies. > > There aren’t 7 instances. There are 2 instances that are running 7/8 task within ECS. Each service runs one task for the container. The containers themselves aren’t dependent on each other. They all live within the same network (VPC), but that is it. For memory allocations, I don’t have max (aka – hard) limits on the containers. This allow the containers to use whatever memory they need. The instance the containers are running on are running out of memory, yes, but in theory there are 4 containers running on a 16 GB instance and while monitoring the instances a container will start eating over 10 GB of memory causing it to max out and then restart the container. As for storage, we are using the rexray plug-in to have consistent storage for the containers. We allocated 30 GB for each container and they aren’t even close to utilizing that space. > > Hopefully that makes sense. > > Jonathan Woods > Cloud Engineer, Cloud Services > Information Technology | Vanderbilt University > > From: Winona Salesky <wsa...@gm...> > Sent: Monday, March 1, 2021 9:05 AM > To: Duncan Paterson <du...@ex...> > Cc: exist-open <exi...@li...>; Woods, Jonathan <jon...@Va...> > Subject: Re: [Exist-open] Running eXist-db Docker containers on AWS (Winona Salesky) > > Hi Duncan, > Thanks for getting back to me, I missed this over the weekend, so sorry for the delay in responding. I'm looping in Jonathan Woods on this email as he has handled the AWS installations. > Here is my understanding of our set up: > 1. The 7 instances run permanently > 2. There are no cross-dependencies between the containers. > Jonathan, perhaps you can answer the other questions having to do with memory? > > I have not yet tried running them on :latest, as I was hoping to hold out until the next official release, perhaps I will give it a try and see if it addresses any issues. > > Thanks for your help, > -Winona > > > > On Sat, Feb 27, 2021 at 7:47 AM Duncan Paterson <du...@ex... <mailto:du...@ex...>> wrote: > Hi Winona, > > i m afraid the topology isn’t quite clear to me yet, from your description. Are all 7 instances supposed to run permanently, or on-demand? > Are there cross-dependencies between the containers? Do they all live on the same network? What memory arguments are you using to run the containers? What are the max and min memory allocations per container? > Are they running out of memory due to something that happens inside exist, or due to ECS memory reallocations? > The logs you shared on slack actually look more like there is an IO issues with disk spaces, what do the logs say that make you think its memory related? > > Have you tried to switch to :latest as many bug fixes are in 5.3.0-SNAPSHOT to see if the problem persists there? Are you provisioning your own base images? > > Greetings > Duncan > > > > We are moving our eXist-db v5.2 based applications to AWS using docker and > are experiencing some performance issues. > > We have an ECS cluster running two t3a.xlarge which have 16gb, each. The > ECS service/task are running on a spread deployment where it tries to load > each task/container evenly between the nodes. We are running 7 eXist-db > based docker images. > > The apps all start out running fine, but eventually run out of memory, > which can cause an unclean shutdown. This seems to happen every few days. > > Any help debugging our setup would be greatly appreciated. > Thank you, > -Winona > > Ceterum censeo exist-db.org <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexist-db.org%2F&data=04%7C01%7Cjonathan.woods%40vanderbilt.edu%7C87ff6a1d6b4c4b18eb1108d8dcc35861%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C0%7C637502078853258332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=szkt1r50J%2BPNwd4oMtGfOpi5Wp3Pm3aZ7xMElJEXJA8%3D&reserved=0> esse conriganda > > > > > > > _______________________________________________ > Exist-open mailing list > Exi...@li... <mailto:Exi...@li...> > https://lists.sourceforge.net/lists/listinfo/exist-open <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fexist-open&data=04%7C01%7Cjonathan.woods%40vanderbilt.edu%7C87ff6a1d6b4c4b18eb1108d8dcc35861%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C0%7C637502078853258332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LEDbYsD8a6xTqe39I4QpMF%2FsTYni85z%2FTTKwMZTQbtA%3D&reserved=0> |
From: Winona S. <wsa...@gm...> - 2021-03-01 15:04:51
|
Hi Duncan, Thanks for getting back to me, I missed this over the weekend, so sorry for the delay in responding. I'm looping in Jonathan Woods on this email as he has handled the AWS installations. Here is my understanding of our set up: 1. The 7 instances run permanently 2. There are no cross-dependencies between the containers. Jonathan, perhaps you can answer the other questions having to do with memory? I have not yet tried running them on :latest, as I was hoping to hold out until the next official release, perhaps I will give it a try and see if it addresses any issues. Thanks for your help, -Winona On Sat, Feb 27, 2021 at 7:47 AM Duncan Paterson <du...@ex...> wrote: > Hi Winona, > > i m afraid the topology isn’t quite clear to me yet, from your > description. Are all 7 instances supposed to run permanently, or on-demand? > Are there cross-dependencies between the containers? Do they all live on > the same network? What memory arguments are you using to run the > containers? What are the max and min memory allocations per container? > Are they running out of memory due to something that happens inside exist, > or due to ECS memory reallocations? > The logs you shared on slack actually look more like there is an IO issues > with disk spaces, what do the logs say that make you think its memory > related? > > Have you tried to switch to :latest as many bug fixes are in > 5.3.0-SNAPSHOT to see if the problem persists there? Are you provisioning > your own base images? > > Greetings > Duncan > > > > We are moving our eXist-db v5.2 based applications to AWS using docker and > are experiencing some performance issues. > > We have an ECS cluster running two t3a.xlarge which have 16gb, each. The > ECS service/task are running on a spread deployment where it tries to load > each task/container evenly between the nodes. We are running 7 eXist-db > based docker images. > > The apps all start out running fine, but eventually run out of memory, > which can cause an unclean shutdown. This seems to happen every few days. > > Any help debugging our setup would be greatly appreciated. > Thank you, > -Winona > > Ceterum censeo exist-db.org esse conriganda > > > > > > > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open > |
From: Ihe O. <ihe...@gm...> - 2021-03-01 14:25:45
|
Great. So how do I install that? On Mon, Mar 1, 2021 at 8:58 AM Craig Berry <cra...@ma...> wrote: > On Mar 1, 2021, at 6:57 AM, Ihe Onwuka <ihe...@gm...> wrote: > > > > Craig the package installed XSLTForms rev 594, the one you linked to is > rev 565. > > Using that versioning scheme, the one I linked to is 652. See: > > < > https://github.com/eXist-db/xsltforms-xar/commit/6423aef11a73988202807a8fab302553a1c31d71 > > > > I don't know why there are two versioning schemes or why there are a > variety of inconsistent version numbers scattered throughout the project's > build files. > > > > > On Mon, Mar 1, 2021 at 7:52 AM Craig Berry <cra...@ma...> wrote: > > > > > > > On Mar 1, 2021, at 12:43 AM, Ihe Onwuka <ihe...@gm...> wrote: > > > > > > That's older than what the package installed. I think I need at least > 629 because that's when support for AVT's came in. > > > > Version 1.3 is not older than version 0.1 in any versioning scheme I've > ever seen. > > > > > > > > On Sun, Feb 28, 2021 at 6:51 PM Craig Berry via Exist-open < > exi...@li...> wrote: > > > > > > > On Feb 26, 2021, at 9:27 AM, Ihe Onwuka <ihe...@gm...> > wrote: > > > > > > > > Next question. How do I upgrade to a more recent XSLTForms release - > at least 629 rather than 594 which is on the package. > > > > > > Never used it myself, but it looks like what's available online via > Package Manger is from 2014, i.e., a very old version. It lists both 565 > and 0.1 as its version numbers, which sound like Subversion revision number > and actual version number, respectively. My guess would be that the > repository from which that package is built is no longer maintained. > > > > > > There appears to be a repository here: > > > > > > https://github.com/eXist-db/xsltforms-xar > > > > > > that has version 1.3. So you could try building that and then just > installing the resulting XAR via package manager like you would do for any > locally-developed package. > > > > > > I don't know who owns the exist-db.org/apps extension delivery > mechanism or why it would be serving such an old version. > > > > > > > > > ________________________________________ > > > Craig A. Berry > > > > > > "... getting out of a sonnet is much more > > > difficult than getting in." > > > Brad Leithauser > > > > > > > > > > > > _______________________________________________ > > > Exist-open mailing list > > > Exi...@li... > > > https://lists.sourceforge.net/lists/listinfo/exist-open > > > > ________________________________________ > > Craig A. Berry > > > > "... getting out of a sonnet is much more > > difficult than getting in." > > Brad Leithauser > > > > ________________________________________ > Craig A. Berry > > "... getting out of a sonnet is much more > difficult than getting in." > Brad Leithauser > > |
From: Craig B. <cra...@ma...> - 2021-03-01 13:58:47
|
On Mar 1, 2021, at 6:57 AM, Ihe Onwuka <ihe...@gm...> wrote: > > Craig the package installed XSLTForms rev 594, the one you linked to is rev 565. Using that versioning scheme, the one I linked to is 652. See: <https://github.com/eXist-db/xsltforms-xar/commit/6423aef11a73988202807a8fab302553a1c31d71> I don't know why there are two versioning schemes or why there are a variety of inconsistent version numbers scattered throughout the project's build files. > > On Mon, Mar 1, 2021 at 7:52 AM Craig Berry <cra...@ma...> wrote: > > > > On Mar 1, 2021, at 12:43 AM, Ihe Onwuka <ihe...@gm...> wrote: > > > > That's older than what the package installed. I think I need at least 629 because that's when support for AVT's came in. > > Version 1.3 is not older than version 0.1 in any versioning scheme I've ever seen. > > > > > On Sun, Feb 28, 2021 at 6:51 PM Craig Berry via Exist-open <exi...@li...> wrote: > > > > > On Feb 26, 2021, at 9:27 AM, Ihe Onwuka <ihe...@gm...> wrote: > > > > > > Next question. How do I upgrade to a more recent XSLTForms release - at least 629 rather than 594 which is on the package. > > > > Never used it myself, but it looks like what's available online via Package Manger is from 2014, i.e., a very old version. It lists both 565 and 0.1 as its version numbers, which sound like Subversion revision number and actual version number, respectively. My guess would be that the repository from which that package is built is no longer maintained. > > > > There appears to be a repository here: > > > > https://github.com/eXist-db/xsltforms-xar > > > > that has version 1.3. So you could try building that and then just installing the resulting XAR via package manager like you would do for any locally-developed package. > > > > I don't know who owns the exist-db.org/apps extension delivery mechanism or why it would be serving such an old version. > > > > > > ________________________________________ > > Craig A. Berry > > > > "... getting out of a sonnet is much more > > difficult than getting in." > > Brad Leithauser > > > > > > > > _______________________________________________ > > Exist-open mailing list > > Exi...@li... > > https://lists.sourceforge.net/lists/listinfo/exist-open > > ________________________________________ > Craig A. Berry > > "... getting out of a sonnet is much more > difficult than getting in." > Brad Leithauser > ________________________________________ Craig A. Berry "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser |
From: Ihe O. <ihe...@gm...> - 2021-03-01 12:57:56
|
Craig the package installed XSLTForms rev 594, the one you linked to is rev 565. On Mon, Mar 1, 2021 at 7:52 AM Craig Berry <cra...@ma...> wrote: > > > > On Mar 1, 2021, at 12:43 AM, Ihe Onwuka <ihe...@gm...> wrote: > > > > That's older than what the package installed. I think I need at least > 629 because that's when support for AVT's came in. > > Version 1.3 is not older than version 0.1 in any versioning scheme I've > ever seen. > > > > > On Sun, Feb 28, 2021 at 6:51 PM Craig Berry via Exist-open < > exi...@li...> wrote: > > > > > On Feb 26, 2021, at 9:27 AM, Ihe Onwuka <ihe...@gm...> wrote: > > > > > > Next question. How do I upgrade to a more recent XSLTForms release - > at least 629 rather than 594 which is on the package. > > > > Never used it myself, but it looks like what's available online via > Package Manger is from 2014, i.e., a very old version. It lists both 565 > and 0.1 as its version numbers, which sound like Subversion revision number > and actual version number, respectively. My guess would be that the > repository from which that package is built is no longer maintained. > > > > There appears to be a repository here: > > > > https://github.com/eXist-db/xsltforms-xar > > > > that has version 1.3. So you could try building that and then just > installing the resulting XAR via package manager like you would do for any > locally-developed package. > > > > I don't know who owns the exist-db.org/apps extension delivery > mechanism or why it would be serving such an old version. > > > > > > ________________________________________ > > Craig A. Berry > > > > "... getting out of a sonnet is much more > > difficult than getting in." > > Brad Leithauser > > > > > > > > _______________________________________________ > > Exist-open mailing list > > Exi...@li... > > https://lists.sourceforge.net/lists/listinfo/exist-open > > ________________________________________ > Craig A. Berry > > "... getting out of a sonnet is much more > difficult than getting in." > Brad Leithauser > > |
From: Craig B. <cra...@ma...> - 2021-03-01 12:52:57
|
> On Mar 1, 2021, at 12:43 AM, Ihe Onwuka <ihe...@gm...> wrote: > > That's older than what the package installed. I think I need at least 629 because that's when support for AVT's came in. Version 1.3 is not older than version 0.1 in any versioning scheme I've ever seen. > > On Sun, Feb 28, 2021 at 6:51 PM Craig Berry via Exist-open <exi...@li...> wrote: > > > On Feb 26, 2021, at 9:27 AM, Ihe Onwuka <ihe...@gm...> wrote: > > > > Next question. How do I upgrade to a more recent XSLTForms release - at least 629 rather than 594 which is on the package. > > Never used it myself, but it looks like what's available online via Package Manger is from 2014, i.e., a very old version. It lists both 565 and 0.1 as its version numbers, which sound like Subversion revision number and actual version number, respectively. My guess would be that the repository from which that package is built is no longer maintained. > > There appears to be a repository here: > > https://github.com/eXist-db/xsltforms-xar > > that has version 1.3. So you could try building that and then just installing the resulting XAR via package manager like you would do for any locally-developed package. > > I don't know who owns the exist-db.org/apps extension delivery mechanism or why it would be serving such an old version. > > > ________________________________________ > Craig A. Berry > > "... getting out of a sonnet is much more > difficult than getting in." > Brad Leithauser > > > > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open ________________________________________ Craig A. Berry "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser |
From: Ihe O. <ihe...@gm...> - 2021-03-01 06:44:10
|
That's older than what the package installed. I think I need at least 629 because that's when support for AVT's came in. On Sun, Feb 28, 2021 at 6:51 PM Craig Berry via Exist-open < exi...@li...> wrote: > > > On Feb 26, 2021, at 9:27 AM, Ihe Onwuka <ihe...@gm...> wrote: > > > > Next question. How do I upgrade to a more recent XSLTForms release - at > least 629 rather than 594 which is on the package. > > Never used it myself, but it looks like what's available online via > Package Manger is from 2014, i.e., a very old version. It lists both 565 > and 0.1 as its version numbers, which sound like Subversion revision number > and actual version number, respectively. My guess would be that the > repository from which that package is built is no longer maintained. > > There appears to be a repository here: > > https://github.com/eXist-db/xsltforms-xar > > that has version 1.3. So you could try building that and then just > installing the resulting XAR via package manager like you would do for any > locally-developed package. > > I don't know who owns the exist-db.org/apps extension delivery mechanism > or why it would be serving such an old version. > > > ________________________________________ > Craig A. Berry > > "... getting out of a sonnet is much more > difficult than getting in." > Brad Leithauser > > > > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open > |
From: Craig B. <cra...@ma...> - 2021-02-28 23:50:14
|
> On Feb 26, 2021, at 9:27 AM, Ihe Onwuka <ihe...@gm...> wrote: > > Next question. How do I upgrade to a more recent XSLTForms release - at least 629 rather than 594 which is on the package. Never used it myself, but it looks like what's available online via Package Manger is from 2014, i.e., a very old version. It lists both 565 and 0.1 as its version numbers, which sound like Subversion revision number and actual version number, respectively. My guess would be that the repository from which that package is built is no longer maintained. There appears to be a repository here: https://github.com/eXist-db/xsltforms-xar that has version 1.3. So you could try building that and then just installing the resulting XAR via package manager like you would do for any locally-developed package. I don't know who owns the exist-db.org/apps extension delivery mechanism or why it would be serving such an old version. ________________________________________ Craig A. Berry "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser |
From: Duncan P. <du...@ex...> - 2021-02-27 12:46:25
|
Hi Winona, i m afraid the topology isn’t quite clear to me yet, from your description. Are all 7 instances supposed to run permanently, or on-demand? Are there cross-dependencies between the containers? Do they all live on the same network? What memory arguments are you using to run the containers? What are the max and min memory allocations per container? Are they running out of memory due to something that happens inside exist, or due to ECS memory reallocations? The logs you shared on slack actually look more like there is an IO issues with disk spaces, what do the logs say that make you think its memory related? Have you tried to switch to :latest as many bug fixes are in 5.3.0-SNAPSHOT to see if the problem persists there? Are you provisioning your own base images? Greetings Duncan We are moving our eXist-db v5.2 based applications to AWS using docker and are experiencing some performance issues. We have an ECS cluster running two t3a.xlarge which have 16gb, each. The ECS service/task are running on a spread deployment where it tries to load each task/container evenly between the nodes. We are running 7 eXist-db based docker images. The apps all start out running fine, but eventually run out of memory, which can cause an unclean shutdown. This seems to happen every few days. Any help debugging our setup would be greatly appreciated. Thank you, -Winona Ceterum censeo exist-db.org esse conriganda |
From: Ihe O. <ihe...@gm...> - 2021-02-26 15:27:23
|
Yeah. Logging out and back in again gave me that screen. Do you want to put that answer on SO so I can accept it. Next question. How do I upgrade to a more recent XSLTForms release - at least 629 rather than 594 which is on the package. On Fri, Feb 26, 2021 at 10:11 AM Joe Wicentowski <jo...@gm...> wrote: > Ihe, > > When logged in as admin, you should be seeing the admin view of the > dashboard, including an entry for Package Manager (see screenshot below). > Could you try logging out of the admin user and logging back in? How about > if you go directly to http://localhost:8080/exist/apps/dashboard/admin? > Do you see the left sidebar as shown in my screenshot? > > Joe > > [image: Screen Shot 2021-02-26 at 10.09.18 AM.png] > > On Fri, Feb 26, 2021 at 3:04 AM Ihe Onwuka <ihe...@gm...> wrote: > >> I am always logged in as admin. There aren't any other users set up on >> this database. This has always been the screen that I get. >> >> [image: image.png] >> >> >> >> On Thu, Feb 25, 2021 at 9:27 PM Craig Berry <cra...@ma...> wrote: >> >>> >>> >>> > On Feb 25, 2021, at 3:25 PM, Ihe Onwuka <ihe...@gm...> wrote: >>> > >>> > >>> https://stackoverflow.com/questions/66375942/installing-xsltforms-on-exist-db-5-2 >>> > >>> > Happy to take answers here too if anyone can help. >>> >>> From stackoverflow: >>> >>> > Given that the package manager is not offered on the eXist-db 5.2 >>> dashboard (at least not on mine) how does one install XSLTForms on an >>> eXist-db 5.2 installation running on an AWS EC2 instance. >>> >>> >>> But the package manager *is* offered on the 5.2 Dashboard. You do have >>> to be logged in as admin to see it. And in default 5.2 without any module >>> updates, the admin user must not be a member of any groups other than admin >>> (that and a number of other bugs in core modules have been fixed since 5.2). >>> >>> ________________________________________ >>> Craig A. Berry >>> >>> "... getting out of a sonnet is much more >>> difficult than getting in." >>> Brad Leithauser >>> >>> _______________________________________________ >> Exist-open mailing list >> Exi...@li... >> https://lists.sourceforge.net/lists/listinfo/exist-open >> > |
From: Joe W. <jo...@gm...> - 2021-02-26 15:11:30
|
Ihe, When logged in as admin, you should be seeing the admin view of the dashboard, including an entry for Package Manager (see screenshot below). Could you try logging out of the admin user and logging back in? How about if you go directly to http://localhost:8080/exist/apps/dashboard/admin? Do you see the left sidebar as shown in my screenshot? Joe [image: Screen Shot 2021-02-26 at 10.09.18 AM.png] On Fri, Feb 26, 2021 at 3:04 AM Ihe Onwuka <ihe...@gm...> wrote: > I am always logged in as admin. There aren't any other users set up on > this database. This has always been the screen that I get. > > [image: image.png] > > > > On Thu, Feb 25, 2021 at 9:27 PM Craig Berry <cra...@ma...> wrote: > >> >> >> > On Feb 25, 2021, at 3:25 PM, Ihe Onwuka <ihe...@gm...> wrote: >> > >> > >> https://stackoverflow.com/questions/66375942/installing-xsltforms-on-exist-db-5-2 >> > >> > Happy to take answers here too if anyone can help. >> >> From stackoverflow: >> >> > Given that the package manager is not offered on the eXist-db 5.2 >> dashboard (at least not on mine) how does one install XSLTForms on an >> eXist-db 5.2 installation running on an AWS EC2 instance. >> >> >> But the package manager *is* offered on the 5.2 Dashboard. You do have >> to be logged in as admin to see it. And in default 5.2 without any module >> updates, the admin user must not be a member of any groups other than admin >> (that and a number of other bugs in core modules have been fixed since 5.2). >> >> ________________________________________ >> Craig A. Berry >> >> "... getting out of a sonnet is much more >> difficult than getting in." >> Brad Leithauser >> >> _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open > |
From: Winona S. <wsa...@gm...> - 2021-02-26 15:11:25
|
We are moving our eXist-db v5.2 based applications to AWS using docker and are experiencing some performance issues. We have an ECS cluster running two t3a.xlarge which have 16gb, each. The ECS service/task are running on a spread deployment where it tries to load each task/container evenly between the nodes. We are running 7 eXist-db based docker images. The apps all start out running fine, but eventually run out of memory, which can cause an unclean shutdown. This seems to happen every few days. Any help debugging our setup would be greatly appreciated. Thank you, -Winona |
From: Ihe O. <ihe...@gm...> - 2021-02-26 08:03:27
|
I am always logged in as admin. There aren't any other users set up on this database. This has always been the screen that I get. [image: image.png] On Thu, Feb 25, 2021 at 9:27 PM Craig Berry <cra...@ma...> wrote: > > > > On Feb 25, 2021, at 3:25 PM, Ihe Onwuka <ihe...@gm...> wrote: > > > > > https://stackoverflow.com/questions/66375942/installing-xsltforms-on-exist-db-5-2 > > > > Happy to take answers here too if anyone can help. > > From stackoverflow: > > > Given that the package manager is not offered on the eXist-db 5.2 > dashboard (at least not on mine) how does one install XSLTForms on an > eXist-db 5.2 installation running on an AWS EC2 instance. > > > But the package manager *is* offered on the 5.2 Dashboard. You do have to > be logged in as admin to see it. And in default 5.2 without any module > updates, the admin user must not be a member of any groups other than admin > (that and a number of other bugs in core modules have been fixed since 5.2). > > ________________________________________ > Craig A. Berry > > "... getting out of a sonnet is much more > difficult than getting in." > Brad Leithauser > > |
From: Craig B. <cra...@ma...> - 2021-02-26 02:28:13
|
> On Feb 25, 2021, at 3:25 PM, Ihe Onwuka <ihe...@gm...> wrote: > > https://stackoverflow.com/questions/66375942/installing-xsltforms-on-exist-db-5-2 > > Happy to take answers here too if anyone can help. From stackoverflow: > Given that the package manager is not offered on the eXist-db 5.2 dashboard (at least not on mine) how does one install XSLTForms on an eXist-db 5.2 installation running on an AWS EC2 instance. But the package manager *is* offered on the 5.2 Dashboard. You do have to be logged in as admin to see it. And in default 5.2 without any module updates, the admin user must not be a member of any groups other than admin (that and a number of other bugs in core modules have been fixed since 5.2). ________________________________________ Craig A. Berry "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser |
From: Ihe O. <ihe...@gm...> - 2021-02-25 21:26:16
|
https://stackoverflow.com/questions/66375942/installing-xsltforms-on-exist-db-5-2 Happy to take answers here too if anyone can help. |
From: Kuukka-Härmä R. <Rii...@fi...> - 2021-02-22 08:03:14
|
Hello, We ended up to do clean eXist-4.7.1 db installation & restored database from backup. After that no references to multiple files, and no errors in backup report. BR, Riina From: Roy Walter <gar...@ya...> Sent: tiistai 16. helmikuuta 2021 17.09 To: Kuukka-Härmä Riina <Rii...@fi...> Cc: Exist-open <exi...@li...> Subject: Re: [Exist-open] Issue with 4.7.1 eXist DB - file Id points to two different collection files Hi, How about creating an empty file, copying the contents of one of the problem files to it and then deleting the donor file. Regards, Roy On Tuesday, 16 February 2021, 14:56:01 GMT, Kuukka-Härmä Riina <rii...@fi...<mailto:rii...@fi...>> wrote: Hello, Thank you for an answer. I tested the query setting let $id := 11240 And it returned the path to same two XML files as using search with xs:string. BR, Riina From: Michael Westbay <wes...@ja...<mailto:wes...@ja...>> Sent: tiistai 16. helmikuuta 2021 14.52 To: Kuukka-Härmä Riina <Rii...@fi...<mailto:Rii...@fi...>> Cc: Exi...@li...<mailto:Exi...@li...> Subject: Re: [Exist-open] Issue with 4.7.1 eXist DB - file Id points to two different collection files Hi Riina, You are setting you $id to an xs:string, not an xs:integer. Comparing strings of integers to integers often causes strange results. Hope this helps. Take care. 2021年2月16日(火) 19:35 Kuukka-Härmä Riina <Rii...@fi...<mailto:Rii...@fi...>>: Hello, Any ideas that what could be gone wrong are welcomed. We have an issue in eXist 4.7.1 db-installation . Backup is failing for some files, and after investigating, we found that there is Document ID that is pointing two different files in separate collections. Failed to access document data Document ID: 11240 Investigating which file this is with query: xquery version "3.1"; declare function local:find($path, $document-id as xs:integer) as xs:string* { local:find-in-collection($path, (), $document-id) }; declare function local:resource ($collection as xs:string, $resource as xs:string, $document-id as xs:integer) as xs:string? { let $path := $collection || '/' || $resource let $id := util:document-id($path) return if ($id eq $document-id) then ($path) else () }; declare function local:find-in-collection ($collection as xs:string, $sub-collection as xs:string?, $document-id as xs:integer) as xs:string* { let $path := string-join(($collection, $sub-collection), '/') return if (xmldb:collection-available($path)) then ( for-each( xmldb:get-child-collections($path), local:find-in-collection($path, ?, $document-id) ), for-each( xmldb:get-child-resources($path), local:resource($path, ?, $document-id) ) ) else ($path || " not found or insufficient permissions to read") }; let $id := '11240' return local:find('/db/APP', $id) This returns two files: "/db/APP/ORGANIZATION.A/CODE/INTERNAL/PUBLISHED/1603458557855/TOSELEMENTS/customFields.xml" "/db/APP/ORGANIZATION.B/CODE/INTERNAL/PUBLISHED/1611822097512/TOSELEMENTS/strongEsignatureText.xml" Howcome there can be returned two files with same id? How this can be fixed, is there any options than reinstall the database and return the content from backup? Should that fix the fileId:s eventually? What I know, for some problematic files there is used eXist dashboard copy/paste functionality - but not all copy pasted files are having this issue. Best Regards, Riina Kuukka-Härmä _______________________________________________ Exist-open mailing list Exi...@li...<mailto:Exi...@li...> https://lists.sourceforge.net/lists/listinfo/exist-open -- Michael Westbay Writer/System Administrator http://www.japanesebaseball.com/ _______________________________________________ Exist-open mailing list Exi...@li...<mailto:Exi...@li...> https://lists.sourceforge.net/lists/listinfo/exist-open |
From: Omar S. <Oma...@oe...> - 2021-02-18 19:44:15
|
Short answer: for eXist 5.2.0 git c58d04ec45de50e7738489dee072fcc863dc8b1b (that is the docker image from docker hub) the XSL processor is SAXON HE 9.9.1.6 saxonica.com Saxon 9.9 docs say: Saxon 9.9 includes highly conformant implementations of the current W3C Recommendations: XSLT 3.0, XQuery 3.1, XPath 3.1, and XSD 1.1. See Standards Conformance for more details. For various reasons I was asking myself the same question every now and then. I created a RestXq method that prints the answer. Here is a version of this /db/apps/get-runtime/get-runtime.xqm (world readable and executeable): xquery version "3.1"; module namespace api="urn:api"; declare %rest:path("/get-runtime") %rest:GET function api:runtime-info() as item()+ { let $xslt-runtime-info := transform:transform(<_/>, document {<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:output method="xml"/><xsl:template match='/'><_><product-name><xsl:value-of select="system-property('xsl:product-name')"/></product-name><product-version><xsl:value-of select="system-property('xsl:product-version')"/></product-version></_></xsl:template></xsl:stylesheet>}, ()) return <html xmlns="http://www.w3.org/1999/xhtml"> <title>Runtime info</title> <body> <h1>Runtime info</h1> <table> <tr> <td>{system:get-product-name()}</td> <td>{system:get-version()} git {system:get-revision()}</td> </tr> <tr> <td>{$xslt-runtime-info/*:product-name/text()}</td> <td>{$xslt-runtime-info/*:product-version/text()}</td> </tr> </table> </body> </html> }; Register it (eg. with exrest:register-module(xs:anyURI('/db/apps/get-runtime/get-runtime.xqm')) ) and you can the infos in for example at http://localhost:8080/exist/restxq/get-runtime Am 18.02.2021 um 18:12 schrieb Christian Achter: > Dear all, > > sorry to disturb you with this question, but I couldn't find anything > about this: > > What XSLT version ist running with eXist-db 5.2.0? > > We are currently running scripts of XSLT 2.0 which work fine but need > to switch to scripts of XSLT 3.0. Will that be possible with eXist 5.2? > > Kind regards > Christian Achter > > > > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open -- Mag. Ing. Omar Siam Austrian Center for Digital Humanities and Cultural Heritage Österreichische Akademie der Wissenschaften | Austrian Academy of Sciences Stellvertretende Behindertenvertrauensperson | Deputy representative for disabled persons Wohllebengasse 12-14, 1040 Wien, Österreich | Vienna, Austria T: +43 1 51581-7295 oma...@oe... | www.oeaw.ac.at/acdh |