On 19 March 2012 15:47, Milan Crha <[email protected]> wrote: > On Mon, 2012-03-19 at 15:21 +0100, Julien Kerihuel wrote: >> Furthermore, there's no *real* case where Release call may fail. MS >> specifications doesn't specify one, and the only real case where it >> may happen is if we loose network connectivity. In such situation, we >> would release memory associated to the object anyway. >> >> I suggest we can move the different statements currently within if >> (retval == MAPI_E_SUCCESS) to the upper level and probably just add an >> assert or debug statement if Release() call fails. > > Hi, > I'm for debug print, rather than assert, though still, the error of > getting disconnected unexpectedly happens to users regularly, thus even > the print might not be ideal. > > When talking about disconnects, there is a bug against evolution-mapi > where users claim that they cannot reconnect after unexpectedly going > offline, like if VPN connection gets lost. My usual experience is that > the call to libmapi is just stuck somewhere deep in tevent, waiting for > a response on already dead connection, which was alive couple seconds > ago. I still do not have any clear idea how to fix it properly, but > that's a different topic anyway.
Yes, I've seen that too. It woiuld indeed be nice to have a solution to that. One possibility - though not in this 100% stuck case - would be to not discard the underlying NT error that otherwise gets reported, i.e. something like a GetLastNtError() since that can often give more meaningful info than MAPI_E_NETWORK_ERROR. For example, > Bye, > Milan > > _______________________________________________ > devel mailing list > [email protected] > http://mailman.openchange.org/listinfo/devel _______________________________________________ devel mailing list [email protected] http://mailman.openchange.org/listinfo/devel
