Re: [Exist-open] oxygen 24 with exist-db 5.3

[Jean-Paul R. <re...@gm...>]

Yesterday I did the first step of rebuilding the XML RPC connection in
Oxygen (per Joe's suggestion). This had no effect.

Looking into Alexander's Github post
https://github.com/eXist-db/exist/issues/4022 I saw some comments from Marc
de Graauw about refactoring the library modules so that there is no
"recursive" importation of modules. This meant redistributing functions
from about 10 modules to about 20. This has eliminated the problem. I went
and did this on another project which was experiencing the same problem,
and it also resolved it. I have done a lot of modification and saving, and
in the last 36 hours I've not had one instance of database locking up.

I've not attempted to repeat the outcome via modify/save/modify cycles in
eXide to determine if the problem is somehow linked to the  connection
method used by Oxygen. But I'm inclined to follow Alexander on the root of
the problem: modules are cross-checking, importing each other recursively,
and leading to lockup. Given that every time I tried to shut down the logs
show threads are waiting.....

I'm not happy about work arounds that will multiply my modules, but it does
seem to address the problem in ways that I can at least control.

JPR


On Mon, Nov 1, 2021 at 8:25 AM Alexander Henket <ah...@xs...> wrote:

> The caching/compiling of xquery code changed in eXist-db 5.something (I
> think Adam was on that). For eXist-db 5 was what really started the issue.
>
> I think this issue is currently the worst issue for us. It made us
> extremely shy about updating our production servers where we we used do
> maintenance just about every day. The thing with a hard kill is the
> indexing that takes 19-20 hours on our server so you *really* don’t that on
> production.
>
> The phenomenon is that different threads are waiting for each other to
> make the first move, but no process to oversee that one actually does so
> the whole db is at peace with as many threads waiting as the pool allows.
> What I think should happen is either assign a form of thread orchestration
> that prevents deadlock and/or allow the db to be stopped in a regular
> fashion without forcing reindex.
>
> Regards
>
> Alexander
>
> Op 1 nov. 2021, om 00:06 heeft Jean-Paul Rehr <re...@gm...> het
> volgende geschreven:
>
> Alexander, it does indeed seem similar.
>
> I see some discussion in that issue about circular referencing between
> modules, but I haven't changed my module construction practices since I
> started a few years ago (3.7). I have no more circularity in module imports
> now than before, although each library module has far more functions now.
>
> I'm going to move to eXide for all work for a few days to see if the
> problem reproduces there.
>
> JPR
>
>
>
> On Sun, Oct 31, 2021 at 9:28 PM Alexander Henket <ah...@xs...>
> wrote:
>
>> Maybe I read what I want to read but sure looks my issue although we’re
>> not on oxygen 24 yet
>>
>> https://github.com/eXist-db/exist/issues/4022
>>
>> Verstuurd vanaf mijn iPhone
>>
>> Op 31 okt. 2021 om 19:17 heeft Jean-Paul Rehr <re...@gm...> het
>> volgende geschreven:
>>
>> 
>> Dear list members,
>>
>> About a week ago I upgraded to Oxygen 24 for it's official support for
>> eXist 5.3. I use Oxygen principally to edit TEI XML files and Xquery files,
>> all stored in eXist 5.3. I am finding however that editing certain Xquery
>> files has become a problem, one which I can't identify the root of.
>>
>> I'll describe the scenario:
>>
>> I will edit any number of Xquery files (chiefly for producing web pages)
>> and then save the edits. I'll preview the results in my browser. And then I
>> go back and make changes to the Xquery, save, preview. Rinse and repeat.
>> After doing this about 5 times, I note that the "save" in Oxygen begins to
>> slow down with the Mac beachball hourglass appearing. I do this a few more
>> times and I get the Oxygen "saving" popup, and the save can take 10-20
>> seconds. A few more times and eXist stops responding and Oxygen reports a
>> timeout error. I then need to shut down eXist and restart, which involves
>> reindexing because the shut down was "unclean" (because I have to force it).
>>
>> Just in the last hour I've had to restart eXist twice because of this. I
>> suspect this is something to do with module validation, although I can't
>> identify a particular aspect of the module that incur this problem. I've
>> tried deleting the module, copying the code into a new module, and
>> resaving, but that has no effect.
>>
>> There is no trace in the eXist logs until I force a shutdown when it then
>> states:
>>
>> 2021-10-31 18:48:13,212 [AWT-EventQueue-0] INFO  (BrokerPool.java
>> [shutdown]:1645) - Waiting 120000ms for remaining threads to shut down...
>> 2021-10-31 18:50:13,486 [AWT-EventQueue-0] WARN  (BrokerPool.java
>> [shutdown]:1656) - Not all threads returned. Forcing shutdown ...
>>
>> *Importantly, I can avoid this if, when I sense that file saving is
>> slowing down, I stop eXist and restart eXist and quit Oxygen. Or if I close
>> the file in Oxygen and reopen it!*
>>
>> I am using the 5.3 official release with Oxygen XML Editor 24.0, build
>> 2021101506. This is a local eXist that has been running fine for months; I
>> use the standard configuration.
>>
>> Editing in eXide produces none of the above problems.
>>
>> Any clues as to how to diagnose this problem? At this point using Oxygen
>> to edit many of my XQuery files is simply unworkable.
>>
>> Thanks and best,
>> Jean-Paul
>>
>> _______________________________________________
>> Exist-open mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-open
>>
>>
>