[ATTN: POOL OPERATORS] PoolServerJ - scalable java mining pool backend

[shads]

- There seems to be a (or even two more) different bug(s) related to counting invalid shares as valids.

- Are "duplicate" rejects not getting logged on purpose?

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.

[1713255513]

1713255513

[1713255513]

1713255513

[gentakin]

Thanks for fixing the bugs really fast! I appreciate it. And get well soon.

I also thought about creating a test suite to check for these kind of problems (could be useful for other custom pools, like AFAIK bitp.it). I have been digging through the Diablominer source some time ago, and I guess it's possible to use it (if the license allows to do so). It will probably get "a little" cluttered..

[eyeoh]

Still having great results with poolj

[Sukrim]

On the other hand you could also try to use jython and run phoenix too!

...or include a fixed "test" getwork with known solution(s)?

It might however be interesting to have something like a "benchmark"/test of the whole system that consists of several miners (where you know the solutions already beforehand), getwork sources (emulated bitcoinds that always return the same sequence of getworks as well as emulated pools for the proxy mode) where you can then also do regression tests for the performance of the whole software.

[shads]

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.

[urstroyer]

The PoolServerJ works great! Keep development going on, i see really huge potential! Definitely worth some donations!

[eleuthria]

Giving PSJ a bit of a bump here.

BTC Guild's new PPS pool has elected to use PoolServerJ during its beta run.  So far the performance has been outstanding (looking at stale/reject rates of < 0.2%).  It eats a decent chunk of RAM at boot, but the increase in RAM usage is very small as the pool scales.

Excellent work shadders, and hopefully soon we can post that a PSJ pool has found its first block .

[eleuthria]

3 blocks have been found by BTC Guild using PoolServerJ so far.  All 3 had the latest patch where it logs shares detected as matching current difficulty before submission and tracks them.

All 3 blocks were identified by PSJ as full difficulty shares before submission, and all 3 were accepted.  No false positives/false negatives so far.

[DavinciJ15]

What to be a hero with your software?

Help me set it up on an Amazon servers and save Namecoins PoolServerJ will be the hero.

[shads]

What's happening to namecoins?

[DavinciJ15]

What's happening to namecoins?

Someone planning an attack, My pool can't handle the hash rates I can give you an amazon server or servers with pushpool compatible schema tonight (Im at work) and you can set it up PoolServerj.  Just tell me what you need.

read about it here...
Namecoin is Prime for a 51% attack
http://dot-bit.org/forum/viewtopic.php?f=2&t=292

[DavinciJ15]

What's happening to namecoins?

I'm sending you 10 btc at 1LezqRatQz7MeNoCVziYwcdwtqeEbvrdAq for your work even if you don't help.

[wtfman]

hey, nice work so far, keep it up

what I missed at my first test was, that I was not able to connect my miners without supplying a password. Would be awesome if that could be implemented too. Maybe I did not find out how it works, but its possible?

[shads]

hey, nice work so far, keep it up

what I missed at my first test was, that I was not able to connect my miners without supplying a password. Would be awesome if that could be implemented too. Maybe I did not find out how it works, but its possible?

take a look at the guide to building plugins:
http://poolserverj.org/documentation/plugin-guide/

It just so happens the example I used in the tutorial was an AnyPasswordWorkerAuthenticator plugin.  That example plugin is included in the build so you just need to do step 2 to enable it.

[wtfman]

hey, nice work so far, keep it up

what I missed at my first test was, that I was not able to connect my miners without supplying a password. Would be awesome if that could be implemented too. Maybe I did not find out how it works, but its possible?

take a look at the guide to building plugins:
http://poolserverj.org/documentation/plugin-guide/

It just so happens the example I used in the tutorial was an AnyPasswordWorkerAuthenticator plugin.  That example plugin is included in the build so you just need to do step 2 to enable it.

great! thanks. also sorry for not noticing it

[DavinciJ15]

Thanks for the fix for my pool it helped a lot, there is no need for me to switch from pushpool right now I must focus adding more power to my pool so that it can handle more hashes.

Once that's done I can upgrade to PoolServerJ.

[shads]

This is a major milestone release for PoolServerJ.  Many of fixes and improvements were as a result of an extensive stress testing process by BTC Guild while they were migrating the pool over.  To celebrate I've changed to license to fully open source.

Notable changes include:

    * Now licensed under GPL v3
    * complete rewrite of longpolling code which has improved longpolling performance markedly
    * alpha implementation of native longpolling listener with the aid of an intermediate daemon built by Caesium from rfcpool
    * numerous stability fixes.

Complete changelog (including the changes from the unreleased 0.2.10):

[0.3.0rc1]

- license change to GPL v3.0
- added a temporary logger to record all stages of submission where a real solution is found.
- fix from <Eleuthria>: convert submitted data to lowercase, some miners return in uppercase resulting in failed work lookup from map.
- new mgmt interface methods:
?method=setCacheSize&source=<mySourceName>&value=<value>
?method=setMaxConcurrentDl&source=<mySourceName>&value=<value>
?method=setMaxWorkAgeToFlush&source=<mySourceName>&value=<value>
?method=setAllCacheSize&value=<value>
?method=setAllMaxConcurrentDl&value=<value>
?method=setAllMaxWorkAgeToFlush&value=<value>
?method=listWorkerCache

- force cache to be trimmed if shrinking cache size.  If left untrimmed this can result in a lag when all the work expires.  Normally as work is request it will open up a slot for fresh work to be fetched.  However due to cache being oversized this doesn't happen.  It's possible for the entire to end up getting purged so the server has to catch up filling the cache from daemon while servicing requests.
- fix: WorkerProxy was case sensitive.  In cases where database case was different to user supplied case of worker name this would cause a cache miss and force a db query every time.  Thanks to <Eleuthria> for finding.
- complete rewrite of longpolling code
- added async LP dispatch.
- restructured repo to include dependencies as source projects instead binaries
- fix: clean up longpoll shutdown.  Missed a threadpool executor which was preventing JVM exit.
- fix: longpoll connection are now all explicity closed on shutdown.  Some miners were not registering the closed socket so don't attempt to reconnect to LP when the server restarts.
- fix: prevent work being served from a source until it's confirmed on the new block
- pause work fetching for source until it's confirm on the new block
- add prev_block_hash checks to each incoming work as a new block indicator.  This reduces the amount of polling needed when not in native longpoll mode.
- fix: set autoReconnect=true on JDBC connections.  worker caching can leave long intervals between uses of the connection causing sql server to time it out.
- add fixed time worker cache eviction strategy.  resolves issue #6
- implementation of longpoll connection counting and enforcement of optional limits
- trace logging with target groups for granular tracing.
- clean up of sample properties file add new config options
- fix: nullpointer if share output file not specified.
- fix: nullpointer if request output file not specified.
- addresses issue #7.  When setting worker IP first check X-Forwarded-For header then falls back to remoteAddr.  This covers situations where the server is behind a load balancing proxy.
- fix: use username.intern() to gain a per user canonical sync lock object. Prevents an obscure bug where two near simultaneous initial connections from one worker can result in multiple db lookups where one hasn't been put into the cache before the other is looked up.
- add keep-alive header to json-rpc client requests.

improve worksource syncing on block change
- prevent entries entering cache during out of sync period
- synchronize the change of sync status process
- remove redundant sourcesOnCurrentBlockArray
- change NotifyLongpollClients thread to a Runnable task to avoid having to start up a new thread.
- acceptNotifyBlockChange now had double check inside sync block to prevent double accepts.
- prestart LP executor threads
- fix mismatched sync objects for block change syncing
- workSource resync moved inside sync block

native longpolling
- add registration of native-enabled sources to native lp listener
- improved debug logging
- address handling using canonical host name
- enable verification request to report success or failure

[0.2.10] - unreleased

- fix: WorkSource request throttling was only activating for HTTP level failures.  TCP failures (e.g. connection refused) would not activate throttling resulting in thousands of requests/sec and high CPU usage.
- convert blocknum from string to int
- refactor common elements to bitcoin-poolserverj-core
- fix missing semi-colons in sample sql  scripts

 

[DavinciJ15]

Hi Shadders

My testing of the merged-mine-proxy application created for nmc and btc merged mining was interesting.  I was able to get poolserverj running it was not hard but it sure is a CPU pig with just 1 miner, I think that's over the top for the default settings.  Anyhow that's not what I wanted to talk about, as I was able to merge mine on the test net with just merged-mine-proxy app and find block then when I switched poolserverj I found none!   

Then I tried pushpoold and same thing... NO blocks after 10 times the shares need based on the difficulty.  Mind you I did the test over and over again and some cases I did find a block but not within the normal variance of the difficulty. Only directly mining the merged-mine-proxy gave me blocks within normal variances.

So I changed pushpoold's server.json file to disable rewrite of the difficulty since it seemed that merged=mine-proxy already did that.  BAM! Pushpool worked as it should and is now finding blocks within normal variance, and it posted the shares to the database.

Switching back to poolserverj and I tried disabling the rewrite but I am not sure if I got the right setting. I'm not on the computer with setting so I will edit this post with the setting I changed but it did not work.  Poolserverj did not find blocks. 

So is there setting you know off hand that will stop poolserverj from rewriting the difficulty and post the shares to the DB?

Thanks

Davinci
BTW I will download the new version and try that one as well.

[shads]

Hi Shadders

My testing of the merged-mine-proxy application created for nmc and btc merged mining was interesting.  I was able to get poolserverj running it was not hard but it sure is a CPU pig with just 1 miner, I think that's over the top for the default settings.  Anyhow that's not what I wanted to talk about, as I was able to merge mine on the test net with just merged-mine-proxy app and find block then when I switched poolserverj I found none!   

Then I tried pushpoold and same thing... NO blocks after 10 times the shares need based on the difficulty.  Mind you I did the test over and over again and some cases I did find a block but not within the normal variance of the difficulty. Only directly mining the merged-mine-proxy gave me blocks within normal variances.

So I changed pushpoold's server.json file to disable rewrite of the difficulty since it seemed that merged=mine-proxy already did that.  BAM! Pushpool worked as it should and is now finding blocks within normal variance, and it posted the shares to the database.

Switching back to poolserverj and I tried disabling the rewrite but I am not sure if I got the right setting. I'm not on the computer with setting so I will edit this post with the setting I changed but it did not work.  Poolserverj did not find blocks. 

So is there setting you know off hand that will stop poolserverj from rewriting the difficulty and post the shares to the DB?

Thanks

Davinci
BTW I will download the new version and try that one as well.

Hi Davinci,

To disable rewrite difficulty you will a find the following line in the sample properties file:
#source.local.1.rewriteDifficulty=false

just remove the comment marker ('#')

also ensure you've got:
useEasiestDifficulty=false

This is a testing/debugging setting specifically for load testing with the stress test client.

I was under the impression that pool servers needed some modifications to work with merged mining.  I could be wrong though.

Regarding poolserverj being a cpu pig, the default settings in sample config are probably more suited to larger pool.  So yes by default it will use a lot of CPU and memory... This is advantageous to a larger pool but a little wasteful for a smaller one. 

To rectify this please look at the articles in the documentation section: http://poolserverj.org/documentation/

Specifically: Performance & Memory tuning and Troubleshooting Tips.

cheers

[shads]

Apologies to anyone who's downloaded 0.3.0rc1 and tried to use it.  Due a series on unamusing screw ups the distribution contained an earlier version of poolserverj.jar.  A new distro is uploading right now and should be done in a couple of minutes.