Re: Socket server

Hi Scott,

I understand that Qp0wChkChld let know the server that
there are no workers running and a new one should be
started.

But I don't understand how the server can know if
there is a worker available or they are all busy and a
new one should be started and then passed the request.

Suppose we have 3 workers running and when a new
request arrives to server, all the 3 workers are busy.


In this case, the server - before the sendmsg - should
start the 4th worker, otherwise no worker can process
the request.

One more question: the worker is in recvmsg. However
if no request arrives within say 30 minutes, it should
end. Shall I use alarm to set the timeout ?

Giuseppe.


--- Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> ha
scritto:

Hi Beppe,

Yes, it's possible to have a variable number of
workers with
sendmsg/recvmsg. Also, the listener gets
notifications (SIGCHLD
signals) when each worker ends, so the listener
could spawn a new worker
if an existing worker crashes (for example). Or it
could submit a new
worker any time an existing worker ends. Or it
could have logic to
decide whether to spawn a new one or not, based on
the current load...

I understand that locks on the data queue can
provide you info about
which workers are currently active -- but if you
submit the workers
using the spawn() API, the workers are all child
jobs, so you can get a
list of them using the Qp0wChkChld API.

also, IBM recommends the sendmsg/recvmsg APIs
instead of
givedescriptor/takedescriptor. Here's their
description in the Info Center:

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzab6/cdescriptors.htm

beppecosta wrote:

Hi Scott,

Is it possible to have a variable number of

workers

with sendmsg/recvmsg ?

The server now handles a variable number of

workers.

It starts 10 workers but - when a new request

arrives

and no more workers are available, the server

starts

another one (up to a maximum number). Each worker
waits on a dtaq for a certain amount of time. If

no

message arrives within 30 mins, it ends. This

means

that in the nighttime you can have 2-3 workers
running, while in the peak hours you can have 20

or

more. Because each workers puts a lock on the dtaq

I

can alway know how many workers are running and I

can

end them easily by sending a message in the dtaq.

All that stuff run in a dedicated subsystem; when

the

crash occurred, the sbs was still on. I suppose

it's a

communication failure, but I don't know where to

look

for. Crash occurred 3 times in 10 month (twice

whith

the old 890 and once with the new 570), so there

is no

big deal about it, but I would like to find what's
causing this failure, and where the SIGTERM comes
from.

Giuseppe.







--- Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> ha
scritto:

beppecosta@xxxxxxxxxxx wrote:

I'have a socket server that spawns 10 workers.

The

server

waits on 'accept' (on a free high port - 52054 -

defined

in the Service Table Entry), while the workers

wait on a

dtaq.

You might consider changing this to use
sendmsg/recvmsg on a socket
pair. That would perform better, and have fewer
errors (in my
experience, anyway) than the old data queue
technique.

CPC1224 Completion 50 11/09/07 11:53:11,246936
QWTPITP2 QSYS 0601 *EXT
Message . . . . : Job ended abnormally.
Cause . . . . . : A SIGTERM signal was

received

for the

job. The action for the signal was to terminate

the job.


Sounds like they all received the SIGTERM signal.

At

the same time. Was
the subsystem ended, by chance? That would cause
this. It's possible
to manually send SIGTERM to each process using

the

kill() API, or the
'kill' QShell command, but that would require a
program to be written,
or a user to run the command.

By constrast, ending the subsystem, or ending all

of

the jobs, would
send this signal to all of them automatically.

You can write code (via the sigaction() API) that
will catch and ignore
SIGTERM if you like.
--

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

___________________________________
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html