Guys any link to 0.5? First page link doesnt work.
We didn't organize it well for this release, but from now on new releases should always appear on http://info.nxtcrypto.org in addition to my announcement here. And you should be able to use the built-in update checker, http://localhost:7874/update.html to check for new versions, and download and verify the zip package. |
|
|
|
Bad luck, two times had a chance and both time didn't succeed. This is not bad luck, this is a my habitude  But question remains: if I don't need to restart java console, do I need only reload client side in browser? Because after this accident, recent blocks became with minus sign ant still minus quantity increases, looks like client lost the chain. If the recent blocks became negative, it is a bug then. We haven't seen this bug recently and I thought it's gone, but apparently not. Next time this happens please report any errors from the console. If reloading the page and restarting the browser isn't enough, then you also have to restart the java process indeed. |
|
|
|
Why java process periodically asks to connect to hosted-by.leaseweb.com, TCP 32151?
Is this some sort of node statistics or what? Should I allow it?
This is just a node listening on a non-default port, not to worry. But you don't need to allow it if you don't want to. |
|
|
|
Had a problem: I had two chances of forging the block, but both time it was not forged, recent blocks became with "-" sign and get the error in java console. Had to lock account and restart the process.
What error did you get? If other than the normal "Generated an incorrect block..." error, please post the full error message here. Error was like "Generated an incorrcst block...". Just to know about my luck or there is something I need to fix. Then it's just bad luck, but that doesn't require a restart. |
|
|
|
Had a problem: I had two chances of forging the block, but both time it was not forged, recent blocks became with "-" sign and get the error in java console. Had to lock account and restart the process.
What error did you get? If other than the normal "Generated an incorrect block..." error, please post the full error message here. |
|
|
|
NEWSThe last chance to claim unclaimed coins is over. We have ~13M coins left and they'll be spent for rewards, bounties and development. Now we are running a reward program. I ask the community to post here links (with short description and link to BTT profile) to projects/persons that helped to promote Nxt. Only projects launched before the 3rd of Jan can apply. There will be several categories, BCNext will choose 3 best participants from each category. I'll contact project owners via BTT personal message to get Nxt account ids for reward payments. The 1st place will receive 50'000, 2nd - 30'000 and 3rd - 20'000 NXT. Categories: - Exchanges - Faucets - Giveaways - Utilities (blockchain explorer or http://nxtra.org/nodes/, for example) - Videos - Articles - Bug reports - Tech support - Public nodes deployment - Clients Please, mark project/person names with bold blue font. We r supposed to complete the list within 24 hours starting from now. My nominations: Public node deployment: Fermenthttps://bitcointalk.org/index.php?action=profile;u=181968*.nxtbase.com nodes laowai80https://bitcointalk.org/index.php?action=profile;u=155505https://bitcointalk.org/index.php?topic=345619.msg4103726#msg4103726Utilities: wesleyhhttps://bitcointalk.org/index.php?action=profile;u=173482http://nxtra.orgnexernhttps://bitcointalk.org/index.php?action=profile;u=168386blockchain explorer http://87.230.14.1/nxt/nxt.cgi?action=1Clients: wesleyhhttps://bitcointalk.org/index.php?action=profile;u=173482mac client at nxtra.org nexernhttps://bitcointalk.org/index.php?action=profile;u=168386native client work in progress mistafreezehttps://bitcointalk.org/index.php?action=profile;u=23095windows installer https://nextcoin.org/index.php/topic,1902.0.htmlArticles: utopianfuturehttps://bitcointalk.org/index.php?action=profile;u=182582https://www.dropbox.com/s/xlzequz7qrggq80/First%20document%20of%20Nxt%20asset%20exchange.pdfAliashttps://nextcoin.org/index.php?action=profile;u=64https://nextcoin.org/index.php/topic,1890.msg18446.html#msg18446Bug reports and code reviews: minusbalancerhttps://nextcoin.org/index.php?action=profile;u=3975https://nextcoin.org/index.php/topic,1228.msg10291.html#msg10291https://nextcoin.org/index.php/topic,2045.msg20178.html#msg20178ImmortAlexhttps://bitcointalk.org/index.php?action=profile;u=131473https://bitcointalk.org/index.php?topic=397214.msg4287958#msg4287958(and more in the same thread) Jaguar0652https://bitcointalk.org/index.php?action=profile;u=183319https://bitcointalk.org/index.php?topic=397183.msg4298078#msg4298078https://bitcointalk.org/index.php?topic=397214.msg4296420#msg4296420ricothttps://bitcointalk.org/index.php?action=profile;u=205282https://bitcointalk.org/index.php?topic=397183.msg4307959#msg4307959https://bitcointalk.org/index.php?topic=397183.msg4296595#msg4296595Videos: Pinarellohttps://bitcointalk.org/index.php?action=profile;u=104283https://www.youtube.com/channel/UC-krT2yl3xjKM8-ZCHkgeRw/videosWebsites, News, Forums: intelhttps://bitcointalk.org/index.php?action=profile;u=102387info.nxtcrypto.org Hosting new client packages and announcements Developer tech support with release uploads and communications opticalcarrierhttps://bitcointalk.org/index.php?action=profile;u=165191*.nxtcrypto.org sites, The Nxt Foundation https://bitcointalk.org/index.php?topic=345619.msg4242429#msg4242429QBTChttps://nextcoin.org/index.php?action=profile;u=498www.nxtcrypto.org |
|
|
|
I will investigate if I can add those in the next release. |
|
|
|
One more thought about memory usage.
I see a lot of getBytes().length calls on Transaction and Block. Especially in Transaction.compareTo() this can create a lot of temporaty byte arrays in short time. But length can be easily and much faster calculated without creating array. I think, even for any Attachment.
Not fixed yet, but already I have a //TODO: cache? on top of those getBytes() methods. And indeed need to do it for caching the length. |
|
|
|
Here are a few more thoughts: (1) This is a minor thing, but i don't think you're checking for overflow in any of the request parameters: int timestamp = ((Long)transactionData.get("timestamp")).intValue();
short deadline = ((Long)transactionData.get("deadline")).shortValue();
byte[] senderPublicKey = convert((String)transactionData.get("senderPublicKey"));
long recipient = (new BigInteger((String)transactionData.get("recipient"))).longValue();
int amount = ((Long)transactionData.get("amount")).intValue();
You're casting the value to a Long and then to an integer, but not checking if truncation occurred. [I would probably move the validation to the Transaction or a transaction factory function. You can also move the validation of positive and valid amounts and fees here]. I have added a few more checks for the values of Transaction.amount and Transaction.fee in 0.5.0. I agree the validation checks are all over the place and need to be cleaned up. (2) You're locking around every call to setBalance / setUnconfirmedBalance, which makes it easy to call the functions incorrectly if you forget to call them from within a lock. IMO, it would make sense to move some of that locking into the functions themselves so they can't be called incorrectly. [you can also change these functions to incrementXyz, since that's what you appear to be doing.
This was already on my list of things to fix, and I have fixed in in 0.5.0, but thanks for noticing. (3) Instead of a giant doGet function, imo, it would make sense to consider a chain of responsibility where you move each potential action into a separate object
I know, just no time to do that yet. |
|
|
|
What if there would be 2 transactions instead of 1? If I want to send 1000 nxt to John, system will send him 1 Nxt first. It will show me - you sent 1 Nxt to John. Do you want to cointinue and send him 999?
Fine, and then the bug will show up at the second transaction and still send the 999 elsewhere. Without knowing where the bug is, attempts to work around it like that will only complicate the code. |
|
|
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Version 0.5.0 is now available at: http://info.nxtcrypto.org/nxt-client-0.5.0.ziphttp://www.nxtcrypto.org/nxt-client-0.5.0.ziphttp://forums.nxtcrypto.org/nxt-client-0.5.0.zip(it may take some time to get it uploaded to all the above, so try whichever works) sha256: c0676985f9ef08852250ba1d3fe980ee1392c3f70be6917f384f3636fa6f06e3 This is to be considered stable release. Change log: Fixed more concurrency issues, performance optimizations and code cleanup. I have fixed all the visible code issues that I consider to be bugs, the remaining TODO's on my list are a matter of code cleanup and refactoring. Added a checkpoint at block 30000 (the start of transparent forging block). Added wesleyh's update checker: https://bitcointalk.org/index.php?topic=345619.msg4294180#msg4294180Use https://localhost:7875/update.html to check for updates - this feature may still have bugs, but including it in the package is a good way to get people to test it on multiple browsers. I have not been able to find any possible cause yet for the most critical in my opinion bug reported so far, transactions being sent to a recipient different than the one selected. I have read through the relevant code again, but don't see any obvious way how this could happen. I am not ignoring those reports and believe it may be a real bug and not a user error, but without a way to reproduce the problem, it is very hard to track it down. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJSyB4TAAoJEFOhyXc7+e2AJ2kP+waLjbK+mhaNHxWUqruv0jrD 74xzaZ4AqZ0jseM95CEqanolrRhWqYJYrxvX5X+JVyG1ERQBj159jp6OuEjdn4G4 NWwTI5uP3QghrIZ1KCh0bG3uUYB3pSrGvjP7n10YH4er2kWtUzT+EZltSlTblUMB SufMnr/9IbIm6d30hhTh9cUW7jzkQbP0Q1YqdOJsrmEuyWW+ZSGuOcU25naglQ2G RV/7sIKN0JCebe0Xe3qjwI12E5yq2DccTjgTwP74o1aVOHcdonIgocu963X49kql /j8uB6ue8rxQ+fhwXpHTwZYC4ysZP1kFP0NKxNh0S0PoPfdlH51aAO2pJhQyOQBB 06BH8NSXKvJx7SUmBP85X9Q1oYXHggTc6RPM3quvLd4B5zkZuztG03i6jIRBVAQ6 lnyq8SJTabfmHK0F1qyyLSZkGwirWZUSrOP04uA3XE6zRT1FSmv/eRx+Mio/0ryE XOAnIraWEMz7/12hYEdDWtsZWXMstdTrWPOveTODeko4gEppx3b/xgon/EVP4q4O 1pl/pBD0KOXv50XWF9488137RUy6EHRPy6ErF0IPIs3sZQTo+o8X2PJ+yK6dmkEN owAr7Yu9tJ0AcLhltkXBxxCcTXQj9MohCics0/CJs51wHv+rrvMFPexHqd1Z2E4V 1p/VUMYOjcG0zcCuWUnd =VNK0 -----END PGP SIGNATURE----- |
|
|
|
Hire this guy. If only for his nick yes, do it asap! Well, he just mentioned a few posts above that he is too busy to be a full time developer. But if ImmortAlex wants to contribute part time, we seem to think similarly so this may work. The problem right now is it will be difficult to split the work between multiple developers, as you can see everything is in one huge file which needs a lot of refactoring. Distributing who can do what without stepping on each others work, and then merging the changes, will take almost the same time as one person doing it all. |
|
|
|
Found static byte[] convert(String string) and static String convert(byte[] bytes) ineffictive. Need I suggest some solutions (like Apache Commons )? Those convert methods also bothered me at first look, but I decided to leave it for later if they need optimizing. My girlfriend promised to buy me a license for YourKit (hey, they have a sale now, personal license is only $99 instead of $500) and I will spend some time profiling. It is only worth optimizing things that really are measured to be a problem. |
|
|
|
There are also a lot of places where the base Exception is being caught and suppressed. It's generally best to only catch exceptions that you can handle, otherwise, you're just continuing without knowing what went wrong and your code could be in a bad state.
Absolutely agree, haven't had the time to fix in 0.4.9e. I'm unsure what you're seeding transactions.nxt with when it's not found? Are those the genesis block transactions? Shouldn't they be getting downloaded from somewhere?
Those are the genesis block transactions, hardcoded in the code. My account number is somewhere there too...  It's kind of awkward to have a private class (e.g. Blocks) populate a member of the containing type directly (e.g. Blocks.loadBlocks assigns Nxt.blocks directly). It looks like you're using classes primarily for namespacing (e.g. grouping related functions) instead of creating standalone classes. For example, the Blocks class cannot be used anywhere else because it has hard dependencies on Nxt (which is also doing server stuff). Might not be a big deal in your case, but it's usually better to minimize class dependencies by creating small, reusable classes with a single purpose (in other words, following the SOLID principle).
Agree. The code doesn't exactly follow any textbook design patterns either. Significant refactoring is needed, but no time for it now, need to fix the critical bugs first. If read object throws here, neither stream will be closed. You should consider moving the closes to a finally block.
Rest assured, all streams are safely closed in finally blocks (or actually using java 7 try-with-resources) in 0.4.9e. |
|
|
|
I hope you already remove "double copy" peers = ((HashMap<String, Peer>)Nxt.peers.clone()).values(); from thread, which is start every second Yes. There is no invocation of clone() in 0.4.9e. |
|
|
|
AFAIR, HashMap.values() make a copy, while HashMap.entrySet() definitely not.
So my variant is even better. You sync in peers anyway, so it is safe.
I didn't know that, are you sure? From the java source of ConcurrentHashMap, which Nxt.peers already is in 0.4.9e: /**
* Returns a {@link Collection} view of the values contained in this map.
* The collection is backed by the map, so changes to the map are
* reflected in the collection, and vice-versa. The collection
* supports element removal, which removes the corresponding
* mapping from this map, via the <tt>Iterator.remove</tt>,
* <tt>Collection.remove</tt>, <tt>removeAll</tt>,
* <tt>retainAll</tt>, and <tt>clear</tt> operations. It does not
* support the <tt>add</tt> or <tt>addAll</tt> operations.
*
* <p>The view's <tt>iterator</tt> is a "weakly consistent" iterator
* that will never throw {@link ConcurrentModificationException},
* and guarantees to traverse elements as they existed upon
* construction of the iterator, and may (but is not guaranteed to)
* reflect any modifications subsequent to construction.
*/
public Collection<V> values() {
Collection<V> vs = values;
return (vs != null) ? vs : (values = new Values());
}
|
|
|
|
Okey, let me rewrite something For memory usage I prefer to code like this: List<Peer> selectedPeers = new ArrayList<>();
for (Map.Entry<String, Peer> entry : peers.entrySet()) {
Peer peer = entry.getValue();
if (peer.blacklistingTime <= 0 && peer.state == state && peer.announcedAddress.length() != 0 && ((!applyPullThreshold || !enableHallmarkProtection || peer.getWeight() >= pullThreshold))) {
selectedPeers.add(peer);
}
} And even more, List selectedPeers can be reused, if used only in this method. You are reading my mind. My tinfoil hat has been leaking! My replacement of the same lines in getAnyPeer, already in 0.4.9e: List<Peer> selectedPeers = new ArrayList<Peer>();
for (Peer peer : Nxt.peers.values()) {
if (peer.blacklistingTime <= 0 && peer.state == state && peer.announcedAddress.length() > 0
&& (!applyPullThreshold || !enableHallmarkProtection || peer.getWeight() >= pullThreshold)) {
selectedPeers.add(peer);
}
}
|
|
|
|
Small suggestion on usage of Collection.toArray(). I see a lot of calls like peers.toArray(new Peer[0]) 1. It is completely useless and equal to simple toArray() call. 2. It is better in terms of speed and memory usage to code like this: peers.toArray(new Peer[peers.size()]) A search for toArray in 0.4.9e finds only two instances in old, commented out code. Keep digging, I am still a step ahead. |
|
|
|
Static variables like peers, blocks, accounts, users are not final. They are initialized at start, so it is not a big flaw right now, but who knows about future.
In 0.4.9e, they are. :-) When I look more deeply in syncronizations, I see a lot of places, where author get content of such global collection and then sync on it, but not sync on collection itself. Example: Block.analyse() method:
Account generatorAccount = accounts.get(Account.getId(generatorPublicKey));
synchronized (generatorAccount) {
generatorAccount.setBalance(generatorAccount.balance + totalFee * 100L);
generatorAccount.setUnconfirmedBalance(generatorAccount.unconfirmedBalance + totalFee * 100L);
} I have fixed, I hope, the synchronization issues related to Blocks and Transactions in 0.4.9e. The synchronization in Accounts is on my TODO list for the next version. |
|
|
|
|
Show Posts
