In message <20130109081141.GA21559@runtux.com> <20130109081141.GA21559@runtux.c
om>,
Ralf Schlatterbeck writes:
>I think I'll have to look into this more closely...

Ralf, I have attached the test tracker tarball I sent to Bernhard. It
includes the auditor and reactor that Bernhard started with.

In an earlier email you asked if it was just an auditor and the answer
is no it is both an auditor and reactor.  But the auditor *does not*
call a get on the database. It just uses the info passed to it in the
db.tx_Source string.

Did I understand you correctly when you indicated that doing a
cl.get(nodeid, 'tx_Source') in the auditor would cause parallel update
transactions to realize they are stepping on each each other and cause
a conflict warning.

In any case the instructions for using the tarball with the test
tracker and the exported test data are:
===========

You should be able to untar the tarball at the top of a roundup
development tree (I am using one with Bernhard's patch applied to
it). It will create the new test template
(share/roundup/templates/test) and the directory demo.exp.

  python demo.py -t test ...

should get you a working tracker. Exit the server and then use:

 PYTHONPATH="$PWD" python  roundup/scripts/roundup_admin.py -i demo
 import demo.exp
 commit
 exit

should get you 4 users and 4 issues and 4 keywords that you can use to
test.

Then restart the demo tracker web interface and make a change to one
of the issues.

Then change the issue in the web interface and via the email interface
and sumit them at the same time. If you try that enough times, in the
journal you will see it get confused and group the change that arrived
via email with a tx_Source that says web.

contents of email_1:
====
From: user4
Subject: [issue4] issue4 [keyword=+keyword1]

====

Email submission can be done using:

  SENDMAILDEBUG=1 PYTHONPATH="$PWD" python roundup/scripts/roundup_mailgw.py demo < email_1

Each change should result in output from the tx_source_detector of the
form:

  tx_SourceCheckAudit(1) pre db.tx_Source: cli, nonce: 84a7b7fe7e99b584f2a3
  tx_SourceCheckAudit(1) post db.tx_Source: cli, nonce 84a7b7fe7e99b584f2a3
  tx_SourceCheckReact(1) pre db.tx_Source: cli, recorded: arrived via: cli 84a7b7fe7e99b584f2a3
  tx_SourceCheckReact(1) post db.tx_Source: cli, recorded: arrived via: cli 84a7b7fe7e99b584f2a3

where pre/post occur before and after a 10 second sleep in the
detector allowing multiple changes to overlap. As you can see above
this change was done to issue 1 (number in parens above) using the cli.

The nonce is a random (and hopefully unique) value to identify the
transaction as it passes through the detectors.

In the history this looks like:

  2013-01-04 01:18:24	admin	set	tx_Source: arrived via: web c05d48aea9f81a9ae254 -> arrived via: cli 84a7b7fe7e99b584f2a3
     keyword: + keyword2

with multiple changes in flight at the same time, we end up with the
journal tx_Source not matching the method by which the change
occurred, and that's the bug.
==========