<div class="gmail_quote">On Mon, Nov 16, 2009 at 11:41 PM, Brett Henderson <span dir="ltr"><<a href="mailto:brett@bretth.com">brett@bretth.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div><div></div><div class="h5">On Wed, Nov 11, 2009 at 8:59 AM, Brett Henderson <span dir="ltr"><<a href="mailto:brett@bretth.com" target="_blank">brett@bretth.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div>Tom Hughes wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 10/11/09 00:09, Matt Amos wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
possibly it's a coincidence, but changeset 3073502 was committed in<br>
transaction 174978321, which is the txnMax of replication diff 84538.<br>
i don't see anything special about that number, though.<br>
</blockquote>
<br>
Ah... I investigated an issue like this a couple of weeks back. I suspect there is an off by one error somewhere that means the last transaction in each diff isn't getting processed by osmosis when it builds the replicate diffs.<br>


</blockquote></div>
That's highly likely :-)  The id logic is a bit funky so I might have made some mistakes in there.  I'll do my best to take a look at it.  Probably won't get to it for a few days though ...<br></blockquote></div>
</div><div>
<br>I've taken a look and believe I've fixed the issue (in svn only for now).  The code was retrieving a transaction snapshot from the server which among other things includes the xMax value.  This value is the next *unassigned* transaction identifier.  Osmosis was then building a query which attempted to retrieve data with that transaction identifier included even though it hadn't been committed yet.  This means that the transaction identifier would some time very soon after get committed to the db but Osmosis would never query for that id again.  Not sure what I was thinking when I did that but I guess I just didn't read up on the meaning of xMax properly.<br>

<br>I think I've fixed the code and I've checked in my changes.  I'll deploy a new version of Osmosis to Services/Horntail hopefully in the next 12 hours.  I'll probably create a minute-replicate2 initially but will update the existing minute-replicate once it looks like it's working and kill the minute-replicate2.<br>

<br>The replication is reasonably simple in theory but gets tricky in practice due to wrapping txn ids, use of unsigned integers (which aren't directly supported in java), and reserved transaction ids.  Hopefully it's one step closer to working properly now.<br>
</div></div></blockquote><div><br>Osmosis 0.31.3 (the latest svn) has been deployed.  I've done some basic testing and the new version appears to produce much the same results as the old one but hopefully without missing data.<br>
 <br></div></div>If anybody sees any problems please let me know.<br><br>Brett<br><br>