Dear Rony,
Many thanks for your feedback!
> You use one interpreter instance for running the Rexx code. As you are
> not explicitly closing the files after the lines()-BIF you become
> dependent upon the ooRexx garbage collector to be triggered in order to
> close the stream of the first activation implicitly. As BSF4ooRexx is
> geared towards dispatching Rexx scripts as quickly as possible, it is
> likely that the ooRexx garbage collector has not been triggered yet,
> such that the open stream in activation 1 is causing the access to this
> file in activation 2 to not be successful.
>
> Solution: explicitly close the streams, if you do not need them anymore,
> e.g. with
>
> call stream 'TEXT.TXT', "C", "Close"
Of course, the root of the problem is in the Rexx scripts themselves as
they should be responsible for properly closing the streams.
However, in our own old custom Rexx-Java bridge, the behaviour was that
after the script was finished, the interpreter was fully closed resulting
in the streams also to be closed.
In Rexx can be quite easy to make the mistake of not properly closing
streams (for example when there is an unexpected error), and many of our
existing scripts depend on the behaviour that streams are automatically
closed after execution.
>
> (Side note: each instance of BSFManager actually creates its own Rexx
> interpreter instance.)
Yes, but starting each script using a new BSFManager doesn't help as the
streams will still be open in the previous instance.
> > Running the same script from the command line works as expected (i.e.
> > running the following twice on the command line prints '1' twice, as
> > expected): rexx -E "SAY LINES('TEST.TXT')")
> >
> This is not the same scenario! In this case a Rexx interpreter is
> created, runs the Rexx program and closes down fully. This is repeated
> twice. The second Rexx program runs only after the first Rexx program
> has been fully shut down in the process.
Yes, it's not the same scenario. I've put it here as an example of how
we'd ideally want things to work, without having to shut down the JVM (and
Rexx interpreter with it).
> > I think there should be a way to have the interpreter shutting down and
> > thus its held resources being released, either programmatically or for
> > example in RexxEngine.terminate() and/or RexxEngine.exec() (after
> > execution of the script).
> >
> This is not under the control of BSF4ooRexx, unfortunately.
Yes, I suppose ultimately the OS closes the streams when the process that
opened them ends.
And I suppose in our own old custom Rexx-Java bridge, the rexx interpreter
was ended after running the script, leading to the OS to clean up dangling
resource handles (unlike in BSF4ooRexx).
> Maybe in your case triggering the ooRexx garbage collector explicitly
> may solve the problem, if the Rexx interpreter instance gets terminated.
That might work in our case.
I've looked around on the net but couldn't find a way to explicitly
trigger the ooRexx GC?
Best regards,
Erik Duijs
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
