PDL Error: read returned error 34

We get the same error occasionally.

Last night this error repeated in the log without any significant delay between error messages. The error and process logs filled up the disk in about an hour an a half, then all the engine processes and monitor daemons died because the disk was full. A couple hours after that someone noticed that Cloverleaf might be the cause of order problems they were having, and I got to restart everything at 3:20 in the morning.

This happened here on Christmas Eve.

A process wrote this message to the log:

[pdl :PDL :ERR /0:  hpf_oru_out:12/24/2013 09:52:27] read failed: Connection reset by peer

Followed by a bazillion copies of this error:

[pdl :PDL :ERR /0:  hpf_oru_out:12/24/2013 09:52:27] read returned error 34 (Numerical result out of range)

Until, apparently, the process core dumped and all interfaces in all sites of our LIVE Cloverleaf engine died.

The resulting log file was 2,147,483,647 bytes.  The err file was 2,147,463,691 bytes.

Any idea what might cause this?

We are running CL 5.6.

We used to get this unending stream of errors when a connection was dropped without being closed properly. In our case it was a network switch whose time-out was shorter than the shortest keep-alive setting. Of course, your mileage may vary.

The receiving system, HPF, was having serious problems at the time this occurred, so it’s entirely possible it just quit responding abruptly.

Cloverleaf shouldn’t go into a panic like this, however…

For the Infor people on this forum – how should Cloverleaf respond in a situation like this?  Is this a known issue?

I’ve seen the read error when partial messages are sent through the connection. It may have been that it sent part of the message, then the connection closed, then sent the rest when the connection re-established.

The best thing to do is to update the PDL to perform one of the following actions when the read error occurs:

* Sync to a start pattern

* Clear the read buffer

* Clear the buffer and restart the connection

Which one you do depends on how the protocol works and if its syncable. In general I would clear the read buffer and restart the connection if it cannot be synced to a unique pattern.

My guess is that the pdl isn’t handling errors correctly or the application is sending rubbish data.