[ 
https://issues.apache.org/jira/browse/PROTON-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14172492#comment-14172492
 ] 

ASF subversion and git services commented on PROTON-708:
--------------------------------------------------------

Commit 1632098 from r...@apache.org in branch 'proton/trunk'
[ https://svn.apache.org/r1632098 ]

PROTON-708: changed pn_driver_error to return the pn_error_t

> C proton driver needs a getter function to access the pn_error so it can be 
> cleared
> -----------------------------------------------------------------------------------
>
>                 Key: PROTON-708
>                 URL: https://issues.apache.org/jira/browse/PROTON-708
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c
>    Affects Versions: 0.7
>            Reporter: Jesse Fugitt
>            Assignee: Rafael H. Schloming
>
> Our team is currently using Proton 0.7 and ran into an issue on Windows while 
> testing where we could not successfully reconnect to a broker once it was 
> taken down and brought back up (we are using a pn_driver_t in C).  It appears 
> that having the ability to clear the pn_error_t stored in the driver struct 
> would have solved the issue for us.  I'll include some of the details below 
> that were also sent to the mailing list but the solution is probably a pretty 
> easy fix that just involves adding a function to the driver that simply 
> returns its pn_error_t field.
> Details
> The Proton library's Driver Module (both Posix and Windows) does not supply a 
> mechanism to clear an error that was detected. In contrast, other modules 
> such as Connection supply a method to obtain the pn_error_t structure (see 
> pn_connection_error()). This method can be used in combination with 
> pn_error_clear() to clear an error.
> It was observed that when establishing a connection from Windows to a 
> potential broker on Linux that a WSAECONNREFUSED can be returned from the 
> connect() call if the broker is not running. This results in a call to 
> select() with a -1 file descriptor. The select() returns a socket error which 
> is recorded in the Error Module. The error number can be obtained using the 
> pn_driver_errno() call. Deleting the Connection and therefore removing the 
> erroneous -1 file description results in subsequent successful select() 
> calls. However, querying the Driver module for an error will perpetually 
> return the last error. There is no mechanism to clear that error.
> A small patch to the driver.c below is working for us currently but we wanted 
> input on what the best or more general solution to the problem should be:
> <   return d ? pn_error_code(d->error) : PN_ARG_ERR;
> ---
> >             int rtn = PN_ARG_ERR;
> >             if (d) {
> >                             rtn = pn_error_code(d->error);
> >                             pn_error_clear(d->error);
> >             }
> >             return rtn;
> On the mailing list, Rafael said his preference would be to expose the 
> driver's pn_error_t as the other modules do so it can be cleared rather than 
> auto-clearing it as we do in the sample patch above.  However, the 
> pn_driver_error function already exists so either we need to break convention 
> with the other modules in terms of the function name or break compatibility.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to