373404 - improve palmsync error checking and logging, and feedback to the hotsync manager

Status: RESOLVED FIXED

(MailNews Core Graveyard :: Palm Sync, defect)

Description

[Wayne Mery (:wsmwk)]

Follow up to bug Bug 183722.  Areas for improvement include ensuring all return codes are provided and returned, logging of additional events to the optional conduit log, and adding feedback to the the hotsync manager during conduit operation.  

David, I don't know winapi threading. CMozABConduitSync::PerformFastSync() looks to me like it always returns success (ends with "return 0"). Does this need to be revised to properly propagate the return code so it can be evaluated?
http://lxr.mozilla.org/mozilla/source/mailnews/extensions/palmsync/conduit/MozABConduitSync.cpp#621

Comment 1

[Wayne Mery (:wsmwk)]

examples for improvement with conduit log 

1. if name='' then the AB should not probably not be synced. Not sure yet about the '-1' entries.  Example log...

Getting moz AB List ... Done getting moz AB List. 
Moz AB[0] category index/synced=-1/0, name='', url='moz-abmdbdirectory://impab-4.mab'
...
Moz AB[5] category index/synced=-1/0, name= '', url= 'moz-abmdbdirectory://impab-11.mab'
...


2. after sync hits 15 palm categories and attempts the 16th it should kick an entry in the HSM log. The conduit log entry looks like this.

Moz AB[15] category index = 5, name = '' doesn't exist on Palm so needs to be added to palm
  Creating new Palm AB with 1 record(s) ... Done creating new Palm AB, new category index=-1. retval=-2000.
Creating new Palm AB failed. retval=-2000.

Comment 2

[Wayne Mery (:wsmwk)]

Attachment: fix retun code in PerformFastSync v1

from comment comment #0, CMozABConduitSync::PerformFastSync() always returns success after finishing CreateThread to run DoFastSync - not good when the return code of the most used sync method (PerformFastSync) is untrustworthy. Also add missing log entry in DoFastSync for GetPCABList return code

references:
http://www.codeguru.com/cpp/misc/misc/threadsprocesses/article.php/c3791/
http://msdn2.microsoft.com/en-us/library/ms683190.aspx
http://msdn2.microsoft.com/en-us/library/ms682512.aspx

note: the thread handle is not closed

Comment 3

[Wayne Mery (:wsmwk)]

Comment on attachment 263276 [details] [diff] [review]
fix retun code in PerformFastSync v1

(In reply to comment #2)
> Created an attachment (id=263276) [details]
> fix retun code in PerformFastSync v1

David, neil commented "the code looks vaguely reasonable".  Will also need your checkin magic

Comment 4

[Wayne Mery (:wsmwk)]

?

Comment 5

[Wayne Mery (:wsmwk)]

checkin?

Comment 6

[David :Bienvenu]

I can't do this until Monday...I'll try to remember to do it then. Please feel free to ping me again then if I forget.

Comment 7

[David :Bienvenu]

Comment on attachment 263276 [details] [diff] [review]
fix retun code in PerformFastSync v1

fixed on trunk, thx, Wayne

Comment 8

[Wayne Mery (:wsmwk)]

(In reply to comment #7)
> (From update of attachment 263276 [details] [diff] [review])
> fixed on trunk, thx, Wayne

David this worked OK on trunk. yay!

please checkin on branch

Comment 9

[Wayne Mery (:wsmwk)]

Attachment: fix retun code in PerformFastSync v1 [1.8 branch]

branch version of attachment 263276 [details] [diff] [review] - line # changes only, no code change

Comment 10

[David :Bienvenu]

fixed on trunk and branch, thx, Wayne!

Comment 11

[David :Bienvenu]

Comment on attachment 266952 [details] [diff] [review]
fix retun code in PerformFastSync v1 [1.8 branch]

clearing request - this looks like it's on the 1.8.1 branch already.