|
Unless Java via QSH re-uses a single JVM, I'd call that the opposite of
efficient. If it does re-use a single JVM, then it suffers from all the
same issues.
"Plus I can call as many Java processes as needed while also switching the
JVM in a current job."
Please explain. AFAIK, the one JVM per job is an OS restriction.
-----Original Message-----
From: Richard Schoen [mailto:Richard.Schoen@xxxxxxxxxxxxxxx]
Sent: Monday, January 22, 2018 12:00 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Java extensions directory vs Excel generation
"Plus I can call as many Java processes as needed while also switching the
JVM in a current job."
Until the JVM crashes or runs out of memory, then your job has to be
restarted. Seen that a bit. Ouch..
If you want to keep Java resident. Better to create a Java based simple
app server then to call and consume Java stuff via REST. Queue Dieter...
That keeps Java in memory but also out of process so RPG can do it's thing
by sending data queue entries possibly or using REST calls to the Java
process which is much easier than mapping Java methods to RPG. Yuk...
BTW: Calling Java via QSH is pretty efficient these days but I agree you
want to limit too many simultaneous calls depending on the app needs.
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com
----------------------------------------------------------------------
message: 1
date: Mon, 22 Jan 2018 14:34:17 +0000
from: Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
subject: RE: Java extensions directory vs Excel generation
I assume by "single instance issues", you mean the fact that each job only
gets a single JVM, which can't be changed or restarted.
Using Java as your driving language is a viable option, but (for
performance reasons) you certainly won't want a ton of RUNJVA from RPG/CL.
"Plus I can call as many Java processes as needed while also switching the
JVM in a current job."
Please explain. AFAIK, the one JVM per job is an OS restriction.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.