Hi,
On Wed, Sep 24, 2014 at 10:59 AM, Fugitt, Jesse <jfug...@informatica.com>
wrote:
> 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 but before proceeding further, we wanted to know if there
> were any other workarounds we were missing or should we open a JIRA to
> allow access to the pn_error_t in the driver so we can clear it (or have it
> cleared automatically when it is accessed). Also, we saw there were some
> changes going in for 0.8 related to the posix and windows driver code but
> haven't looked at that in depth yet. Would any of those changes help us
> with needing to clear the error in the driver?
>
> 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;
>
>
> Should we open a JIRA on this?
>
I would definitely open a JIRA. My inclination would be to lean towards
exposing the driver's pn_error_t as the other modules do. The only slightly
tricky thing here is that pn_driver_error() is already taken so we either
need to break compatibility or not follow the same convention here.
The changes you mention coming up in the 0.8 release don't really impact
the driver, but rather provide something of a more flexible alternative to
the driver in the form of a cross platform selector API. Currently you'd
need to supply a bit of glue code yourself in order to use it, however it
might be worth having a look at.
--Rafael
