Finally I have been able to debug and correct all aspects of running ooRexx in 7/24 mode with
BSF4ooRexx, constantly creating and terminating Rexx interpreter instances (RII) via/from the Java
side.
There is only one problem/observation left/open. Here the attempt to describe the use case: whenever
a Java program creates a RexxScriptEngine (cf. javafx.script.Engine, Javadocs at:
<https://docs.oracle.com/javase/8/docs/api/javax/script/package-summary.html>) the BSF4ooRexx setup
code does the following:
* it takes the javax.script.ScriptContext' readerObject, wraps it up (will insert
a 'REXXin?>'
prompt) for ooRexx and uses that for setting .local's input monitor
(".input~destination(wrappedReaderObject)")
* it takes the javax.script.ScriptContext' writerObject, wraps it up (will insert
a 'REXXout>'
prompt) for ooRexx and uses that for setting .local's output monitor
(".output~destination(wrappedWriterObject)")
* it takes the javax.script.ScriptContext' errorWriterObject, wraps it up
(will insert a
'REXXerr>' prompt) for ooRexx and uses that for setting .local's error
monitor
(".error~destination(wrappedErrorWriterObject)")
* it takes the javax.script.ScriptContext' errorWriterObject, wraps it up
(will insert a
'REXXtrc>' prompt) for ooRexx and uses that for setting .local's traceOutput
monitor
(".traceOutput~destination(wrappedErrorWriterObject)")
* it takes the javax.script.ScriptContext' readerObject, wraps it up (will insert
a 'REXXdbgin?>'
prompt) for ooRexx and uses that for setting .local's debugInput monitor
(".debugInput~destination(wrappedReaderObject)")
This is done to allow ooRexx programmers to use the Java reader/writers/streams
transparently.
E.g. using "SAY ..." or ".output~say(...)" will cause the "..." output to be written to the Java
writer/stream (prefixed with "REXXout>") to allow identifying Rexx output in Java output streams
(the prefix can be turned off as is the case for Webserver deployments).
BSF4ooRexx relies on the UNINIT mechanism of ooRexx to release references to Java objects (being
held by ooRexx proxy objects of BSF4ooRexx). This has been working very well!
It seems however that when terminating a Rexx interpreter instance the monitored destination objects
in the monitors stored in the local environment (.input, .output, .error, .traceOutput, .debugInput)
do not have their UNINIT methods executed (as if the added destinations to these monitors do not get
removed and therefore making the objects eligible for garbage collection). This causes memory leaks.
Not sure whether this is working as designed hence asking.
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
