Enric Roca wrote:
> Hello,
>
> We are using Apache 1.3.26, Perl 5.5.3 and perl-cgi scripting to
> communicate to applications with XML. App1 calls the cgi script that
> is placed in the other machine. The script reads the XML message and
> pass it to pipe1. This message is processed by App2 and a response
> message is returned to pipe2 and sent to App1.
>
> The process works fine, but we have detected an issue when more that
> one XML message is sent at the same time. The first message that
> arrives is well processed but the second message is lost.
>
> Any ideas about what to do in the Perl script to avoid concurrency
> problems ?
>
> This is the script:
>
>
> #!/usr/local/bin/perl
> print "Content-type: text/xml\n";
> use CGI;
> read(STDIN, $cadena, $ENV{'CONTENT_LENGTH'});
>
> $cadena =~ tr/+/ /; # reeplace the + sign by spaces
>
> $request = "> /myfolder/mypipe/pipe1";
>
> unless (open(SYSREQUEST, $request))
> {
> die("Impossible to open the pipe $request\n");
> }
>
> print SYSREQUEST "$cadena\n";
>
> close(SYSREQUEST);
>
> $request2 = "/myfolder/mypipe/pipe2";
>
> unless (open(SYSREQUEST2, $request2))
> {
> die("Impossible to open the pipe $request2\n"); }
>
> while ( <SYSREQUEST2> )
> {
> print "$_\n";
> }
> close(SYSREQUEST2);
(Note that this is not a Perl issue, but an IPC design issue)
Do you have control over the program on the other end of the named pipes? If
so, I recommend you do this:
1. CGI script (client) creates a unique named pipe (perhaps using PID number
in the file name).
2. Next open the "pipe1" pipe on which the other program (server) is
reading. Client then writes it's other pipe name as well as the request data
to that pipe, delimited in some fashion.
3. Server reads the client's pipe name and request data. It processes the
request and then writes the response back out the client's unique pipe. In
this way, the server will write each response to a different pipe, so they
won't get intermixed or lost.
Note that the request data must less than PIPE_BUF bytes (as defined on your
system) in order to be written atomically. If you can't do that, you'll need
to either break up request data into PIPE_BUF or smaller chunks and identify
them by client, or perhaps use the "private" pipe created in step 1 to pass
the request data to the server.
If you do not have control over the program on the other end of the pipe,
you'll need to use some mechanism to serialize the requests so one client
doesn't try to read the other's response. You can use a lock file, a
semaphore, etc.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
