ok just tried a service install using 0.2.9a.tar.gz (the one on the website).  It work both for a 1.6_u25 Sun JDK.  I tested both the 32bit and 64bit versions ok.  I haven't tried openJDK1.7 but I can't see any reason why it would fail.  Unless "C:\Program Files\Java\jdk1.7.0\jre\bin\server\jvm.dll" doesn't happen to exist in openJDK?

You might try editing win-service.bat and changing the options : --StartMode=jvm and --StopMode=jvm to either 'java' or 'exe' (no quotes).

Detail doc on service options available here: http://commons.apache.org/daemon/procrun.html

procrun can be a bitch to get right so I'm scared to touch it once I've found a working config.

did you try running the service gui and verifying that all paths etc it's recorded for the service are valid?

oops... that's a little embarrassing.  I put the 0.2.8 binary in the 0.2.9 distribution...
I've updated the archive on the download page and also put the single jar file there if you want to just download that and copy it over the old one.

Sorry about that...

Not sure what that one's all about I just did a diff between the 0.2.8 and 0.2.9 win-service.bat and they haven't changed... Are you running from the same directory?  If not you may need to remove the service before reinstalling.  Remember you *must* run win-service.bat from the bin directory or none of the paths will match up properly.

You can try running PoolServerJServicew.exe which is a gui interface to show all the service settings.  Check that all the paths in there are actually valid.  I'm just about to head to bed so if you don't have any luck let me know and I'll try a win-service install from the 0.2.9 binary in the morning and see what I can find.

thanks, I've fixed the sample sql files in 0.2.9.  BTW 0.2.9 fixes a critical memory leak so please update.

It could be several of those things...

I haven't tried psj with solidcoin but I can't see any reason it wouldn't work ok with so I wouldn't jump straight to b).

With regards to config yes there are some easy ways to turn psj into a pig and in fact some of the default settings in the sample config are probably not ideal as defaults.  With the right tuning it should fly though.  I've written a bit of a guide to performance tuning here: http://poolserverj.org/documentation/performance-memory-tuning/

But definately the first step is to ensure you've got a patched bitcoind.  I saw 10-20x performance increase in the rate of incoming works when I patched my daemon.  I don't know how heavily solidcoin has been modified so not sure how easy/hard it will be to apply that patch but it really is essential.  If patching isn't an option (or if it is and you just want more)... Then you could always setup a whole bunch of bitcoind's and feed them all into the poolserver. 

It appears the last critical update introduced a new bug which if triggered causes a memory leak due the cache flushing thread crashing.  If you're using 0.2.8 upgrade is urgently recommended.

[0.2.9]
- fix: FastEqualsSolution not serializable causing exception dumping workmap during safe restart
- fix: nullpointer exception crashing cache cleaner thread leading to eventual OOM error.
- added generic try catch to all threads to catch unknown exceptions and prevent them stopping. - need to add 'shutdownOnCriticalError' option then these errors can be handled by shutting down the server and a wrapper script can restart.

you've kind of just pointed one of the more insidious potential effect of hopping.  For many small pools switching to PPS is simply not an option due the much higher variance risk they have to bear.  Only last week we saw a small pool shutdown for just that reason.  The endgame is that small pools will gradually lose 24/7 miners to pool large enough to handle PPS.  Leaving them with only hoppers... When they have no 24/7 miners left to leech off the hoppers won't have any advantage and will move onto the next pool.

It's currently very hard for small pools to break in a get a reasonable market share but continue to above scenario to it's logical conclusion and you won't have any more small pools.  Competition and innovation will be seriously damaged.

Even if it doesn't cost the pool directly it will cost indirectly as their 24/7 miners wise up and leave for a hop-proof pool.

They lose coins compared to what they would make if there were no hoppers... It's a zero sum game.  The number of coins to go around is pretty much fixed.  If no one hopped everyone would get the same amount of coins as if everyone hopped.  Somewhere in the middle hoppers get more and non-hoppers get less. 

There's any number of convoluted rationalizations to dress it up with but the simple fact is pool-hoppers make additional profit at the cost of non-hoppers.  Sure you could argue that it's their own stupid fault.  They don't know about hopping or they do but don't know how to avoid it.  Or perhaps in rare case they just like giving coins away.  But it doesn't alter the fact that for hoppers to win there has to be non-hoppers that lose.

Did anyone get video of jgarzik's presentation?  If so please post it somewhere.

Hi Gentakin,

The 0.2.8 release should address all these issue.  I've moved all the duplicate handling inside the same synchronized block so this should alleviate the race condition.  There was a reason for duplicate not being logged... Developer forgot... Fixed now though.  I've rewritten the whole duplicate check portion.  I found a couple of other possible problems in addition to the 3 you found so thanks for bringing my focus to this part of the code, it was very much needed.  It was originally added as a bit of an afterthought and not really tested thoroughly.

The tests you've been doing would make great unit tests... If only I could work out how to integrate phoenix into a unit test.  DiabloMiner might be an option for integration as a test platform since it's java based.

This release contains some fix's and updates essential for anyone running a live pool.  Please read the changelog for details.

[0.2.8]
- implement 'include' in properties to allow seperation of config blocks into different files for easy changeover
- add check for duplicate solution on submit
- changed 'stale-work' to 'stale' for pushpool compatibility
- change property name 'useEasiestDifficulty' to 'useRidiculouslyEasyTargetForTesingButDONTIfThisIsARealPool' to make is clear this isn't the same as pushpools 'rpc.target.rewrite'
- crude support for share counter table updates rather than full submits.
- fix: cache size set to 1/2 maxCacheSize due to partially implement dynamic cache sizing
- fix: shares accepted below difficulty due to endian issues setting difficulty target. (thanks luke-jr for the help)
- fix: duplicate work checks not working properly due to race conditions.  Moved atomic duplicate check/update operations into synchronized block.
- fix: duplicate work not being logged
- updated json-rpc and utils libs
- update sample properties file to reflect recent changes.

spam away.. It's very helpful.  The faster we can find all the bugs the sooner it's ready for production use.  I'll have a detailed look at all this now.  I would have last night but got hit by the flu from hell and had to go to bed...

I worked it out (thanks to luke-jr for the handholding).. I had the endianess around the wrong way when setting the easy target string and converting to a BigInteger.  I've made a fix now and will create a new release shortly.

Some more interesting stats...

http://boinc.netsoft-online.com/e107_plugins/boinc/bp.php?project=1

I looks like since may all the BOINC projects have been dropping.  Folding@home peaked at around 8 and is now around 4. Coincided pretty much with the bitcoin price bubble and the Silk Road publicity.

hmmm... if useEasiestDifficulty != true then

easyDifficultyTargetString = "ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000"
easyDifficultyTargetAsInteger = new BigInteger(easyDifficultyTargetString, 16);

Which is basically just parsing the hex string...

There's no other reference to either variable through any codepath.... I'll have a more detailed look in the morning but I' think that string is wrong?  Not sure where I got that from...

Yes that should be a safe assumption except for the bug you pointed out ... Actually the check should just be entry.ourResult.  Currently reason is left null for a valid share and I can see no reason why it would change but it's possible in future the reason field may be used for some sort of meta data.  entry.ourResult is intended to be guaranteed to reflect share valid/invalid from the pool's perspective.  



Thanks for the report.  I'm a bit befuddled to be honest since the validation code hashes the solution before checking.  Any chance you could send me the modded phoenix file?  And let me know what version?  Or if you can tell me the version jand which file it's in if the code you quoted is verbatim.

You didn't happen to have useEasiestDifficulty=true in your properties file did you?  If so could you set it false and test again? useEasiestDifficulty sets difficult so only 2 hashes are required on avg to get a solution.  It's intended for load testing only and should have been set false in the sample properties file but as with the license I forgot to update

I think for next version I might change the property to useRidiculouslyEasyTargetButDontIfThisIsARealPool so it's more obvious that's it's not the same thing as rewritedifficulty in pushpool.

Good catch, that's an oversight on my part... as of v0.2.3 the code was published to https://bitbucket.org/shadders/bitcoin-poolserverj

As far as I'm concerned what's published is OSS.  I haven't updated the licenses yet, will do so in the next release which should be in the next couple of days.  If you want to be covered in the meantime pm me an email address and I'll send you a 'permission to create derivatives' email.  I would just write it here but I don't think a forum post carrys much legal standing.

The only parts that aren't fully OSS with published source are a few utility libraries of my own that I use for numerous unrelated projects.  The reason I haven't published those is because I don't want the hassle of maintaining a public repo for them all.  You are welcome to decompile and inspect code, if you really want the source contact me and I'll send you a copy of the current snapshots.  The one's I'm referring to are all the libs in the /lib/lib_non-maven folder with the exception of the trove library (which is OSS and not written by me).

0.2.7 released

[0.2.7]

- fix: accidentally hardcoding our_result = false
- enabled reporting winning share to blockChainTracker which enables notifyBlockChangeMethod to report if the block was won or not.
- fix: UniqueDataPortiton.equals not comparing properly.  preventing hashmap lookups making valid work submits report as unknown.
- added method “flushWorkers” to mgmt interface which works just like “flushWorker” except it take a “names” param with a comma delimited list