Since Iconomy has gone inactive, what can i use instead

Discussion in 'Plugin Development' started by Yurikoma, Jul 8, 2012.

Thread Status:
Not open for further replies.
  1. Offline

    Yurikoma

    (I don't know if this goes here, but i can't find anywhere else to ask)

    Iconomy is currently classified as inactive, and has been for awhile now, so I don't feel comfortable keeping it around until it becomes more unstable/breaks.

    So does anyone know another plugin that does the same job, or is better.

    Any help will be appreciated.
     
  2. Don't worry, iConomy won't die that easy:
    1. The author is still active.
    2. It's open source so if the author abandons it somebody other will take it up.
    3. The reason that it's inactive is because it did not break for a longer time, so no code changes where needed.
     
  3. Offline

    Yurikoma

    the author hasn't been online since Apr 03, 2012 though, but i guess i will stick with it untill something happens 2 it
     
  4. From the forums:
    As this looks like a montly check at one of the two sites he should logon again soon.
    Or maybe he just logs on if he has an alert, is it like that Nijikokun ? ;)

    //EDIT: Also: Last activity at github: 6 days ago.

    //EDIT²: Last twittered: 2 days ago.
     
  5. Offline

    horse2950

    If u don't feel like doing any updating or waiting just use Essentials! They have a built in Economy.
     
  6. Offline

    the_merciless

  7. Offline

    Xemos

    Why change from 5.01? There is nothing broken with it so there is If it works don't change it. We have done a bit of changes ourselves to it to further integrate it into our server. But alas, i see no need why you have to have it active when nothing is broken in it. xD
     
  8. Offline

    Yurikoma

    im using the v7 april fools joke one also i was looking at the author on bukkit Dev Nijikokun, some reason they are two different accounts.

    Also keeping it active insures users that it is stable, the longer time there is between updates, and so on worries us that it might not be updated when it does break.
     
  9. Everybody has two different accounts cause the forums and bukkitdev are two different sides. You can link the accounts but it doesn't bing you anything except the typical "dev.bukkit.org profile" below your name.
    But it does not need any updates. iConomy is a good piece of software that matured enough to not break that easy and to have all the functions users want it to have.
    Think about it that way: If you have builded a house, would you renovate it because the leaseholders could think you don't care about it or would you do it if there's need to cause something broke?

    Seriously, what should the author of iConomy do to make you guys happy? Release v7.1 which would be exactly the same as v7 expect the april fool message removed? :confused:
     
  10. Offline

    pzxc

    Mmmmm... how about fix the multithreaded flatfile bug that Vault warns about whenever you load iConomy with a vault installation. Meaning, iConomy (still) has a multithreading bug where any multithreaded plugin that tries to write iconomy data (giving players money etc) -- such as votifier -- can cause a wipe of all iconomy data, resetting everyone's money to zero. This has been discussed heavily on the vault forums

    Mysql storage of iconomy does not have this problem, but since vault has no way to detect whether your iconomy setup uses flatfile or mysql it throws a SEVERE error telling you iconomy has major problems (and it does) when using flatfile account storage. I have a small server that I don't use mysql at all, everything is flatfile, and we were having total economy resets happen a couple times a week for the last few months... I went as far as to write a script to backup the accounts.mini iconomy flatfile periodically so I could restore it when a wipe occurred, which it did many times. Now, you could say "so use mysql then" which of course is an option. But then I could also say "iconomy should fix the flatfile, some people prefer it over mysql for various reasons".

    Ended up switching to BOSeconomy a couple weeks ago. It works perfectly again.
     
  11. Just had a look at iConomys bug tracker and the bug you mentioned isn't listed there (at least not as open bug, didn't had a look at the closed ones). Also keep in mind that you aren't even allowed to call (99% of) the bukkit API calls from another thread cause of minecrafts nature. That this wrong using of the API works with MySQL is cause of MySQLs nature and does not mean it's a bug in the flatfile system.

    If Vault wants to synchronize API calls that aren't meaned to be called async it's their bug, not iConomys.
     
  12. Offline

    pzxc

    It's not Vault that's causing the problem. It's many other plugins, including Votifier as an example, that interface with iconomy (via Vault or independently). Vault is just reporting the issue because they get complaints about economy resets, and since iconomy is one of their supposted "economy" plugins, they felt it necessary to warn their users about it. And, it's not that the plugins that cause the problem (e.g. Votifier) are calling bukkit API methods asynchronously or writing to the file system asynchronously -- rather, they are calling methods of iConomy (or calling methods of Vault which then calls methods of iConomy), and *it* is writing the data asynchronously and thus sometimes causing economy wipes.

    Really, you can't blame anyone BUT iconomy for wipes caused by writing data asynchronously to iconomy's flatfile "accounts.mini" because no plugins write to that file, they just call iconomy methods and iconomy writes to the file. If iconomy handled its I/O properly then there wouldn't be money wipes. After all, the flatfile is the "backend" so to speak of iconomy, it's internal to iconomy, and not even exposed via iconomy methods.

    Also here are tickets on iConomy's bug tracker relating to this issue:
    https://github.com/iConomy/Core/issues/228
    https://github.com/iConomy/Core/issues/222
    https://github.com/iConomy/Core/issues/214
    https://github.com/iConomy/Core/issues/196
    https://github.com/iConomy/Core/issues/190
    https://github.com/iConomy/Core/issues/171

    Now, I guess you could say, well if plugins didn't call Vault methods asynchronously, then Vault wouldn't call iconomy's methods asynchronously, and iconomy would write data asynchronously thus corrupting the file. True. However that doesn't excuse iconomy for not handling its own internal storage correctly. If it was designed so that data shouldn't be written asynchronously, then it should also have been designed with a queue system of some kind so that asynchronous calls to iconomy methods would build a queue which would write data to its internal (i remind you internal) storage system in a synchronous manner. Yes?

    Anyway, BOSeconomy handles it all properly and works without a hitch even on plugins that do asynchronous calls, so that's what I'm using now... I don't even really have a problem because I switched and I'm happy as can be now under boseconomy. The only reason I brought it up is because I thought surely anyone who claimed "iconomy works great and has no issues, what could you possibly ask them to update it for?" must surely not realize that there ARE issues, in fact issues severe enough that other plugins, including the #1 bigger economy/chat/permissions interface plugin that many many many MANY plugins use to interface with various economy/permissions systems feels it's serious enough to warrant throwing a severe error on startup just to warn people about what can happen under certain circumstances....

    those circumstances being using iconomy with flatfile storage, and any number of plugins that might happen to execute economy calls asynchronously (which for most people, there's no way to tell which plugins might call it synchronously and which do it async -- I only happen to know that Votifier is one but I do know there are others, but I have no way to tell).

    Now.... shall we continue to let iconomy stick its head under the hand and say "not our problem! another plugin is causing it!" and ask all those other plugins to make sure they are not calling economy interface methods in an asynchronous manner? Or shall we ask the one plugin (iconomy) that has the ability to fix ALL the problems by fixing their own internal I/O procedures? I dunno what method would be simpler, I tend to think the problem should be fixed at the source, not at the symptom level. But what I do know is, iconomy hasn't been updated in a while, and it's losing users because of this issue and will continue to do so until/unless they fix it (which it is in their power to do, boseconomy does not suffer from this problem).

    For now I am just telling people to switch to boseconomy (which they are aware of and are willing to discuss this issue just like vault is, in fact they are designing an import feature specifically *because* of this issue to make it easier for people to switch over from iconomy)
     
  13. pzxc From your first link:
    So it sounds like it isn't iConomys nor Vaults bug but a bug of Votifier and other plugins, which seem to assume they are allowed to call API functions (from Vault or directly from iConomy) asynchronous, which simply isn't the case.

    Also, again, that it works with MySQL is cause MySQL is thread-safe by it's nature while a flatfile is not. Hence why we use SQL in heavy multi-threaded environments (like a web server) instead of flatfiles (of course other thinks like general performance count here, too).

    So you have the choice:
    - Don't use iConomy.
    - Bug the authors of Votifier & co.
    - Use a SQL database for iConomy (and get all the other nice things from using it, too).

    I just can't see a bug in iConomy here. If I would write a plugin which calls bukkit API functions asynchronously and if your server would crash cause of this, would you bug the bukkit team about it cause their API methods aren't thread safe or would you bug me cause I use the API wrong? Right now you are bugging iConomy cause others use it's API wrong...
     
    ferrybig likes this.
  14. Offline

    pzxc

    Bukkit clearly documents which methods are threadsafe and which aren't. iConomy doesn't inform you about any lack of thread-safeness. BOSeconomy is threadsafe. So I'm picking option 1 - don't use iconomy.

    I'm just saying, it'd be simpler if, instead of iconomy pointing the finger at everyone else anytime somebody brings this issue up (including in their bug tracker), they were simply truthful and informative (our internal storage isn't threadsafe, and we haven't built anything into our method calls that makes sure asynchronously called API methods only call internal storage in a synchronous manner, therefore all our method calls are not threadsafe. And either (a) we are aware of the issue and plan to fix it, or (b) we are not gonna make our plugin threadsafe, we admit this is a problem with flatfile storage but have no plans to fix it.

    But they're not saying they're gonna fix what *is* within their power to fix, instead they deny that there is even a problem...

    I mean, really, I'm a good programmer but new to bukkit, and even I can tell all you have to do is making a queueing system on modifying the data, wherever there is a possibility of conflict / thread collision, just put a queue in front of it and insert all "asynchronous" changes to the queue, and where the data-writing must be synchronous, pull it from the queue one at a time from a single thread. Really shouldn't be that hard, but then that depends on how much technical debt has been accumulated from bulky code... and since iconomy was the best and greatest economy plugin for such a long time, I bet their codebase isn't the prettiest out there or easiest to work with.

    I suppose you're technically right that it isn't a "bug" with iconomy if they never intended for any of their methods to be called asynchronously, but they certainly don't tell anyone to be careful not to do it. And so many plugins do it, and so it breaks. I don't blame iconomy for it happening, if it wasn't their intention for their code to be threadsafe, but I do think it's easier to ask them to fix it for everybody, than it is to ask everybody else (other plugin developers) to fix it for them.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 26, 2016
  15. (source: http://wiki.bukkit.org/index.php?title=Scheduler_Programming )

    The list was way shorter not long ago and it didn't grow cause they fixed the thread safety, but users reported the methods are thread save or they realized it for themself. What they really document is: There may be thread safe methods, but to get sure either read the sources of bukkit or just use the few methods at the list. Why should iConomy go another way here?
    Why should they? Flat files aren't thread safe by nature and any dev assuming a API based on it must be is clearly doing something wrong.
    Which is fine, but no reason to bug iConomy. It's the other way around: You have a working alternative, so just use it.
    Well, I don't know all the story and I won't search now, but I would assume they where spammed by so many bug reports that they decided not to handle them, which means: "Stop opening duplicated bug reports! We know about it and we won't change it!" ... I mean you linked 6 reports and tell that there where many discussions all over again. If users can't listen to what was told and instead ask the same questions over and over again you would ignore them too, wouldn't you?
    Cause there is no problem. Google for terms like "flat file thread safe" ... A dev should know that something based on a flat file may not be thread safe and check that before using it asynchronously. The fact that there are plugins which use it the wrong way just shows the skills of the dev and the quality of the codes. But there are tons of plugins which call bukkit API methods asynchronous, too. I just filled a bug report cause of that for a major plugin used by many servers today. According to your statements it would have been better to bug the bukkit team about it...
    Yea, but then the data isn't up2date, so you would bug iConomy cause if another plugin asks for the amount of money a player has the retuned value may be wrong. Or cause plugins are taking more money from your account than you have, or... As this would be a real bug in iConomy they would fix it by freezing the queue, checking the file , then check the queue and finally unfreezing it again at every API call which could easily ruine performance and you would bug them cause it lags the server...
    You have a link to iConomys github page, so why bet instead of check? I didn't look into iConomy that much, but from what I've seen it looks like easy maintainable, modular code.
    Okay, go at the roof of your house and look if there's a sign "don't jump". I bet there isn't, so it must be safe.
    Everybody knows that it's not and (again) a flat file storage isn't naturally thread safe, so assuming an API build around it must be is purely stupid.
    Showing the skills of some devs here and the quality of their code. If they are to lazy to check their codes for thread safety but blindly assume it has to work why do you even use their plugins? I woudln't touch any software from a dev that seems to fail logic thinking.
    And it's easier to tell bukkit to make all their API calls thread save instead of asking every dev of every plugin that uses the API wrong. But nobody (well, not really nobody, some "good programmers" really did it) would bug bukkit cause of it.
     
  16. Offline

    Sleaker

    V10lator - sorry, but you comments about iConomy being active, and having an active developer are wrong. So are your comments about it receiving bug fixes.

    iConomy only had 1 developer, Niji. he would come back from 3 month long hiatus's to fix maybe 1 or 2 issues, or to fix small compatibility problems with a bukkit release, then never actually take a look at the bugs that were being reported. This kept the illusion that the plugin was active. If you look through the commit history on this project you'll see what I mean. It hasn't had a commit in about 3 months, and hasn't seen a good effort at fixing the current bugs that exist for over 6 months.

    The reason why iConomy was moved to inactive was because the developer could not be reached to continue updating the project. He is still active on github with non-Bukkit related projects, but he simply ignores iConomy/Bukkit projects, leaving things pretty apparent that he has given up.

    As far as the crashes are concerned, yes iConomy has a pretty big issue. It's flatfile support is self-written (for no apparently good reason), and does not support thread-safe calls which cause it to wipe data with plugins like votifier.
     
  17. Sleaker Well, then my point that it's open source stays still valid, so maybe somebody should fork it.

    But are you sure that's the case it has gone inactive? As far as I remember plugins are going inactive automatically after some time.
     
  18. Offline

    Sleaker

    Plugins don't automatically go inactive yet (at least that I'm aware of). I personally requested staff look into it because it causes so many problems. They tried contacting Niji, he never responded. Plugin was put into inactive state due to developer being inactive, and not patching the plugin regularly.

    And yes, someone could take over iConomy as it's GPL, the issue I see there is that Niji has so much custom code in his flatfile db (the whole thing) it's not really worth trying to fix it. It seemed more like he was experimenting on creating a new data store type, and in the end, it has caused more issues.
     
  19. Still somebody could remove the flat file db and maybe re-implement it in another way. ;)
    I agree that this might be a lot of work, but we have so many coders here and iConomy is on of the major bukkit plugins, it shouldn't be that hard to find at least one coder that wants to do the job. But maybe the problem is that they think (like I did) that the author is still working on it...
     
  20. Offline

    Sleaker

    why not just work with an active plugin - CraftConomy, has an active developer and nearly all the features that iConomy had, and wouldn't be that difficult to fill in where it was lacking,
     
  21. Offline

    winter4w

    There is a bug your database can be gone for no reason ....
     
Thread Status:
Not open for further replies.

Share This Page