Re: [basex-talk] BaseX/GUI v9.1.2 memory use

[Christian Grün]

Hi all,

I have revised the cache management of the project view in the latest
9.2.1 snapshot:

• The maximum number of cached file paths is now limited to 50,000.
• If a symbolic link is found in the directory structure, it will only
be traversed once.

Cheers,
Christian



On Wed, Jan 23, 2019 at 3:56 PM Bridger Dyson-Smith
 wrote:
>
> Mea culpa! I may have steered the train of conversation in a non-productive 
> direction: my home is parsed due to how I launch the GUI. In any event, I 
> haven't had any issues with parsing project files or symbolic links, either.
>
> Apologies,
> Bridger
>
> On Wed, Jan 23, 2019 at 8:30 AM Johannes Echterhoff 
>  wrote:
>>
>> For what it’s worth: in our developments we had a directory as part of the 
>> project files where we stored all queries that were executed during 
>> development and testing (these queries were dynamically created by other 
>> queries). Saving these queries is just part of our process. However, after a 
>> while that resulted in hundreds to thousands of query files. That resulted 
>> in a massive memory demand, and we noticed increased CPU usage, both of 
>> which we could not explain at first. Eventually we found out that the BaseX 
>> GUI automatically parsed all these queries, each time initializing a custom 
>> module we wrote, where the initialization of that module created a temporary 
>> directory with a number of files. The solution for us was to simply move the 
>> directory where we save the executed queries somewhere outside of the 
>> project files opened in the BaseX GUI.
>>
>>
>>
>> Best regards,
>>
>> Johannes
>>
>>
>>
>>
>>
>> Von: BaseX-Talk [mailto:basex-talk-boun...@mailman.uni-konstanz.de] Im 
>> Auftrag von Graydon Saunders
>> Gesendet: Mittwoch, 23. Januar 2019 14:19
>> An: Christian Grün 
>> Cc: BaseX 
>> Betreff: Re: [basex-talk] BaseX/GUI v9.1.2 memory use
>>
>>
>>
>> Never had a problem with the GUI parsing project files.  No issues with 
>> symbolic links.
>>
>>
>>
>> I have generally found basex very reliable but never try to update the 
>> installed version; it's always move the old, unpack the new.
>>
>> On Wed, Jan 23, 2019, 08:09 Christian Grün  wrote:
>>
>> Thanks for your assessments. So maybe we should ensure that every file and 
>> directory will only be parsed once.
>>
>>
>>
>> Did anyone of you have problems with the automatic parsing of project files 
>> in the BaseX GUI, or with symbolic links in particular?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Am Mi., 23. Jan. 2019, 09:12 hat Marco Lettere  
>> geschrieben:
>>
>> Same for us over here. The ability to follow symlinks is a very powerful 
>> feature that we use to externalize folders (data, restxq for instance). So 
>> please don't remove it altogether!
>>
>> M.
>>
>>
>>
>> On 22/01/19 23:50, Graydon Saunders wrote:
>>
>> I've been handling updates by making data/ a symbolic link to a data 
>> directory that's a sibling of the basex directory.  (Move the old, unpack 
>> the new, go into new and replace data/ with a symbolic link up and over.)
>>
>>
>>
>> Would hate to see that stop working.
>>
>> On Tue, Jan 22, 2019, 17:36 Christian Grün  wrote:
>>
>> Good to hear that! I can’t recollect that something particular has changed 
>> in version 9.1.2, regarding the scanning of project files, but I’ll have 
>> some thoughts how we can trace and interrupt such loops (or ignore symbolic 
>> links instead).
>>
>>
>>
>>
>>
>> Am Di., 22. Jan. 2019, 23:22 hat Bridger Dyson-Smith  
>> geschrieben:
>>
>> Glad that helped :)
>>
>>
>>
>> I see this when I start from a fresh install vs expanding the ZIP into the 
>> same directory.
>>
>>
>>
>> On Tue, Jan 22, 2019, 5:17 PM Rick Graham >
>> Thanks Bridger!
>>
>>
>>
>> Indeed, I quit basexgui and manually edited .basexgui to set the project 
>> directory to a newly created empty directory.  basexgui seems normal/stable 
>> after that.
>>
>>
>>
>> I rarely, as in almost never, use wine but I didn't have this issue with 
>> previous versions of BaseX.  Something seems unexpected here.
>>
>>
>>
>>
>>
>> On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith  
>> wrote:
>>
>> Hi Rick, et al,
>>
>> I think (but am not 100% sure) that the GUI 

Re: [basex-talk] BaseX/GUI v9.1.2 memory use

[Bridger Dyson-Smith]

Mea culpa! I may have steered the train of conversation in a non-productive
direction: my home is parsed due to how I launch the GUI. In any event, I
haven't had any issues with parsing project files or symbolic links,
either.

Apologies,
Bridger

On Wed, Jan 23, 2019 at 8:30 AM Johannes Echterhoff <
echterh...@interactive-instruments.de> wrote:

> For what it’s worth: in our developments we had a directory as part of the
> project files where we stored all queries that were executed during
> development and testing (these queries were dynamically created by other
> queries). Saving these queries is just part of our process. However, after
> a while that resulted in hundreds to thousands of query files. That
> resulted in a massive memory demand, and we noticed increased CPU usage,
> both of which we could not explain at first. Eventually we found out that
> the BaseX GUI automatically parsed all these queries, each time
> initializing a custom module we wrote, where the initialization of that
> module created a temporary directory with a number of files. The solution
> for us was to simply move the directory where we save the executed queries
> somewhere outside of the project files opened in the BaseX GUI.
>
>
>
> Best regards,
>
> Johannes
>
>
>
>
>
> *Von:* BaseX-Talk [mailto:basex-talk-boun...@mailman.uni-konstanz.de] *Im
> Auftrag von *Graydon Saunders
> *Gesendet:* Mittwoch, 23. Januar 2019 14:19
> *An:* Christian Grün 
> *Cc:* BaseX 
> *Betreff:* Re: [basex-talk] BaseX/GUI v9.1.2 memory use
>
>
>
> Never had a problem with the GUI parsing project files.  No issues with
> symbolic links.
>
>
>
> I have generally found basex very reliable but never try to update the
> installed version; it's always move the old, unpack the new.
>
> On Wed, Jan 23, 2019, 08:09 Christian Grün 
> wrote:
>
> Thanks for your assessments. So maybe we should ensure that every file and
> directory will only be parsed once.
>
>
>
> Did anyone of you have problems with the automatic parsing of project
> files in the BaseX GUI, or with symbolic links in particular?
>
>
>
>
>
>
>
>
>
>
>
> Am Mi., 23. Jan. 2019, 09:12 hat Marco Lettere 
> geschrieben:
>
> Same for us over here. The ability to follow symlinks is a very powerful
> feature that we use to externalize folders (data, restxq for instance). So
> please don't remove it altogether!
>
> M.
>
>
>
> On 22/01/19 23:50, Graydon Saunders wrote:
>
> I've been handling updates by making data/ a symbolic link to a data
> directory that's a sibling of the basex directory.  (Move the old, unpack
> the new, go into new and replace data/ with a symbolic link up and over.)
>
>
>
> Would hate to see that stop working.
>
> On Tue, Jan 22, 2019, 17:36 Christian Grün 
> wrote:
>
> Good to hear that! I can’t recollect that something particular has changed
> in version 9.1.2, regarding the scanning of project files, but I’ll have
> some thoughts how we can trace and interrupt such loops (or ignore symbolic
> links instead).
>
>
>
>
>
> Am Di., 22. Jan. 2019, 23:22 hat Bridger Dyson-Smith <
> bdysonsm...@gmail.com> geschrieben:
>
> Glad that helped :)
>
>
>
> I see this when I start from a fresh install vs expanding the ZIP into the
> same directory.
>
>
>
> On Tue, Jan 22, 2019, 5:17 PM Rick Graham 
> Thanks Bridger!
>
>
>
> Indeed, I quit basexgui and manually edited .basexgui to set the project
> directory to a newly created empty directory.  basexgui seems normal/stable
> after that.
>
>
>
> I rarely, as in almost never, use wine but I didn't have this issue with
> previous versions of BaseX.  Something seems unexpected here.
>
>
>
>
>
> On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith <
> bdysonsm...@gmail.com> wrote:
>
> Hi Rick, et al,
>
> I think (but am not 100% sure) that the GUI defaults to looking through
> your home directory on startup. So, somewhere in
> `~/rick/.wine/dosdevices/...` you have symbolic links that are looped.
>
>
>
> I think you might be able to circumvent this problem by finding
> `.basexgui` - it would probably be close to wherever you started the GUI
> from on your filesystem. I think you can edit some of the PATHS there and
> that may help?
>
>
>
> Again, I'm not sure. HTH!
>
> Best,
>
> Bridger
>
>
>
> On Tue, Jan 22, 2019 at 4:56 PM Rick Graham  wrote:
>
> The command-line seemed to be operating normally.
>
>
>
> What exactly is/are my project directories?
>
>
>
> I attached to the running GUI instance `strace -f -e trace=stat -p 13368`
> and it has infin

Re: [basex-talk] BaseX/GUI v9.1.2 memory use

[Johannes Echterhoff]

For what it’s worth: in our developments we had a directory as part of the 
project files where we stored all queries that were executed during development 
and testing (these queries were dynamically created by other queries). Saving 
these queries is just part of our process. However, after a while that resulted 
in hundreds to thousands of query files. That resulted in a massive memory 
demand, and we noticed increased CPU usage, both of which we could not explain 
at first. Eventually we found out that the BaseX GUI automatically parsed all 
these queries, each time initializing a custom module we wrote, where the 
initialization of that module created a temporary directory with a number of 
files. The solution for us was to simply move the directory where we save the 
executed queries somewhere outside of the project files opened in the BaseX GUI.

Best regards,
Johannes


Von: BaseX-Talk [mailto:basex-talk-boun...@mailman.uni-konstanz.de] Im Auftrag 
von Graydon Saunders
Gesendet: Mittwoch, 23. Januar 2019 14:19
An: Christian Grün 
Cc: BaseX 
Betreff: Re: [basex-talk] BaseX/GUI v9.1.2 memory use

Never had a problem with the GUI parsing project files.  No issues with 
symbolic links.

I have generally found basex very reliable but never try to update the 
installed version; it's always move the old, unpack the new.
On Wed, Jan 23, 2019, 08:09 Christian Grün 
mailto:christian.gr...@gmail.com>> wrote:
Thanks for your assessments. So maybe we should ensure that every file and 
directory will only be parsed once.

Did anyone of you have problems with the automatic parsing of project files in 
the BaseX GUI, or with symbolic links in particular?





Am Mi., 23. Jan. 2019, 09:12 hat Marco Lettere 
mailto:m.lett...@gmail.com>> geschrieben:
Same for us over here. The ability to follow symlinks is a very powerful 
feature that we use to externalize folders (data, restxq for instance). So 
please don't remove it altogether!
M.

On 22/01/19 23:50, Graydon Saunders wrote:
I've been handling updates by making data/ a symbolic link to a data directory 
that's a sibling of the basex directory.  (Move the old, unpack the new, go 
into new and replace data/ with a symbolic link up and over.)

Would hate to see that stop working.
On Tue, Jan 22, 2019, 17:36 Christian Grün 
mailto:christian.gr...@gmail.com>> wrote:
Good to hear that! I can’t recollect that something particular has changed in 
version 9.1.2, regarding the scanning of project files, but I’ll have some 
thoughts how we can trace and interrupt such loops (or ignore symbolic links 
instead).


Am Di., 22. Jan. 2019, 23:22 hat Bridger Dyson-Smith 
mailto:bdysonsm...@gmail.com>> geschrieben:
Glad that helped :)

I see this when I start from a fresh install vs expanding the ZIP into the same 
directory.

On Tue, Jan 22, 2019, 5:17 PM Rick Graham 
mailto:rickhg1...@gmail.com> wrote:
Thanks Bridger!

Indeed, I quit basexgui and manually edited .basexgui to set the project 
directory to a newly created empty directory.  basexgui seems normal/stable 
after that.

I rarely, as in almost never, use wine but I didn't have this issue with 
previous versions of BaseX.  Something seems unexpected here.


On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith 
mailto:bdysonsm...@gmail.com>> wrote:
Hi Rick, et al,
I think (but am not 100% sure) that the GUI defaults to looking through your 
home directory on startup. So, somewhere in `~/rick/.wine/dosdevices/...` you 
have symbolic links that are looped.

I think you might be able to circumvent this problem by finding `.basexgui` - 
it would probably be close to wherever you started the GUI from on your 
filesystem. I think you can edit some of the PATHS there and that may help?

Again, I'm not sure. HTH!
Best,
Bridger

On Tue, Jan 22, 2019 at 4:56 PM Rick Graham 
mailto:rickhg1...@gmail.com>> wrote:
The command-line seemed to be operating normally.

What exactly is/are my project directories?

I attached to the running GUI instance `strace -f -e trace=stat -p 13368` and 
it has infinite repetitions of:

[pid 13436] 
stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02",
 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links)

What's going on here?

On Tue, Jan 22, 2019 at 10:21 PM Christian Grün 
mailto:christian.gr...@gmail.com>> wrote:
at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167)
at org.basex.

Re: [basex-talk] BaseX/GUI v9.1.2 memory use

[Christian Grün]

Thanks for your assessments. So maybe we should ensure that every file and
directory will only be parsed once.

Did anyone of you have problems with the automatic parsing of project files
in the BaseX GUI, or with symbolic links in particular?





Am Mi., 23. Jan. 2019, 09:12 hat Marco Lettere 
geschrieben:

> Same for us over here. The ability to follow symlinks is a very powerful
> feature that we use to externalize folders (data, restxq for instance). So
> please don't remove it altogether!
> M.
>
> On 22/01/19 23:50, Graydon Saunders wrote:
>
> I've been handling updates by making data/ a symbolic link to a data
> directory that's a sibling of the basex directory.  (Move the old, unpack
> the new, go into new and replace data/ with a symbolic link up and over.)
>
> Would hate to see that stop working.
>
> On Tue, Jan 22, 2019, 17:36 Christian Grün 
> wrote:
>
>> Good to hear that! I can’t recollect that something particular has
>> changed in version 9.1.2, regarding the scanning of project files, but I’ll
>> have some thoughts how we can trace and interrupt such loops (or ignore
>> symbolic links instead).
>>
>>
>>
>> Am Di., 22. Jan. 2019, 23:22 hat Bridger Dyson-Smith <
>> bdysonsm...@gmail.com> geschrieben:
>>
>>> Glad that helped :)
>>>
>>> I see this when I start from a fresh install vs expanding the ZIP into
>>> the same directory.
>>>
>>> On Tue, Jan 22, 2019, 5:17 PM Rick Graham >>
 Thanks Bridger!

 Indeed, I quit basexgui and manually edited .basexgui to set the
 project directory to a newly created empty directory.  basexgui seems
 normal/stable after that.

 I rarely, as in almost never, use wine but I didn't have this issue
 with previous versions of BaseX.  Something seems unexpected here.


 On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith <
 bdysonsm...@gmail.com> wrote:

> Hi Rick, et al,
> I think (but am not 100% sure) that the GUI defaults to looking
> through your home directory on startup. So, somewhere in
> `~/rick/.wine/dosdevices/...` you have symbolic links that are looped.
>
> I think you might be able to circumvent this problem by finding
> `.basexgui` - it would probably be close to wherever you started the GUI
> from on your filesystem. I think you can edit some of the PATHS there and
> that may help?
>
> Again, I'm not sure. HTH!
> Best,
> Bridger
>
> On Tue, Jan 22, 2019 at 4:56 PM Rick Graham 
> wrote:
>
>> The command-line seemed to be operating normally.
>>
>> What exactly is/are my project directories?
>>
>> I attached to the running GUI instance `strace -f -e trace=stat -p
>> 13368` and it has infinite repetitions of:
>>
>> [pid 13436]
>>> stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02",
>>> 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links)
>>
>>
>> What's going on here?
>>
>> On Tue, Jan 22, 2019 at 10:21 PM Christian Grün <
>> christian.gr...@gmail.com> wrote:
>>
>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167)
> at
> org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at
> org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at
> org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
>

>>> Looks like a endless loop that is caused by parsing the files in
>>> your project directory. Do you possibly have any symbolic links?
>>>
>>> Can you reproduce the problem with a completely fresh BaseX zip
>>> archive?
>>>
>>>
>>>
>

Re: [basex-talk] BaseX/GUI v9.1.2 memory use

[Marco Lettere]

Same for us over here. The ability to follow symlinks is a very powerful 
feature that we use to externalize folders (data, restxq for instance). 
So please don't remove it altogether!

M.

On 22/01/19 23:50, Graydon Saunders wrote:
I've been handling updates by making data/ a symbolic link to a data 
directory that's a sibling of the basex directory.  (Move the old, 
unpack the new, go into new and replace data/ with a symbolic link up 
and over.)


Would hate to see that stop working.

On Tue, Jan 22, 2019, 17:36 Christian Grün > wrote:


Good to hear that! I can’t recollect that something particular has
changed in version 9.1.2, regarding the scanning of project files,
but I’ll have some thoughts how we can trace and interrupt such
loops (or ignore symbolic links instead).



Am Di., 22. Jan. 2019, 23:22 hat Bridger Dyson-Smith
mailto:bdysonsm...@gmail.com>> geschrieben:

Glad that helped :)

I see this when I start from a fresh install vs expanding the
ZIP into the same directory.

On Tue, Jan 22, 2019, 5:17 PM Rick Graham
mailto:rickhg1...@gmail.com> wrote:

Thanks Bridger!

Indeed, I quit basexgui and manually edited .basexgui to
set the project directory to a newly created empty
directory.  basexgui seems normal/stable after that.

I rarely, as in almost never, use wine but I didn't have
this issue with previous versions of BaseX.  Something
seems unexpected here.


On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith
mailto:bdysonsm...@gmail.com>> wrote:

Hi Rick, et al,
I think (but am not 100% sure) that the GUI defaults
to looking through your home directory on startup. So,
somewhere in `~/rick/.wine/dosdevices/...` you have
symbolic links that are looped.

I think you might be able to circumvent this problem
by finding `.basexgui` - it would probably be close to
wherever you started the GUI from on your filesystem.
I think you can edit some of the PATHS there and that
may help?

Again, I'm not sure. HTH!
Best,
Bridger

On Tue, Jan 22, 2019 at 4:56 PM Rick Graham
mailto:rickhg1...@gmail.com>>
wrote:

The command-line seemed to be operating normally.

What exactly is/are my project directories?

I attached to the running GUI instance `strace -f
-e trace=stat -p 13368` and it has infinite
repetitions of:

[pid 13436]

stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02",
0x7f7beb2796e0) = -1 ELOOP (Too many levels of
symbolic links)


What's going on here?

On Tue, Jan 22, 2019 at 10:21 PM Christian Grün
mailto:christian.gr...@gmail.com>> wrote:

at

org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167)
at

org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
at

org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
at

org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)


Looks like a endless loop that is caused by
parsing the files in your project directory.
Do you possibly have any symbolic links?

Can you reproduce the problem with a
completely fresh BaseX zip archive?

Re: [basex-talk] BaseX/GUI v9.1.2 memory use

[Graydon Saunders]

I've been handling updates by making data/ a symbolic link to a data
directory that's a sibling of the basex directory.  (Move the old, unpack
the new, go into new and replace data/ with a symbolic link up and over.)

Would hate to see that stop working.

On Tue, Jan 22, 2019, 17:36 Christian Grün 
wrote:

> Good to hear that! I can’t recollect that something particular has changed
> in version 9.1.2, regarding the scanning of project files, but I’ll have
> some thoughts how we can trace and interrupt such loops (or ignore symbolic
> links instead).
>
>
>
> Am Di., 22. Jan. 2019, 23:22 hat Bridger Dyson-Smith <
> bdysonsm...@gmail.com> geschrieben:
>
>> Glad that helped :)
>>
>> I see this when I start from a fresh install vs expanding the ZIP into
>> the same directory.
>>
>> On Tue, Jan 22, 2019, 5:17 PM Rick Graham >
>>> Thanks Bridger!
>>>
>>> Indeed, I quit basexgui and manually edited .basexgui to set the project
>>> directory to a newly created empty directory.  basexgui seems normal/stable
>>> after that.
>>>
>>> I rarely, as in almost never, use wine but I didn't have this issue with
>>> previous versions of BaseX.  Something seems unexpected here.
>>>
>>>
>>> On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith <
>>> bdysonsm...@gmail.com> wrote:
>>>
 Hi Rick, et al,
 I think (but am not 100% sure) that the GUI defaults to looking through
 your home directory on startup. So, somewhere in
 `~/rick/.wine/dosdevices/...` you have symbolic links that are looped.

 I think you might be able to circumvent this problem by finding
 `.basexgui` - it would probably be close to wherever you started the GUI
 from on your filesystem. I think you can edit some of the PATHS there and
 that may help?

 Again, I'm not sure. HTH!
 Best,
 Bridger

 On Tue, Jan 22, 2019 at 4:56 PM Rick Graham 
 wrote:

> The command-line seemed to be operating normally.
>
> What exactly is/are my project directories?
>
> I attached to the running GUI instance `strace -f -e trace=stat -p
> 13368` and it has infinite repetitions of:
>
> [pid 13436]
>> stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02",
>> 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links)
>
>
> What's going on here?
>
> On Tue, Jan 22, 2019 at 10:21 PM Christian Grün <
> christian.gr...@gmail.com> wrote:
>
>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167)
 at
 org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
 at
 org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
 at
 org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)

>>>
>> Looks like a endless loop that is caused by parsing the files in your
>> project directory. Do you possibly have any symbolic links?
>>
>> Can you reproduce the problem with a completely fresh BaseX zip
>> archive?
>>
>>
>>

Re: [basex-talk] BaseX/GUI v9.1.2 memory use

[Christian Grün]

Good to hear that! I can’t recollect that something particular has changed
in version 9.1.2, regarding the scanning of project files, but I’ll have
some thoughts how we can trace and interrupt such loops (or ignore symbolic
links instead).



Am Di., 22. Jan. 2019, 23:22 hat Bridger Dyson-Smith 
geschrieben:

> Glad that helped :)
>
> I see this when I start from a fresh install vs expanding the ZIP into the
> same directory.
>
> On Tue, Jan 22, 2019, 5:17 PM Rick Graham 
>> Thanks Bridger!
>>
>> Indeed, I quit basexgui and manually edited .basexgui to set the project
>> directory to a newly created empty directory.  basexgui seems normal/stable
>> after that.
>>
>> I rarely, as in almost never, use wine but I didn't have this issue with
>> previous versions of BaseX.  Something seems unexpected here.
>>
>>
>> On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith <
>> bdysonsm...@gmail.com> wrote:
>>
>>> Hi Rick, et al,
>>> I think (but am not 100% sure) that the GUI defaults to looking through
>>> your home directory on startup. So, somewhere in
>>> `~/rick/.wine/dosdevices/...` you have symbolic links that are looped.
>>>
>>> I think you might be able to circumvent this problem by finding
>>> `.basexgui` - it would probably be close to wherever you started the GUI
>>> from on your filesystem. I think you can edit some of the PATHS there and
>>> that may help?
>>>
>>> Again, I'm not sure. HTH!
>>> Best,
>>> Bridger
>>>
>>> On Tue, Jan 22, 2019 at 4:56 PM Rick Graham 
>>> wrote:
>>>
 The command-line seemed to be operating normally.

 What exactly is/are my project directories?

 I attached to the running GUI instance `strace -f -e trace=stat -p
 13368` and it has infinite repetitions of:

 [pid 13436]
> stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02",
> 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links)


 What's going on here?

 On Tue, Jan 22, 2019 at 10:21 PM Christian Grün <
 christian.gr...@gmail.com> wrote:

> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167)
>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
>>>
>>
> Looks like a endless loop that is caused by parsing the files in your
> project directory. Do you possibly have any symbolic links?
>
> Can you reproduce the problem with a completely fresh BaseX zip
> archive?
>
>
>

Re: [basex-talk] BaseX/GUI v9.1.2 memory use

[Bridger Dyson-Smith]

Glad that helped :)

I see this when I start from a fresh install vs expanding the ZIP into the
same directory.

On Tue, Jan 22, 2019, 5:17 PM Rick Graham  Thanks Bridger!
>
> Indeed, I quit basexgui and manually edited .basexgui to set the project
> directory to a newly created empty directory.  basexgui seems normal/stable
> after that.
>
> I rarely, as in almost never, use wine but I didn't have this issue with
> previous versions of BaseX.  Something seems unexpected here.
>
>
> On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith <
> bdysonsm...@gmail.com> wrote:
>
>> Hi Rick, et al,
>> I think (but am not 100% sure) that the GUI defaults to looking through
>> your home directory on startup. So, somewhere in
>> `~/rick/.wine/dosdevices/...` you have symbolic links that are looped.
>>
>> I think you might be able to circumvent this problem by finding
>> `.basexgui` - it would probably be close to wherever you started the GUI
>> from on your filesystem. I think you can edit some of the PATHS there and
>> that may help?
>>
>> Again, I'm not sure. HTH!
>> Best,
>> Bridger
>>
>> On Tue, Jan 22, 2019 at 4:56 PM Rick Graham  wrote:
>>
>>> The command-line seemed to be operating normally.
>>>
>>> What exactly is/are my project directories?
>>>
>>> I attached to the running GUI instance `strace -f -e trace=stat -p
>>> 13368` and it has infinite repetitions of:
>>>
>>> [pid 13436]
 stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02",
 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links)
>>>
>>>
>>> What's going on here?
>>>
>>> On Tue, Jan 22, 2019 at 10:21 PM Christian Grün <
>>> christian.gr...@gmail.com> wrote:
>>>
 at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167)
>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
>>
>
 Looks like a endless loop that is caused by parsing the files in your
 project directory. Do you possibly have any symbolic links?

 Can you reproduce the problem with a completely fresh BaseX zip archive?

Re: [basex-talk] BaseX/GUI v9.1.2 memory use

[Rick Graham]

Thanks Bridger!

Indeed, I quit basexgui and manually edited .basexgui to set the project
directory to a newly created empty directory.  basexgui seems normal/stable
after that.

I rarely, as in almost never, use wine but I didn't have this issue with
previous versions of BaseX.  Something seems unexpected here.


On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith 
wrote:

> Hi Rick, et al,
> I think (but am not 100% sure) that the GUI defaults to looking through
> your home directory on startup. So, somewhere in
> `~/rick/.wine/dosdevices/...` you have symbolic links that are looped.
>
> I think you might be able to circumvent this problem by finding
> `.basexgui` - it would probably be close to wherever you started the GUI
> from on your filesystem. I think you can edit some of the PATHS there and
> that may help?
>
> Again, I'm not sure. HTH!
> Best,
> Bridger
>
> On Tue, Jan 22, 2019 at 4:56 PM Rick Graham  wrote:
>
>> The command-line seemed to be operating normally.
>>
>> What exactly is/are my project directories?
>>
>> I attached to the running GUI instance `strace -f -e trace=stat -p 13368`
>> and it has infinite repetitions of:
>>
>> [pid 13436]
>>> stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02",
>>> 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links)
>>
>>
>> What's going on here?
>>
>> On Tue, Jan 22, 2019 at 10:21 PM Christian Grün <
>> christian.gr...@gmail.com> wrote:
>>
>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
>

>>> Looks like a endless loop that is caused by parsing the files in your
>>> project directory. Do you possibly have any symbolic links?
>>>
>>> Can you reproduce the problem with a completely fresh BaseX zip archive?
>>>
>>>
>>>

Re: [basex-talk] BaseX/GUI v9.1.2 memory use

[Bridger Dyson-Smith]

Hi Rick, et al,
I think (but am not 100% sure) that the GUI defaults to looking through
your home directory on startup. So, somewhere in
`~/rick/.wine/dosdevices/...` you have symbolic links that are looped.

I think you might be able to circumvent this problem by finding `.basexgui`
- it would probably be close to wherever you started the GUI from on your
filesystem. I think you can edit some of the PATHS there and that may help?

Again, I'm not sure. HTH!
Best,
Bridger

On Tue, Jan 22, 2019 at 4:56 PM Rick Graham  wrote:

> The command-line seemed to be operating normally.
>
> What exactly is/are my project directories?
>
> I attached to the running GUI instance `strace -f -e trace=stat -p 13368`
> and it has infinite repetitions of:
>
> [pid 13436]
>> stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02",
>> 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links)
>
>
> What's going on here?
>
> On Tue, Jan 22, 2019 at 10:21 PM Christian Grün 
> wrote:
>
>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167)
 at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
 at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
 at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)

>>>
>> Looks like a endless loop that is caused by parsing the files in your
>> project directory. Do you possibly have any symbolic links?
>>
>> Can you reproduce the problem with a completely fresh BaseX zip archive?
>>
>>
>>

Re: [basex-talk] BaseX/GUI v9.1.2 memory use

[Rick Graham]

The command-line seemed to be operating normally.

What exactly is/are my project directories?

I attached to the running GUI instance `strace -f -e trace=stat -p 13368`
and it has infinite repetitions of:

[pid 13436]
> stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02",
> 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links)


What's going on here?

On Tue, Jan 22, 2019 at 10:21 PM Christian Grün 
wrote:

> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167)
>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
>>>
>>
> Looks like a endless loop that is caused by parsing the files in your
> project directory. Do you possibly have any symbolic links?
>
> Can you reproduce the problem with a completely fresh BaseX zip archive?
>
>
>

Re: [basex-talk] BaseX/GUI v9.1.2 memory use

[Christian Grün]

>
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167)
>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
>>
>
Looks like a endless loop that is caused by parsing the files in your
project directory. Do you possibly have any symbolic links?

Can you reproduce the problem with a completely fresh BaseX zip archive?

Re: [basex-talk] BaseX/GUI v9.1.2 memory use

[Rick Graham]

No, I haven't tried the other apps yet.  I've only ever used the GUI and
the command-line.  I'll try that soon.

Meanwhile, here's some Java error traces from launching the GUI.

$ /usr/local/src/basex/bin/basexgui
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: GC
> overhead limit exceeded
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at javax.swing.SwingWorker.get(SwingWorker.java:602)
> at org.basex.gui.layout.GUIWorker$1.done(GUIWorker.java:40)
> at javax.swing.SwingWorker$5.run(SwingWorker.java:737)
> at
> javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.run(SwingWorker.java:832)
> at sun.swing.AccumulativeRunnable.run(AccumulativeRunnable.java:112)
> at
> javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.actionPerformed(SwingWorker.java:842)
> at javax.swing.Timer.fireActionPerformed(Timer.java:313)
> at javax.swing.Timer$DoPostEvent.run(Timer.java:245)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
> at java.awt.EventQueue.access$500(EventQueue.java:97)
> at java.awt.EventQueue$3.run(EventQueue.java:709)
> at java.awt.EventQueue$3.run(EventQueue.java:703)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
> at
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
> at
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
> at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
> Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.util.Arrays.copyOf(Arrays.java:3332)
> at java.lang.String.(String.java:166)
> at org.basex.util.Token.string(Token.java:115)
> at org.basex.util.TokenBuilder.toString(TokenBuilder.java:405)
> at org.basex.io.IOFile.add(IOFile.java:528)
> at org.basex.io.IOFile.create(IOFile.java:500)
> at org.basex.io.IOFile.(IOFile.java:74)
> at org.basex.io.IOFile.(IOFile.java:39)
> at org.basex.io.IOFile.children(IOFile.java:226)
> at org.basex.io.IOFile.children(IOFile.java:193)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173)
> Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java
> heap space
> at java.awt.image.DataBufferInt.(DataBufferInt.java:75)
> at com.sun.java.swing.plaf.gtk.GTKEngine.finishPainting(GTKEngine.java:591)
> at com.sun.java.swing.plaf.gtk.GTKEngine.finishPainting(GTKEngine.java:582)
> at
> com.sun.java.swing.plaf.gtk.GTKPainter.paintTabbedPaneContentBackground(GTKPainter.java:866)
> at
> javax.swing.plaf.synth.SynthTabbedPaneUI.paintContentBorder(SynthTabbedPaneUI.java:731)
> at
> javax.swing.plaf.synth.SynthTabbedPaneUI.paint(SynthTabbedPaneUI.java:486)
> at
> javax.swing.plaf.synth.SynthTabbedPaneUI.update(SynthTabbedPaneUI.java:376)
> at javax.swing.JComponent.paintComponent(JComponent.java:780)
> at javax.swing.JComponent.paint(JComponent.java:1056)
> at javax.swing.JComponent.paintChildren(JComponent.java:889)
> at 

Re: [basex-talk] BaseX/GUI v9.1.2 memory use

[Christian Grün]

Hm, I couldn’t reproduce this out of the box. Does the problem only
occur in your GUI instance? Did you check out the behavior on
command-line or in the DBA as well?


On Tue, Jan 22, 2019 at 9:51 PM Rick Graham  wrote:
>
> Hello,
>
> Thanks again, as always, for a great product.
>
> I just installed BaseX v9.1.2 (upgrading from a previous v9.1.2 snapshot), 
> launched the GUI and then got interrupted.  When I returned, almost all of 
> the JVM's memory was being used.  I hit "GC" several times but it didn't seem 
> to help.  I had no database loaded/open.  Seems like some memory isn't 
> getting freed properly.
>
> Here's my "INFO"
>
>> General Information:
>>  Version: 9.1.2
>>  Used Memory: 1593 MB
>> Global options:
>>  AUTHMETHOD: Basic
>>  CACHETIMEOUT: 3600
>>  DBPATH: /usr/local/src/basex/data
>>  DEBUG: false
>>  FAIRLOCK: false
>>  HOST: localhost
>>  HTTPLOCAL: false
>>  IGNORECERT: false
>>  IGNOREHOSTNAME: false
>>  KEEPALIVE: 600
>>  LANG: English
>>  LANGKEYS: false
>>  LOG: true
>>  LOGMSGMAXLEN: 1000
>>  LOGPATH: .logs
>>  NONPROXYHOSTS:
>>  PARALLEL: 8
>>  PARSERESTXQ: 3
>>  PASSWORD:
>>  PORT: 1984
>>  PROXYHOST:
>>  PROXYPORT: 0
>>  REPOPATH: /usr/local/src/basex/repo
>>  RESTPATH:
>>  RESTXQPATH:
>>  SERVERHOST:
>>  SERVERPORT: 1984
>>  STOPPORT: 8985
>>  TIMEOUT: 30
>>  USER:
>>  WEBPATH: /usr/local/src/basex/webapp
>> Local options
>>  ADDARCHIVES: true
>>  ADDCACHE: false
>>  ADDRAW: false
>>  ARCHIVENAME: false
>>  ATTRINCLUDE:
>>  ATTRINDEX: true
>>  AUTOFLUSH: true
>>  AUTOOPTIMIZE: false
>>  BINDINGS:
>>  CASESENS: false
>>  CATFILE:
>>  CHECKSTRINGS: true
>>  CHOP: true
>>  COMPPLAN: true
>>  COPYNODE: true
>>  CREATEFILTER: *.xml
>>  CREATEONLY: false
>>  CSVPARSER:
>>  DEFAULTDB: false
>>  DIACRITICS: false
>>  DOTCOMPACT: false
>>  DOTPLAN: false
>>  DTD: false
>>  ENFORCEINDEX: false
>>  EXPORTER:
>>  FORCECREATE: false
>>  FTINCLUDE:
>>  FTINDEX: false
>>  HTMLPARSER:
>>  INLINELIMIT: 100
>>  INTPARSE: false
>>  JSONPARSER:
>>  LANGUAGE: en
>>  LSERROR: 0
>>  MAINMEM: false
>>  MAXCATS: 100
>>  MAXLEN: 96
>>  MAXSTAT: 30
>>  MIXUPDATES: false
>>  PARSER: xml
>>  QUERYINFO: true
>>  RUNQUERY: true
>>  RUNS: 1
>>  SERIALIZE: true
>>  SERIALIZER:
>>  SKIPCORRUPT: false
>>  SPLITSIZE: 0
>>  STEMMING: false
>>  STOPWORDS:
>>  STRIPNS: false
>>  TAILCALLS: 256
>>  TEXTINCLUDE:
>>  TEXTINDEX: true
>>  TEXTPARSER:
>>  TOKENINCLUDE:
>>  TOKENINDEX: false
>>  UPDINDEX: false
>>  WRITEBACK: false
>>  XINCLUDE: true
>>  XMLPLAN: true
>
>
> Best regards,
> Richard
>

[basex-talk] BaseX/GUI v9.1.2 memory use

[Rick Graham]

Hello,

Thanks again, as always, for a great product.

I just installed BaseX v9.1.2 (upgrading from a previous v9.1.2 snapshot),
launched the GUI and then got interrupted.  When I returned, almost all of
the JVM's memory was being used.  I hit "GC" several times but it didn't
seem to help.  I had no database loaded/open.  Seems like some memory isn't
getting freed properly.

Here's my "INFO"

General Information:
>  Version: 9.1.2
>  Used Memory: 1593 MB
> Global options:
>  AUTHMETHOD: Basic
>  CACHETIMEOUT: 3600
>  DBPATH: /usr/local/src/basex/data
>  DEBUG: false
>  FAIRLOCK: false
>  HOST: localhost
>  HTTPLOCAL: false
>  IGNORECERT: false
>  IGNOREHOSTNAME: false
>  KEEPALIVE: 600
>  LANG: English
>  LANGKEYS: false
>  LOG: true
>  LOGMSGMAXLEN: 1000
>  LOGPATH: .logs
>  NONPROXYHOSTS:
>  PARALLEL: 8
>  PARSERESTXQ: 3
>  PASSWORD:
>  PORT: 1984
>  PROXYHOST:
>  PROXYPORT: 0
>  REPOPATH: /usr/local/src/basex/repo
>  RESTPATH:
>  RESTXQPATH:
>  SERVERHOST:
>  SERVERPORT: 1984
>  STOPPORT: 8985
>  TIMEOUT: 30
>  USER:
>  WEBPATH: /usr/local/src/basex/webapp
> Local options
>  ADDARCHIVES: true
>  ADDCACHE: false
>  ADDRAW: false
>  ARCHIVENAME: false
>  ATTRINCLUDE:
>  ATTRINDEX: true
>  AUTOFLUSH: true
>  AUTOOPTIMIZE: false
>  BINDINGS:
>  CASESENS: false
>  CATFILE:
>  CHECKSTRINGS: true
>  CHOP: true
>  COMPPLAN: true
>  COPYNODE: true
>  CREATEFILTER: *.xml
>  CREATEONLY: false
>  CSVPARSER:
>  DEFAULTDB: false
>  DIACRITICS: false
>  DOTCOMPACT: false
>  DOTPLAN: false
>  DTD: false
>  ENFORCEINDEX: false
>  EXPORTER:
>  FORCECREATE: false
>  FTINCLUDE:
>  FTINDEX: false
>  HTMLPARSER:
>  INLINELIMIT: 100
>  INTPARSE: false
>  JSONPARSER:
>  LANGUAGE: en
>  LSERROR: 0
>  MAINMEM: false
>  MAXCATS: 100
>  MAXLEN: 96
>  MAXSTAT: 30
>  MIXUPDATES: false
>  PARSER: xml
>  QUERYINFO: true
>  RUNQUERY: true
>  RUNS: 1
>  SERIALIZE: true
>  SERIALIZER:
>  SKIPCORRUPT: false
>  SPLITSIZE: 0
>  STEMMING: false
>  STOPWORDS:
>  STRIPNS: false
>  TAILCALLS: 256
>  TEXTINCLUDE:
>  TEXTINDEX: true
>  TEXTPARSER:
>  TOKENINCLUDE:
>  TOKENINDEX: false
>  UPDINDEX: false
>  WRITEBACK: false
>  XINCLUDE: true
>  XMLPLAN: true


Best regards,
Richard