You are getting out of memory errors, add -Xmx1024M in your command line. But also try 0.7.2, it is better in memory requirements.

Try again with 0.7.2.

Those are normal, orphaned blocks being popped off. It is just being more detailed about what it is doing, to help with debugging.

I don't understand this code so I cannot change it. It is up to CfB and BCNext to decide if and when this should be fixed.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Release 0.7.2

http://download.nxtcrypto.org/nxt-client-0.7.2.zip

sha256: e8788f9cb5a7eef825526767ea39318f3aa58374d749f86b8e893c612be5937b


Change log:

Improved performance of blockchain scan.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJS91QDAAoJEFOhyXc7+e2AgtMQANVkTyLX7VaLsy5gKZOontgu
J5QqHgboQtkyvy+/uN3Holb1x62W3uN3kH9rob/WS68n1nXHzBF8adVfBtjgyhn5
GtxzWovbkStTrE4eatGDaTk+9WRVbEJeRTSM80VjAuo1jR8xGFHbXCTf1DnFuR0B
zE/tz7LJHmYPlUTfmvAvUfN+vUA55qNY7KcpQ5Davs+o3qCOFVmUXg6MQD2Egi+1
ROcJZUJTkIIZs3u43KUM9BaN3znwjD9j/CHx0d95t2Ol0dOzovPMRUaytiZVMvQq
jAwL0lVvxOq7GrqWLZu4+4rfcjjQNBYNWg3RX0o0NggwDj4LSqvlcvG4S4Z516Pk
EveNpAseRRtO8QDqigi+cMeSUWLMOSiXtMf2qbHxaHyXWMB1b4UWbwJsKdj7JgEY
m8hgn8I7z6RVx/Jsxt9xEsANV4xhmh/htviPOfppgkzOuYbd0GYXGZ+qquH+KQka
VZhYxVywTA35cmN2PC3OdEOldezxPRtehVQsWNWbiZhKbr6PmqCdTroSWqlwjia3
XMkyGbsWvNXQnrlVy+Av/FTbZT6PXq3TJZvLdryX+X5TSn9Ggl4EAHCd5qjEv59g
H767/G7UOul+fK5mbUMhbVT/AN5hZ5tvRufaVLkXUeiADGXGeZ1yshgFFHitFxLQ
RgOCSWd0nUt41gDPhE9O
=qoui
-----END PGP SIGNATURE-----

It seems to depend very non-linearly on the amount of memory. I don't have a better solution yet other than just making sure you give it enough memory. For me anything above -Xmx1024M works fine, 768M is slow, 512M crashed after more than 10 min of high CPU load. It is strange because last week I was able to run it with only -Xmx256M. These are the timings I get now:

-Xmx4096M:   55 s
-Xmx1024M:   58 s
-Xmx768M:     2 min 26 s
-Xmx512M:     > 10 min, out of memory

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Release 0.7.1

http://download.nxtcrypto.org/nxt-client-0.7.1.zip

sha256: 08f54b324ec4e644adc4864368e31c7ed14feb52918ca4522377c94d1f360f8a


Release 0.6.2

http://download.nxtcrypto.org/nxt-client-0.6.2.zip

sha256: cdb39d82e59aade4a0ea6b9f64fc9852fdab5d37a9a4ba755dffeaa96672aaf5


Change log:

Fixed a bug in the calculation of guaranteed balance which could in some
cases result in effective balance higher than the actual balance. Since
this change can produce a fork, a switch to the correct calculation will
happen at block 64000. Everyone should upgrade to either 0.7.1 or 0.6.2
before that block, or we will get forks.

Improved validation of peer addresses to prevent syntactically invalid or
unresolvable addresses from being included in the peers list.

Enabled logging of all debugging output to a log file. Everything printed
out to the console will also get logged to a file nxt.log. This should
help with submitting bug reports in case of crashes and errors, as it
doesn't matter anymore if your windows console just disappeared.
The nxt.log file is overwritten at every server restart.

Cleaned-up hallmark and authorization token processing. Added Token and
Hallmark classes, those can be now used by Java client developers to
generate and validate tokens and hallmarks without going through the http
interface.

Improved logging of block push failures and block pop-off events, those
will now print out the block id and the reason for block rejection.

Improved peer blacklisting and logging of reasons for blacklisting. Http
requests from blacklisted peers are now completely ignored.

Made all API request handling classes under the nxt.http package visible
in the javadoc documentation, to be used for documenting the parameters
and return values of the http API.

There haven't been any database related bugs in the 0.7 series. All the
above changes have been applied to both 0.6 and 0.7 branches. I encourage
more people to try the 0.7.1 version, there is no need to continue
maintaining the 0.6 branch very long if we don't encounter problems with
the database version.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJS9p7eAAoJEFOhyXc7+e2A44gP/iocZBytS+u/B2mpbcEAs0e2
VIpx8FLrAmSOX8Dwq+8O8PHdDVvbHeZuVpi9PZNmrZQnOlUfhqHF8MdGIBhEzRJw
f+koWWjSZTft5w/CKnM4PpvD1FzFh2XO/jMtkgI8nEu6YAXg6jwM6X2BqS6tSCNh
A65F+Juaw/na6n1HNCOt6SKj3tCdQf0xwNOeYCvqbkJL589n9WmHrqmPXhNmT52N
NvypwvY1uuNCG4Bd+rq6auw0tdCfFkxT82dIO2AlFWDjPQblBVKdg9PhNMtUaIDd
9/Go0YqC73+rIsRiLFWdxZqnJXprSMGVN5uUaHZ/eKBsROl5smuFsGODNcWK/+3k
p+35wI/ZG+fh9Lf5ALkJ3r0ZJh9JRLJrsOCnseTVFd6qMtvoxo6bWt/3kQgvBKNA
GFB01022UbPgPB5JwAF+adYDXOQ2MthGCIsb9y//smfHvsEXNahs9qYdhVhe2iIa
lmjqrSh34BrU3SMEGm6tsyYBTJ5akvrrm5JTBR6ujqR5VO5bjyWNxYIgewipzwJi
bvi6m5s06ldCggR5Yk1pLriOXjZUAFqTGUPFS6DMpUMezys+IJeCZ/Lh7M6dcCem
9E0H/Q0PpuMiZ7T5SccjyHr9ICT3jj805ERXvlc/YI+R0UGg6KPKijv/bU1pbf+/
BnqIfsUWg5zbkU6lkuja
=LewA
-----END PGP SIGNATURE-----

No, you shouldn't have to. Popping off a block or a few blocks is common and normal.

See, it is running out of memory. How do you start java, what -Xmx parameter do you use? Try:
java -Xmx1024M -jar start.jar

Must have a really slow hard drive... Not much I can do about that now, reading 100 MB database from disk can be expected to be slow, compared to when everything is in memory.

Eventually I will get rid of the need for a full scan. Now it is needed so that accounts, aliases, orders, etc, can be loaded and updated based on the information in each block and every transaction, and then kept in memory. When we switch to storing those in database tables too, a scan will be needed only when for some reason the content of those tables gets out of sync with whatever is in the blocks and transactions tables.

https://bitbucket.org/JeanLucPicard/nxt-public/issues

This is just a networking error, safe to ignore.

I need to know what gets printed out before the crash. Start it from the command line, or somehow prevent that cmd window from disappearing too soon. I don't know how, I never use windows.

If we get an academic to agree to do the review, we might better give them the latest cleaned-up 0.7.x source. Nothing has changed in the Crypto classes, but overall it will be much easier to navigate the code.

Not to such extent, either you are on a fork and rejecting blocks from the main chain, or most of your peers are on a fork and feeding you the wrong blocks all the time.

I should add logging of the blockId that was popped off, to be able to see which one it is and compare to the block explorer or another node.

Let me ask again. What error do you see on startup? As in, what gets printed to the console?

If you see the NRS stopped message and no errors, then there were no problem with the shutdown. What exactly error do you see on startup?

No, but make sure the server has been shutdown cleanly before saving that nxt_db folder.

Yes, the nxt_db files are supposed to be relocatable, the absolute path to them doesn't matter. Actually, in 0.7.0e their location is relative to the current directory from where you started java. I should make this a parameter at least.

I have special code that handles database upgrades automatically on startup. So yes, from 0.7.0e to 0.7.1 and anything later you should be able to upgrade without having to start fresh, even if it involves database changes such as new tables, columns or indexes.
Most likely no, it is never a good idea to try to backup a database while it is running. One day I will look into what facilities H2 has for doing live backups.

You are on a fork, just look at the huge % target numbers. No need to upgrade to 0.7.0e, but you have to delete the .nxt files and start again.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Release 0.7.0e - experimental

http://download.nxtcrypto.org/nxt-client-0.7.0e.zip

sha256: aa778bade323d2b3f4cf13c925aa7b541d57f0853a5828385b72254ac92010bc

Change log:

This is the first release using an embedded java database (H2) to store
the blockchain, instead of serialized java object files. Because this is
a major change, this version is to be considered experimental.

The blocks.nxt and transactions.nxt and .bak files are no longer used.
Furthermore, they will not be loaded at startup, when you start with
empty database the very first time it will need to download the full
blockchain from the network.

The database is stored under the nxt_db directory, as of now it will
take around 100 MB when downloaded. If anything goes wrong and you need
to start fresh, it is safe to delete that nxt_db directory, it will be
recreated.

There are no changes in the web.xml file compared to 0.6.1. I will add
parameters to tweak database settings later, if needed.

The database will use 50% of the memory available to java for its cache.
The actual value is printed out at startup.

Currently only blocks and transactions are stored in database tables,
everything else such as accounts, aliases, assets, orders, messages,
is loaded at startup and then kept in memory. The amount of memory
those take is still small, relative to what was needed for all blocks
and transactions.

At startup, the blockchain scan takes a bit longer, this is normal.
If anything else is unusually slow, I will look into profiling and
optimizing it.

There are no new user-visible features compared to 0.6.1, the code is
kept in sync now (including the critical bugfixes). Having both 0.6.1
and 0.7.0e nodes on the network should not result in forks. I will
maintain both the 0.6.x and 0.7.x branches for some time, until all
major database related issues are discovered and fixed. Please report
bugs, including the stack traces.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJS88S2AAoJEFOhyXc7+e2A45IP/j6Wy+UrJ3BTipd6ddcvtXuG
3CuNxP5XXZn56dW5/2CS9dWKLNUSaaQr6GV2z/bEVOQBZQ3XPkX6MYQaKucInDOC
LltAh6pvHN/plP/ll+Wlglwu3k/qM193hfFezAvXwJNiHym/NanYp9HRJRF8DJmz
ZB3J/Qr1K91+9mWUNd0kMXv9IhgOHMoP+CWOrAoefTk/7XNH9pOBDdi5uUHP0gtF
4O6kis5HVkICIVkHGNi8rdED5z6drQFYpnwm5OG0CONK9fUatymSRjUPy0PHd+aI
MRxihtfV05gRIhBOtrMre2WYbSTBCDL0ITy0b4ejtYW7WU2TC7bW8Gk10o6DjSbx
inOWUm5EWs1MbebpERskjVd8cLLc8EgGtBpuEs8XPmzNiWw7ma5msUpnbPFWF5hT
nYSOgmGzY5MsTaFLzGARXFm3xv52JS0mM+catOOCKyHH/+1geJXjkbyK5eVgtshJ
5TxdnUA/LjX73bAVJOtOJlULFHwzrnKfl26qGoZRwR9gSJRLEoeA8yW5Wv2Bnx9N
2fwkVy9cfTeZTerVe0r0SfxywqmDMG3Og+9GhxLD3qE58aolRC3yOZZnh1xspT+s
LI1j3Q6GbaR7Mb5QXbrs2qtxDRjdnrmg/4CkhTAmAku1nBFtgeCXJY/wgtxGH+BL
Q4q/PI4rf99LkSxbe2l+
=TssU
-----END PGP SIGNATURE-----