Thanks Harsh,Todd.
After 200 million years, spacemen manage the earth, they also know Hadoop,
but they cannot restart it, after a hard debug they find the txid has been
overflowed for many years.
--Send from my Sony mobile.
On Jun 25, 2013 10:52 PM, "Todd Lipcon" wrote:
> I did some back of the
I did some back of the envelope math when implementing txids, and
determined that overflow is not ever going to happen... A "busy" namenode
does 1000 write transactions/second (2^10). MAX_LONG is 2^63. So, we can
run for 2^63 seconds. A year is about 2^25 seconds. So, at 1k tps, you can
run your na
Yes, it logically can if there have been as many transactions (its a
very very large number to reach though).
Long.MAX_VALUE is (2^63 - 1) or 9223372036854775807.
I hacked up my local NN's txids manually to go very large (close to
max) and decided to try out if this causes any harm. I basically
b
Hi dear All,
It's long type for the txid currently,
FSImage.java:
boolean loadFSImage(FSNamesystem target, MetaRecoveryContext recovery)
throws IOException{
editLog.setNextTxId(lastAppliedTxId + 1L);
}
Is it possible that (lastAppliedTxId + 1L) exceed Long.MAX_VALUE ?
