Bozo Dragojevic updated PROTON-372:

    Attachment: 0001-Handle-POLLHUP-as-pending-io.patch

This seems like a less heavy-handed approach to handling POLLHUP. 

Handle POLLHUP as pending io

According to http://www.greenend.org.uk/rjk/tech/poll.html and
it is better to treat POLLHUP as input event than an error.

If a connector is in a state where no input is expected,
like the final close frame was already received
the POLLHUP gets treated as output event.

> driver does not handle POLLHUP
> ------------------------------
>                 Key: PROTON-372
>                 URL: https://issues.apache.org/jira/browse/PROTON-372
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c
>    Affects Versions: 0.5
>         Environment: osx
>            Reporter: Bozo Dragojevic
>         Attachments: 0001-Handle-POLLHUP-as-pending-io.patch, 
> 0001-Handle-POLLHUP-as-POLLERR.patch, confuse-driver.py
> If a peer closes the socket at an inopportune time poll() will start 
> returning POLLHUP but not POLLERR. this drives messenger into a busyloop as 
> the driver does not check this flag.
> The messenger instance is still able to service other connections but it's 
> doing so at 100% cpu load as every poll() call returns immediately.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to