Ripple API

[JoelKatz]

Ripple network times are seconds since 1/1/2000, 00:00:00 UTC.

[1714892890]

1714892890

[Arvicco]

Ripple network times are seconds since 1/1/2000, 00:00:00 UTC.

Thanks, you need to update https://ripple.com/wiki/JSON_API then:

time: An unsigned integer. Number of seconds since the UNIX epoch: Janurary 1, 1970.

[JoelKatz]

Yeah. Sorry about that. We considered changing it to seconds since the UNIX Epoch or text times, but that would make things awkward when we're reading JSON. (We'd have to know if an integer was a time in order to know whether to apply the offset.)

The documentation has been fixed.

[Arvicco]

Ripple network times are seconds since 1/1/2000, 00:00:00 UTC.

BTW, your timestamp formats are inconsistent across events. Such as, "ledgerClosed" event has its timestamp in Unix epoch, rather than Ripple epoch. This is confusing.

[JoelKatz]

Nice catch. I'll check to make sure it won't break anything and see if it can be changed to be consistent with all the other times. The "ledger" command also reports close times like "2013-Mar-08 21:16:10", which is a bit annoying (I don't even know if that's local time or UTC, *sigh*). We wanted the JSON format to be mostly human comprehensible, but times get ugly because we don't always know that something is a time when it's being parsed. (And the JSON output and input formats are supposed to be compatible.)

[nelisky]

For my current use case I need a polling approach to following up transactions (as opposed to subscribing to events). This is all fine for payments received but I can't see any reference to payments sent from the source account. I can in fact see the transaction received on the destination.

Is this by design? Shouldn't payments sent also appear in account_tx?

[JoelKatz]

For my current use case I need a polling approach to following up transactions (as opposed to subscribing to events). This is all fine for payments received but I can't see any reference to payments sent from the source account. I can in fact see the transaction received on the destination.

Is this by design? Shouldn't payments sent also appear in account_tx?

Payments sent should appear in account_tx. Perhaps you're trying to query for too many transactions at once? The limit is currently 200 transactions in most cases. The transactions appear with the most recent transactions first, that might be throwing you.

[nelisky]

Nope, I'm asking for 2 tx only. I'll send you the exact query tomorrow (work computer already off for today).

[nelisky]

@JoelKatz it appears this only happens agains my local rippled, so something must have gone wrong with it. I'm recompiling to the latest, but if it keeps happening is there something you'd want me do before I nuke everything out and start from scratch?

[JoelKatz]

@JoelKatz it appears this only happens agains my local rippled, so something must have gone wrong with it. I'm recompiling to the latest, but if it keeps happening is there something you'd want me do before I nuke everything out and start from scratch?

By default, the server only acquires 256 back ledgers. You can set the history higher if you want (search the config file for "ledger_history"). If you don't have the ledger a transaction is in, you can't provide the transaction to clients who ask. If you look in the 'server_info' output, you'll see a field called 'complete_ledgers'. This is the range of ledgers your server has fully indexed and locally available.

[nelisky]

@JoelKatz it appears this only happens agains my local rippled, so something must have gone wrong with it. I'm recompiling to the latest, but if it keeps happening is there something you'd want me do before I nuke everything out and start from scratch?

By default, the server only acquires 256 back ledgers. You can set the history higher if you want (search the config file for "ledger_history"). If you don't have the ledger a transaction is in, you can't provide the transaction to clients who ask. If you look in the 'server_info' output, you'll see a field called 'complete_ledgers'. This is the range of ledgers your server has fully indexed and locally available.

Sure, I'm kind of, sort of aware of that (I didn't know to look for complete_ledgers) but since I get one half of it, the received payment tx, I should have the ledger, right?

This does present a separate issue, though; how much is enough? If I start the server with history to 256, does that mean it prunes history to last 256 while running, or just that on startup it requests only the past 256 ledgers (if they aren't already local).
I guess my question is how to properly handle long periods between polling the server for new tx.

[nelisky]

"complete_ledgers" : "339007-341774"

source @f3b837eea654deec3572a89a000f2b6e13156f6a, same issue. I'll nuke and start afresh, probably something went sideways with my deploy.

[JoelKatz]

Are you saying there's a transaction you know was placed in a ledger inside the range of completed ledgers you have and account_tx isn't showing it? Or are you saying your server isn't acquiring a ledger it's supposed to acquire?

You can use account_tx against our server to get the 'inLedger' field to see what ledger a transaction was included in. Then check your server to see if it has that ledger. If it doesn't, make sure it's configured such that it should. If it should have it but doesn't check server_info every few minutes to see if it's still acquiring ledgers.

[nelisky]

I have nuked the db and changed ledger_history to 65536, now waiting for rippled to catch up with the ledger in question.

What was happening was: I had the ledger (339675), a 'rippled ledger 339675' would show it (in full default with 'full'), and then:

./rippled account_tx rLDDq8ZGhCaVBP8MyYTifhCJzgWPQBjwpt 339675 339675
would show the transaction

./rippled account_tx rfYv1TXnwgDDK4WQNbFALykYuEBnrR4pDX 339675 339675
would not (but not with a 'ledger not found' error, should wouldn't show any tx detail).

./rippled account_tx rfYv1TXnwgDDK4WQNbFALykYuEBnrR4pDX 339675
./rippled account_tx rLDDq8ZGhCaVBP8MyYTifhCJzgWPQBjwpt 339675
Both the above commands would also not show errors nor anything about the tx.

Running any of these commands against s1.ripple.com does work as expected, so it is something local to me.

[nelisky]

Same difference,

./rippled account_tx rfYv1TXnwgDDK4WQNbFALykYuEBnrR4pDX 339675 339675

Connecting to: 127.0.0.1:5005
{
   "result" : {
      "account" : "rfYv1TXnwgDDK4WQNbFALykYuEBnrR4pDX",
      "status" : "success"
   }
}

Oh, well, gona build from a fresh checkout now

[JoelKatz]

This could potentially happen if you wiped your transaction database but kept your ledger database. The ledger database would tell the server that it had processed the ledger and didn't need to re-process it. The 'account_tx' command uses part of the transaction database to find all transactions that affected the selected account.

Data scrubbing is on our road map. This will also allow us to remove old data that's no longer referenced, if desired. (This is not as simple as it sounds because we know when we first fetched data, but whether that data is still in use or not in use, it sits there just the same. So we'd need to do background scrubbing to determine when we stopped needing it.)

[nelisky]

I removed the whole db directory, so I'm sure that's not it. I have now built from a clean checkout, started without any database, ledger_history is 65536 and... it still happens

If I issue the same account_tx to s1.ripple.com it returns the correct data, but against my local ripple it gives me nothing (for the source address, it is correct for the destination address). I have a small debug log that I will provide you, but it gives you little to nothing from what I could read.

Can you tell me the exact revision that is running on s1.ripple.com? Are there other public servers I can try the account_tx command against?

[JoelKatz]

I removed the whole db directory, so I'm sure that's not it. I have now built from a clean checkout, started without any database, ledger_history is 65536 and... it still happens

You waited until your server reported that it had the ledger? That's the only thing I can think of. I'll look over the code just in case there's something I might be missing.

Can you tell me the exact revision that is running on s1.ripple.com? Are there other public servers I can try the account_tx command against?

It's the head of the git repository as of this morning:

commit 92318a47bd59659e2dbfde174b14893ee2fe4afa
Date:   Sun Mar 10 19:15:28 2013 -0700

[nelisky]

You waited until your server reported that it had the ledger? That's the only thing I can think of. I'll look over the code just in case there's something I might be missing.

Yes, I did. Had I not done it there would be an error 'No such ledger'. It also dawned on me I'm using a very low end 32bit machine for this, not all that much ram also. I will try to run this on a separate system that has proper server specs.

[JoelKatz]

Yes, I did. Had I not done it there would be an error 'No such ledger'.

I don't think account_tx will ever give you "no such ledger". You can query for transactions from ledger zero to ledger one million and it will give you the latest 200. (Arguably, it probably should tell you which ledgers it has in the reply, but you can always check, it's published to the "server" stream.)

It also dawned on me I'm using a very low end 32bit machine for this, not all that much ram also. I will try to run this on a separate system that has proper server specs.

We don't test extensively on 32-bit machines. 1GB should be sufficient. If you have less than 1.5GB, leave your "node_size" at "small" (the default). This will cause the system to use less RAM in exchange (mostly) for more disk I/O.