RE: keep a java program open -- JAVA400-L

>From a Toolbox performance perspective, data queues is about as lightweight
as it gets.  All work is eventually done by calling an iSeries Data Queue
API.  In client/server mode the client sends data to the server.  The
server pulls data off the connection and affects the data queue by calling
an iSeries API.  In the data queue case little additional processing in
needed.  If the Java program is running on the same server that holds the
queue, there is a native optimization.  With the optimization the Toolbox
skips the server and directly calling the API (by calling C code via JNI).

As with all Toolbox objects, reusing the connection is key when in
client/server mode.  In client/server mode the best model is connecting up
front and reusing the connection until ready to end the application.

There was a performance problem with older versions of AS/400.  If peek or
read with wait was being used (read the queue, if nothing there wait for
xxx seconds before returning empty in case something shows up), and an
entry was not available, control would not be returned to the client for at
least two seconds.  That is, even if an entry showed up .1 seconds after
the wait, control would still not be returned for two seconds.  This was a
'feature' of the server.   It took them that long to set up the objects
necessary to wait for something to show up.  We finally convinced them this
was a bug not a feature and they fixed it with a PTF.  More info (including
PTF numbers) is in the faq section of the Toolbox web site
(http://www-1.ibm.com/servers/eserver/iseries/toolbox/faq.htm#faqX).

Summary -- data queues is the fastest IPC mechanism available via Toolbox
classes.

David Wall
AS/400 Toolbox for Java




                      "Richards, Etienne
                      (CAP, PTL)"               To:       
"'java400-l@midrange.com'" <java400-l@midrange.com>
                      <Etienne.Richards@        cc:
                      penske.com>               Subject:  RE: keep a java 
program open
                      Sent by:
                      java400-l-admin@mi
                      drange.com


                      01/22/2002 02:51
                      PM
                      Please respond to
                      java400-l





David,

What other options do you have for inter process communication on the
AS/400? In ILE C you can use shared memory, is that available in RPG?

Do you think that shared memory might be faster, all that you then send
through the data queues are enough information to identify the shared
memory
that must be accessed by the receiving application.

Can the AS/400 Toolbox people please comment on the speed of accessing data
queues from java using the toolbox classes.

Etienne

-----Original Message-----
From: David Morris [mailto:David.Morris@plumcreek.com]
Sent: Tuesday, January 22, 2002 2:54 PM
To: java400-l@midrange.com
Subject: RE: keep a java program open


Etienne,

Since you mention scalability, I assume you want speed. Data queues
in the past with Java were terribly slow. I know there was a fix made
that
eliminated an unnecessary delay. Data queues are also inefficient with

varying length data.

I hit that delay problem in an application that passed quite a bit of
data.
I converted that code to use a user space to pass the bulk of data and

a single message on a data queue to trigger an action and it was many
times faster.

You are right that data queues allow you to scale your application. I
built a server framework that uses a configurable number of server
jobs and it has worked out very well. It was written in RPGIV, but I am

sure that the performance benefit is the same. We use it mostly to
farm out FTP jobs, but it also comes in handy for processors we use
to sync-up our data warehouse files.

David Morris

>>> Etienne.Richards@penske.com 01/22/02 12:16PM >>>

I have looked at the CPU usage of the java application that is waiting
for a
message on the queue and it looked good (It seemed like it blocked
while
waiting, it was not doing polling). Data queues also seemed like the
fasted
way to get messages to move between different applications that run on
the
same AS/400 machine.

I also feel that this type of solution would scale very well. You can
have
multiple java programs or multiple java threads read from the same
queue and
only one of them will get a message, that way you can pre-start more
jobs or
threads to do the work.

For me it felt as if the communication between to two jobs (CL and
Java
process) was almost instantaneous. It also allowed me to make use of
connection pooling for jdbc and AS400 connections which reduced the
time to
complete the request even more.

Are there any other ways to move data from java back to a calling RPG /
CL
program? I know you can use PCML to call a RPG program from java and
you can
have input and output parameters but what can you do if you want to
call a
java program from RPG while wanting to have input and output
parameters? You
could probably use data areas, MQ Series, Data queues but they all seem
to
fall into the same type of solution.

I hope I answered your question, I know I started rambling a bit...

Etienne
_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.
_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.