Re: HTTP API or Web Service concurrency issue

Hi Charles,

Hmmm, it doesn't appear so. The reported failure is between 2 separate
submitted jobs performing the same task (generating and emailing an HTML
letter)..

This submitted process uses:
a) PGMA (named ACTGRP) to call SVCPGMB (*CALLER)
a.1) SVCPGMB calls SVCPGMC (*CALLER) which performs an HTTP_URL_GET() to a
web service to load an IFS output file with HTML.
a.2) SVCPGMB then calls SVCPGMD (*CALLER) which calls SVCPGMC (*CALLER)
which performs an HTTP_URL_POST_RAW() to take that HTML (now in memory) and
send an email containing that HTML

SVCPGMC (*CALLER) is where we centralized all access to the HTTP API.

So, a single job instance of this process is two calls to HTTP API. I
anticipate that the first call to produce an HTML file establishes the
connection, and the second call to send the HTML email is reusing the same
connection. I'd hope that the web services are stateless, but I'll double
check with that team to ensure they are. From what I can tell, each call
to an HTTP API procedure is finished with it upon return from each call.

In step a.1, the IFS output file created contains a timestamp in the file
name, with a precision of 6 fractional seconds. That should do a very good
job ensuring a unique file name, but I see that as a potential problem
where 2 jobs could, in theory, obtain the same exact timestamp, and collide
on the IFS output file name. I'll likely recommend shoring that up to
ensure uniqueness.

Mike

On Wed, May 29, 2019 at 10:05 AM Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

Mike,

Do you have anyplace in the jobs where
- PGMA and PGMB both use HTTP API
- PGMA calls PGMB
- PGMA hasn't finished using HTTP API before calling PGMB

That can cause problems as HTTP API doesn't support simultaneous
connections within a job (Activation group really)

You can work around it by running PGMA and PGMB in seperate activation
groups as HTTP API uses *CALLER.

Charles




On Wed, May 29, 2019 at 9:56 AM Mike Jones <mike.jones.sysdev@xxxxxxxxx>
wrote:

Hi Scott,

Not a multi-threaded program, but it is being called in a submitted jobs
environment on a large system hosting many companies, where the HTTP API
and the web service can be executed in multiple jobs at the same instant
(across different jobs).

I noticed yesterday we have a very old version. I'm already planning on
recommending we update to the current version. Because it could impact
many companies, that will be a bureaucratic and slow process.

Thanks for your help and feedback.

Mike

On Tue, May 28, 2019 at 9:46 PM Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx

wrote:

Mike.

What do you mean by "concurrency", here? Are you trying to call
HTTPAPI in a multi-threaded environment? You almost never see people
use multi-threaded code in RPG, so this would be very bizarre. HTTPAPI
is not designed for multi-threaded access.

If you are running multiple copies of HTTPAPI in separate jobs or
activation groups, there is no problem.

However, you are running an 11 year out-of-date version of HTTPAPI.

Who

knows what bugs have been fixed in the past 11 years? I certainly

can't

remember everything that has happened in that time. Considering

updating.

-SK

On 5/28/19 6:00 PM, Mike Jones wrote:

HTTPAPI Version 1.23 released 2008-04-24
OS/400 V7R3M0

We're using the HTTP API plus internal web services and are

occasionally

experiencing a concurrency issue, where the results of one web

service

call

are getting mixed up with the results of a different web service

call.

RPG <--> HTTP API <--> Java Web Service

Our RPG and Java teams don't think the problem is in their code (of

course,

which I don't necessarily believe). But, they asked me to look into

if

there have ever been concurrency issues in the HTTP API product by

Scott

K. Has anyone seen any concurrency issues like that?

Mike

--
Scott Klement
http://www.scottklement.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com