[Chandler-dev] Problem with stamping and collection notifications/ kind watchers

Travis Vachon travis at osafoundation.org
Tue Jul 18 17:19:09 PDT 2006

Hi Andi,

After talking more with Bryan about this, I understand more clearly why
a commit during a refresh is kind of tricky. While it might be a nice
feature to be able to do this, I've actually found a way around doing it
in my particular situation which isn't actually all that weird.

If you still think this is something you'd like to work in, I'd be
willing to do the test you mentioned, but if not, I'm just as happy at
this point not worrying about it.

Bryan, one other note: you mentioned at one point that you could put a
commit back in after stamping happens. This seems to make sense, and if
there are no objections, it would be convenient for me to have this happen.

Thanks again,


Andi Vajda wrote:
> On Tue, 18 Jul 2006, Travis wrote:
>> Hi all,
>> I've found something which seems like a bug in the interaction
>> between the notification framework and stamping.
>> When new mail messages enter Chandler, I'd like to annotate them and
>> put them into a mail directory Item so they will be accessible to the
>> IMAP server. Currently, this works perfectly for all the entry cases
>> I've tested (the IMAP client, Item>New Item>Message, drag and drop
>> from Thunderbird/Mail.app/etc) except stamping. When a message is
>> stamped, a repository commit during the callback causes a very nasty
>> error (which I've reproduced at the bottom of this page).
>> A bit more exploration led to the creation of a parcel which
>> illustrates this bug. It appears that the problem is indeed caused by
>> the commit during an onCollectionNotification or watchKind callback.
>> Removing the commit fixes the problem, and the test parcel is
>> sufficiently simple that it seems likely the bug is coming from code
>> already in Chandler's trunk.
>> Grant did some exploring and found the following:
>>> So, here's what's seems to be going on:
>>> The self.onCollectionNotification() callback that results from
>>> notificationQueueSubscribe() is always happening in the main thread.
>>> When you commit your changes (as you should), that causes a whole
>>> bunch of stuff to happen, including changes to CPIA blocks in the
>>> app. That eventually causes CPIA to get into a weird state; probably
>>> what's happening is the commit in the middle of the refresh exposes
>>> some dependency on the order of notification processing. 
> Doing a commit() inside a refresh() seems a little fishy and is sure
> to raise some interesting questions about the sequence of things. At
> the end of refresh(), a number of notifications are sent out,
> including the asynchronous ones from the collection watch queue used
> by CPIA (and CPIA only).
> Something that might work better, if you must trigger a commit()
> inside a refresh(), is doing it asynchronously as well. Wait for
> refresh() to complete and then commit(). One way to do this might be
> for me to delay any calls to commit() inside refresh() until refresh()
> is done.
> If you can simulate this by placing a call to commit() at the end of
> refresh() in repository/persistence/DBRepositoryView.py and calling it
> when a condition of yours is reached (use some global hack) and verify
> that it works, I can then add support for that. What do you think ?
> Andi..

More information about the chandler-dev mailing list