RDBLK+1^HLCSTCP1, Attempt to read past an end-of-file,150373082,-%GTM-E-IOEOF in the error trap
Bug #526734 reported by
Jon Tai
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| OpenVista/GT.M Integration |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
Even after the fix for bug 526609, we're still seeing these in the error trap, although they don't cause the interface to shut down. My *guess* is that $DEVICE is set when the connection is fully closed (handled in bug 526609), but this EOF error occurs when we try to READ after the inbound stream is closed, i.e., the TCP connection is half-closed.
We should check $ZEOF just like we check $DEVICE -- if $ZEOF is set, and we're not in the middle of a message, close the connection gracefully and go back to listening.
Related branches
lp:~jontai/openvista-gtm-integration/bug526734
- jeff.apple: Approve
- Diff: 0 lines
| Changed in openvista-gtm-integration: | |
| milestone: | none → 0.8.9 |
| description: | updated |
Revision history for this message
| jeff.apple (jeff-apple) wrote | #1 |
| Changed in openvista-gtm-integration: | |
| status: | New → Fix Committed |
| Changed in openvista-gtm-integration: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
I *think* the EOF thing occurs when the MUMPS side has closed, and then tries to read. It's the opposite of the connection reset error, when the other side closes the connection and we try to read. If I'm right, then perhaps we should investigate why the MUMPS side is closing at all.