[ 
https://issues.apache.org/jira/browse/PROTON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

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
http://lkml.indiana.edu/hypermail/linux/kernel/0404.0/0770.html
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