Justin,
If the RPG is "fairly involved" as you said, you may be better served to set up a simple "server" job that listens on a request data queue, where each request sent includes the name of the response data queue to use to reply.
It is pretty easy to adapt almost any RPG process to run in batch as such as server job, waiting on a request data queue using the QRCVDTAQ API.
You can also "scale up" by increasing the number of identical copies of that server job running, to keep up with "demand" in case many threads may be all trying to make requests more or less simultaneously.
One really nice thing about this architecture is, the OS handles the queuing, such that the next available server job picks up the next waiting request from the incoming request data queue, automatically. The only thing you have to do is to ensure that you have started enough "server jobs" all waiting on the same request queue to keep up with demand.
Also, if you go that way, you can change your "web service" to also make its request via the same request data queue, and get back the results via its own results data queue(s), and that way, you have just one single shared code base to maintain, going forward.
Hope that helps,
Mark S. Waterbury
On Friday, March 6, 2020, 1:58:05 PM EST, Justin Taylor <justin@xxxxxxxxxxxxx> wrote:
Multiple JVM threads would be calling the same RPG procedure concurrently, which would cause a bottleneck since the RPG would be single-threaded.
The RPG code is already available as a webservice, it just seems silly for a native IBMi job to have to call a local webservice to run an RPG program. Que sera, sera!
Thanks guys :)
-----Original Message-----
From: Nathan Andelin [mailto:nandelin@xxxxxxxxx]
Sent: Friday, March 06, 2020 12:26 PM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Java->RPG, *SERIALIZE required?
Because it's multi-threaded, and a single-threaded bottleneck would be
undesirable.
Now I'm curious about what you might be comparing thread(*serialize) to? I assume you understand that calling Java methods must also be serialized in muti-threaded Java processes. That's just normal practice within multi-threaded Jobs. The fact that RPG code might be single-threaded has nothing to do with it.
An alternative would be to communication between a pool of Java threads and a pool of RPG servers via data queues or some other form of inter-process communication.
midrange.com
